libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static


From: Brian Dessent
Subject: Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static
Date: Thu, 13 Nov 2008 14:16:24 -0800

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]