This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LTO symtabs inconsistency


On 16/10/2010 21:20, Dave Korn wrote:

>>          U _libintl_bindtextdomain
>>          U _libintl_gettext
>>          U _libintl_textdomain

>>  0070 00009600 00005f6c 6962696e 746c5f74  ......_libintl_t
>>  0080 65787464 6f6d6169 6e000002 00000000  extdomain.......
>>  0090 00000000 00a60000 005f6c69 62696e74  ........._libint
>>  00a0 6c5f6269 6e647465 7874646f 6d61696e  l_bindtextdomain
>>  00b0 00000200 00000000 00000000 a9000000  ................

>   For some reason, the two libintl symbols have underscores.  gettext is
> missing altogether because we have a builtin for it, but I don't think we do
> for (bind)textdomain.

  Ah.  It's because those functions have assembler names defined for them already:

> (gdb) call debug_tree ($5)
>  <identifier_node 0x7fa5cf30 *_libintl_textdomain>

  Can someone clarify the purpose of the LTO symtab: is it there for anything
that LTO itself does, or is it solely to get the linker to pick up
kind-of-more-or-less the right dependencies?  IOW, would it make sense for the
LTO symtab entries to be transformed by ASM_OUTPUT_LABELREF, are they intended
to be assembler-level symbols, or are they supposed to be C-level symbols?

    cheers,
      DaveK




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]