Ralf Wildenhues wrote:
> I'm actually not sure whether _GLOBAL__F[ID]_.* can appear on w32.
> Do you know? They should happen with C++ code using constructors
> and destructors IIRC.
Yes they do occur, although not matching that regexp. For one, they
will have two leading underscores before the G, as with all symbols
compared to their linux counterparts (i.e. __USER_LABEL_PREFIX__ is "_"
on Cygwin/MinGW.) For another I would have expected the regexp to match
[FID] not F[ID] as there seems to generally be only one character in
that position, whose purpose is illuminated by this comment in
gcc/tree.c:
/* Generate a name for a special-purpose function function.
The generated name may need to be unique across the whole link.
TYPE is some string to identify the purpose of this function to the
linker or collect2; it must start with an uppercase letter,
one of:
I - for constructors
D - for destructors
N - for C++ anonymous namespaces
F - for DWARF unwind frame information. */
A testcase:
$ echo "struct foo { int x; foo() : x(42) {}; }; static foo bar;" \
| g++ -x c++ -S - -o - -O2
.file ""
.section .ctors,"w"
.align 4
.long __GLOBAL__I__77970994_840EDDA1
.lcomm _bar,16
.text
.align 2
.p2align 4,,15
.def __GLOBAL__I__77970994_840EDDA1; .scl 3; .type
32; .endef
__GLOBAL__I__77970994_840EDDA1:
pushl %ebp
movl $42, %eax
movl %esp, %ebp
popl %ebp
movl %eax, _bar
ret
Also:
$ c++filt __GLOBAL__I__foobar
global constructors keyed to _foobar
$ c++filt __GLOBAL__D__foobar
global destructors keyed to _foobar
$ c++filt __GLOBAL__FI__foobar
__GLOBAL__FI__foobar
This implies that 'FI' is not valid, or at least not recognised by the
demangler as significant.
Brian
