[PATCH] dwarf: Add -gdwarf{32,64} options

[Richard Biener]

On Tue, 1 Dec 2020, Jakub Jelinek wrote:

> On Tue, Dec 01, 2020 at 11:49:43AM +0100, Richard Biener wrote:
> > On Tue, 1 Dec 2020, Jakub Jelinek wrote:
> > 
> > > Hi!
> > > 
> > > The following patch makes the choice between 32-bit and 64-bit DWARF formats
> > > selectable by command line switch, rather than being hardcoded through
> > > DWARF_OFFSET_SIZE macro.
> > > 
> > > The options themselves don't turn on debug info themselves, so one needs
> > > to use -g -gdwarf64 or similar.
> > > 
> > > Ok for trunk if it passes bootstrap/regtest?
> > 
> > OK.  Note there's
> > 
> > /* Various DIE's use offsets relative to the beginning of the
> >    .debug_info section to refer to each other.  */
> > 
> > typedef long int dw_offset;
> > 
> > which on L32 hosts means we might not support dwarf64 generation
> > for CUs that do not fit in 31bits?  Should we change that to
> > int64_t?  Or should we sorry() for -gdwarf64 on 32bit hosts?
> > 
> > There's also
> > 
> >   unsigned long die_abbrev;
> > 
> > and other uses of '[unsigned] long' in dwarf2out.c.
> 
> One thing is 32-bit hosts vs. 64-bit targets, and we maybe should indeed use
> HOST_WIDE_INT for dw_offset; not sure about die_abbrev, if the .debug_abbrev
> section is over 4GiB in one TU, then that would be already massive amounts of debug
> info (.debug_info is typically 10-100x times larger than .debug_abbrev).
> Even the HOST_WIDE_INT dw_offset might not be immediately necessary, if a
> 32-bit host needs to emit 4GiB of .debug_info for one TU, then I'm pretty
> sure we need at least 4 times that much of compile memory if not much more,
> our in memory DIE representation isn't exactly compact.
> The advantage of DWARF 64-bit is not (at least for the time being) a single
> TU exceeding the limits, but when linking a shared library with tons of TUs
> where we exceed those limits then (for some large libraries we are already
> close to those limits or over them now).
> 
> Another thing is 32-bit targets.  For them the limitations of the object
> file format (e.g. 32-bit ELF) will not allow > 2GiB debug info anyway,
> and as I've just tested, e.g. on x86_64 with -m32 -gdwarf64 will not work
> even on tiny testcases:
> as: pr64716.o: unsupported relocation type: 0x1
> pr64716.s: Assembler messages:
> pr64716.s:6013: Error: cannot represent relocation type BFD_RELOC_64
> as: pr64716.o: unsupported relocation type: 0x1
> pr64716.s:6015: Error: cannot represent relocation type BFD_RELOC_64
> as: pr64716.o: unsupported relocation type: 0x1
> pr64716.s:6017: Error: cannot represent relocation type BFD_RELOC_64
> So yes, we can either do a sorry, error, or could just avoid 64-bit
> relocations (depending on endianity instead of emitting
> .quad expression_that_needs_relocation
> emit
> .long expression_that_needs_relocation, 0
> or
> .long 0, expression_that_needs_relocation
> So, which way do we want to go?

64bit relocs are not required here?  That is, can one with
dwarf64 choose 32bit forms for select offsets (like could
dwz exploit this?)?

If so the above might be OK, otherwise I guess a sorry()
would be more to the point.

> > Do dwarf32 and dwarf64 objects inter-operate just fine (as long as
> > the linker can resolve all relocations w/o truncating)?
> 
> I think it should, but whether all debug info consumers and other tools
> will be able to cope with it remains to be seen.  If they have bugs, those
> should be fixed.  By adding the -gdwarf{32,64} switches we allow them to try
> that.
> 
> 	Jakub
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)