This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


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

Re: linkonce and dwarf 2


   Date: Tue, 16 Nov 1999 15:13:27 -0800
   From: Jason Merrill <jason@cygnus.com>

   2) Another scheme would be to have only one additional CU.  Each class
   would still get its own section, and the link would cause the CU header to
   be wrapped around the classes which weren't discarded from that object; I'm
   assuming that if you have sections in two objects like

      .debug_info_head
      .gnu.linkonce.d.1A
      .gnu.linkonce.d.f__Fv
      .debug_info_tail

   and the link script says

      .debug_info : { *(.debug_info* .gnu.linkonce.d.*) }

   then the section contents will retain the above order in the output, rather
   than lumping all the _head bits together and so on.

I think this will cause the GNU linker to output all the .debug_info*
sections followed by all the .gnu.linkonce.d.* sections.  I may be
mistaken, though.

What if you aren't using the GNU linker?

   The problem with this scheme is that the CU header specifies the length of
   the CU, and there would be no way to compute this at compile or assembly
   time; it would depend on which subsections had been kept or thrown away.
   Is there currently any way to express link-time arithmetic in gas?

Only via relocations.

   3) Another scheme would be to do something like the stabs BINCL
   optimization, and put all the info for a header into its own CU.  This
   would also be useful for C, while the two schemes above would mainly work
   for C++ (because of the stronger rules for type names in C++).  The problem
   with this scheme is that it would require linkonce and symbol resolution
   semantics like those of the BINCL optimization; we would only want to
   discard duplicates if they were identical, and we would want references to
   be bound to the appropriate instance if not all are discarded.

I'm not sure why this is a serious problem.

   Hmm...it occurs to me that rather than just keying off the header name, we
   could do a checksum of the debug info we're generating and include that in
   the section name and symbol names.  That ought to do the trick without any
   linker changes.

Cute.

Ian

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