www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1997/10/10/07:25:59

From: marcus AT bighorn DOT dr DOT lucent DOT com
Subject: Re: Bad linker behaviour
10 Oct 1997 07:25:59 -0700 :
Message-ID: <199710091441.IAA12964.cygnus.gnu-win32@chorus.dr.lucent.com>
To: ian AT cygnus DOT com, gnu-win32 AT cygnus DOT com

In reference to ld doing demangling by default, Ian says:

>I would have no objection in principle to making this depend upon a
>command line option.  Unfortunately, compilers traditionally do not
>pass any such command line option.  gcc must work with either a native
>Unix linker or the GNU linker.  It can not pass a command line option
>that will only be understood by the GNU linker.  Therefore, I don't
>see any way to make this work correctly based on a command line
>option.

When gcc compiles a file, there are two symbols that it adds to the object
module, `___gnu_compiled_c' and `gcc2_compiled.'.  For a C++ file, I see
that `__gnu_compiled_cplusplus' and `gcc2_compiled.' are defined.  So, it
seems that ld could watch for `___gnu_compiled_c' in an object file and
flag it for removing the leading '_'  on symbols from that module, and
if it sees `__gnu_compiled_cplusplus' it would demangle symbols from that
object module, otherwise it would leave the symbol alone.

Of course, this would have to depend on the source object module, once the
modules have started to be combined (or sub-linked via the -r flag) it
gets a bit more difficult to pick out what symbols came from where.

Does this have much merit?

marcus hall
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019