This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: linkonce and dwarf 2
- To: jason at cygnus dot com
- Subject: Re: linkonce and dwarf 2
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 16 Nov 1999 19:21:37 -0500
- CC: binutils at sourceware dot cygnus dot com
- References: <199911162313.PAA25037@yorick.cygnus.com>
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