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@xxxxxxxxx>: > 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@xxxxxxxxx>: >> 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@xxxxxxxxxx>: >>> 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