Re: understanding __FUNCTION__ generation

1 msg	bug in g++ front-end
1 msg	gcc-4.3-20070914 is now available
2 msg	FW: Symbol Table Export From GCC?
5 msg	porting problem: segfault when compiling progra...
4 msg	Any chance for intel core --march?
3 msg	Stack parameter - pass by value - frame usage
1 msg	Work Online From Home.
29 msg	Is Sun putting much effort into supporting the ...
3 msg	Bootstrap broken - treelang: error: ‘treelang...
7 msg	GCC 4.3.0: Stage 3
3 msg	GCC 4.2 Branch Status: Slush
1 msg	New branch for GC work

understanding __FUNCTION__ generation
\ Sunzir Deepur (11 Sep 2007)
. \ Jim Wilson (12 Sep 2007)
. . \ Sunzir Deepur (12 Sep 2007)

2 msg	Recent (middle-end?) regressions in the Fortran...
4 msg	Polyhedron test: gas_dyn run-time performance r...
1 msg	support for float/complex math in libgcc cross-...
4 msg	SImode and PSImode question
1 msg	gcc-4.1-20070910 is now available
6 msg	deadline extension for debug info project into ...
9 msg	error compiling libgcc with ported cross-compiler

Subject:	Re: understanding __FUNCTION__ generation
Group:	Gcc
From:	Sunzir Deepur
Date:	12 Sep 2007

Hi Jim,

On 9/12/07, Jim Wilson <wilson> 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