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


>>>>> Ian Lance Taylor <ian@zembu.com> writes:

 >    From: Jason Merrill <jason@cygnus.com>

 >       .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.

I figured that if that's what you wanted, you would write

  *(.debug_info*)
  *(.gnu.linkonce.d.*)

 > What if you aren't using the GNU linker?

Well, then you lose.  I don't see any way to do this stuff that doesn't
rely on link-time combination of sections.

 >    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.

I suppose what I was asking was "is there a relocation which could express
the difference between two arbitrary symbols, and is there gas syntax which
could generate it?"

 >    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?  Because headers might have different contents in different objects,
whether because of macros, template instantiations or whatever.  If I have
a DIE referring to a symbol defined in a comdat that is discarded and that
symbol isn't defined elsewhere, I lose.

Jason

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