Fwd: Compiling with -fdata-sections doesn't put the constant in the section expected
Clément Péron
peron.clem@gmail.com
Thu Oct 2 14:09:00 GMT 2014
Ok so i look into the sources and i think their is another other
feature which doesn't work as expected.
Line : 381 of varasm.c sprintf (name, ".rodata.cst%d", (int) (align / 8)).
As i understood it, i think when you use the -fmerge-constant
parameters the string and the constant are put into a specific section
(respectively .rodata.strX.X or .rodata.cstX) depending on their
alignment and LD compare those vars inside those sections and try to
merge when it's possible.
But i created different functions with different constants and none
are put into a section called .rodata.cstX ? is it only me ?
I'm thinking to patch my gcc and i'm thinking about the best way to
achieve both -fdata-sections and -fmerge-constant.
I suppose that the Garbage collector is before the merge of the
string/cst so i think call the section .rodata.csX.__function and
.rodata.strX.X.__function are the best way to achieve both garbage
collecting and merging.
What do you think ? Do you have the same issue when you try to merge constants ?
Thanks for your help,
Clement
2014-10-01 14:14 GMT+02:00 Clément Péron <peron.clem@gmail.com>:
> Yes, functions declared as static and their local variables are
> removed well by the compiler when optimization is enabled.
>
> 2014-10-01 12:02 GMT+02:00 Andrew Haley <aph@redhat.com>:
>> I can't think of any reason that each string should not be put into a
>> unique section. It's need a unique name for each string, but that isn't
>> hard.
>
> You think it's easy to patch because I'm trying to look sources to
> understand but not sure i will suceed to patch it myself.
>
> Do i need to report this somewhere else ? (I saw that the bug was
> reported here but nobody confirmed it
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303)
>
> Clement
More information about the Gcc-help
mailing list