This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFC: Change in dwarf2dbg using sizeof_offset
- From: Kai Tietz <Kai dot Tietz at onevision dot com>
- To: Alan Modra <amodra at bigpond dot net dot au>
- Cc: binutils at sourceware dot org
- Date: Thu, 31 Jul 2008 09:15:20 +0200
- Subject: Re: RFC: Change in dwarf2dbg using sizeof_offset
> On Wed, Jul 30, 2008 at 08:27:07PM -0400, Daniel Jacobowitz wrote:
> > On Thu, Jul 31, 2008 at 09:06:39AM +0930, Alan Modra wrote:
> > > The .debug_aranges change will increase its size by 12 bytes per
> > > compilation unti. The .debug_info change increases its size by 4
> > > bytes per compilation unit. I don't see this as a big deal.
> > >
> > > We aren't talking about changing anything to do with target
> > > addresses/offsets. They are already 64-bit for a 64-bit target even
> > > in the current 32-bit dwarf .debug_aranges.
> >
> > Oh, I see. That sounds fine if we're only talking about aranges. You
> > confused me by saying "means we can't have a .debug_info section
> > larger than 4G" - that offset's the one that takes up a lot of space.
>
> I really did mean .debug_info. The changes are for
> a) the .debug_aranges header, which specifies an offset into
> .debug_info.
> b) in .debug_info, the DW_AT_stmt_list entry of DW_TAG_compile_unit
> DIE, which points into .debug_line.
>
> Huh, but now that I look at it again, I see that this only changes
> assembler generated .debug_info and .debug_aranges, so there isn't
> really any point in making the change. The windows target would need
> to handle compiler generated .debug_info anyway, which presumably
> wants to keep 32-bit offsets for size reasons as you point out.
For w64 I prepared an patch too. It defines the DWARF_OFFSET_SIZE macro
for this target to 8. The problem is that for PE there is no way to allow
32-bit relocations, because a dll can be rebased above the 4 GB va (e.g.
msvcrt is above the 32-bit boundary by default).
So w64 have need that all 32-bit offsets, which are not of kind rva, are
changed to 64-bit offset.
The other chance to do this without the need of any load time relocation
would be to make dw2 using rva instead of secrel. The dw2 code could use
the ld symbol __ImageBase (__image_base) to get the correct va.
Well I see, that the space requirment of this patch is in general small,
so why should we introduce a target difference here?
A second question I have, where in objcopy I have to implement, that load
time relocation pointing into removed sections are remove, too?
Cheers,
Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.