understanding __FUNCTION__ generation

understanding __FUNCTION__ generation

[Sunzir Deepur]

hi list,

recently I've encountered a problem in which some removals of
(what seems to be unneeded) lines of header files inflicted changes in
the resulting binary. further inverstigation showed
that the chages were different __FUNCTION__.numbers (in the __FUNCTION__.
xxx symbol names).

can someone please help me understand what can change those numbers ?
how are they generated and what control them ?

thank you all
sunzir

Re: understanding __FUNCTION__ generation

[Jim Wilson]

Sunzir Deepur wrote:
> recently I've encountered a problem in which some removals of
> (what seems to be unneeded) lines of header files inflicted changes in
> the resulting binary. further inverstigation showed
> that the chages were different __FUNCTION__.numbers (in the __FUNCTION__.
> xxx symbol names).

This would be clearer if you gave an example.  However, I'm guessing 
that the issue here is the names for function local statics.  The names 
for these are unique within a function, but not unique across a file. 
The assembler requires unique names for them, so we add the DECL_UID to 
make them unique.  See lhd_set_decl_assembler_name in langhooks.c.  The 
DECL_UID changes if you add/delete declarations.

For instance, if I compile this with -O -S for an x86_64-linux target
int *sub (void) { static int i = 10; return &i; }
int *sub2 (void) { static int i = 20; return &i; }
I get variables i.1499 and i.1504.  If I add another variable in the 
first line
static int y;
then I now have variables i.1500 and i.1505.

This wouldn't happen with functions unless you have nested functions.

You could see a similar problem if compiling multiple files as one unit, 
since static functions in different files could have the same name, 
which would have to be changed to make them unique.  This is probably 
handled in a different place in the gcc code, but probably handled the 
same way.

Jim

Re: understanding __FUNCTION__ generation

[Sunzir Deepur]

Hi Jim,

On 9/12/07, Jim Wilson <wilson@specifix.com> wrote:
> Sunzir Deepur wrote:
> > recently I've encountered a problem in which some removals of
> > (what seems to be unneeded) lines of header files inflicted changes in
> > the resulting binary. further inverstigation showed
> > that the chages were different __FUNCTION__.numbers (in the __FUNCTION__.
> > xxx symbol names).
>
> This would be clearer if you gave an example.

 This is the diff between the old and the new binaries examined
under objdump -d -t :

2c2
< old.o:     file format elf32-i386
---
> new.o:     file format elf32-i386
10c10
< 00000000 l     O .rodata      0000000f __FUNCTION__.4883
---
> 00000000 l     O .rodata      0000000f __FUNCTION__.4848
12c12
< 0000005a l     O .rodata      00000010 __FUNCTION__.4921
---
> 0000005a l     O .rodata      00000010 __FUNCTION__.4886
17c17
< 000000d8 l     O .rodata      00000015 __FUNCTION__.4965
---
> 000000d8 l     O .rodata      00000015 __FUNCTION__.4930
20c20
< 00000119 l     O .rodata      0000000e __FUNCTION__.5002
---
> 00000119 l     O .rodata      0000000e __FUNCTION__.4967
22c22
< 000001a8 l     O .rodata      0000000e __FUNCTION__.5022
---
> 000001a8 l     O .rodata      0000000e __FUNCTION__.4987
24c24
< 0000021b l     O .rodata      00000010 __FUNCTION__.5051
---
> 0000021b l     O .rodata      00000010 __FUNCTION__.5016

> However, I'm guessing
> that the issue here is the names for function local statics.  The names
> for these are unique within a function, but not unique across a file.
> The assembler requires unique names for them, so we add the DECL_UID to
> make them unique.  See lhd_set_decl_assembler_name in langhooks.c.  The
> DECL_UID changes if you add/delete declarations.

Yes ! That is it ! Thanks so much ! I use the __FUNCTION__ macro
in my code, and i guess it is translated into a static variable holding
the function name, which perfectly fits your explanation !

Thanks!!
Sunzir