Fwd: Compiling with -fdata-sections doesn't put the constant in the section expected

[Clément Péron]

Hi,

I've just add a small code to separate each mergeable string in
different section and i win 6ko on my elf. Which is quite nice when
you have only 200ko available. :)



2014-10-02 16:08 GMT+02:00 Clément Péron <peron.clem@gmail.com>:
> 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