| Message ID | 1303809055.4928.10.camel@springer.wildebeest.org |
|---|---|
| State | New |
| Headers | show |
Mark Wielaard <mjw@redhat.com> writes: > This PR was put on hold for a while since gdb didn't immediately need > it. But the consensus seemed that it was a good idea to always output > the address ranges (.debug_arange section) information if a CU > (.debug_info section) was emitted. Because the consumer has no way to > tell the difference between an empty table that we omitted and failure > to generate a table that would have contained data. We recently > discussed this again (see PR), and it still seems like a good thing. So > here it a patch to just do that: I doubt this is a good idea in general: I've seen the following failure in the libgo testsuite on IRIX 6.5: _gotest_.o ERROR: dwarf_elf_init: DW_DLE_DEBUG_ABBREV_NULL 34 .debug_abbrev section present but elf_getdata() failed or section is zero-length gotest: warning: no tests matching Test([^a-z].*)? in _gotest_.o _xtest_.o elfdump reveals: [13] SHT_MIPS_DWARF 0 0x410 0 .debug_abbrev 0 0 0x1 0 0x00000000 So at least some linkers and tools get confused by such emtpy sections. Rainer
Hi Rainer, On Tue, 2011-04-26 at 11:22 +0200, Rainer Orth wrote: > Mark Wielaard <mjw@redhat.com> writes: > > > This PR was put on hold for a while since gdb didn't immediately need > > it. But the consensus seemed that it was a good idea to always output > > the address ranges (.debug_arange section) information if a CU > > (.debug_info section) was emitted. Because the consumer has no way to > > tell the difference between an empty table that we omitted and failure > > to generate a table that would have contained data. We recently > > discussed this again (see PR), and it still seems like a good thing. So > > here it a patch to just do that: > > I doubt this is a good idea in general: I've seen the following failure > in the libgo testsuite on IRIX 6.5: > > _gotest_.o ERROR: dwarf_elf_init: DW_DLE_DEBUG_ABBREV_NULL 34 .debug_abbrev section present but elf_getdata() failed or section is zero-length > gotest: warning: no tests matching Test([^a-z].*)? in _gotest_.o _xtest_.o > > elfdump reveals: > > [13] SHT_MIPS_DWARF 0 0x410 0 .debug_abbrev > 0 0 0x1 0 0x00000000 > > So at least some linkers and tools get confused by such emtpy sections. Thanks for testing the patch. Although I am slightly confused how it ended up producing a .debug_abbrev section that is actually empty. Are you sure this isn't an existing issue? The only thing the patch should do (and seems to do on my GNU/Linux setup) is to explicitly output a .debug_aranges section that is of the minimum size (so not actually empty, just indicating no ranges are covered by outputting just the table terminator). If you could provide me with some more information (I have neither an IRIX 6.5, nor a libgo setup here) about the created files before/after the patch that would be appreciated. I might have missed some other interaction between the debug section output. Thanks, Mark
Hi Mark, > Thanks for testing the patch. Although I am slightly confused how it > ended up producing a .debug_abbrev section that is actually empty. Are > you sure this isn't an existing issue? it certainly is, and not related to your patch (which I didn't test: my IRIX and Tru64 UNIX boxes are far too slow to test anything not immediatly related ;-) I just observed this general issue and wanted to point it out to avoid introducing other instances without due consideration. > The only thing the patch should do (and seems to do on my GNU/Linux > setup) is to explicitly output a .debug_aranges section that is of the > minimum size (so not actually empty, just indicating no ranges are > covered by outputting just the table terminator). Seems I misread the patch then: I'd suspect this (instead of zero-sized sections) should be safe. Sorry for the noise. Rainer
OK. Jason
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index f3c4c09..520d7a2 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -23812,21 +23812,17 @@ dwarf2out_finish (const char *filename) } } - /* Output the address range information. We only put functions in the - arange table, so don't write it out if we don't have any. */ + /* Output the address range information if a CU (.debug_info section) + was emitted. We output an empty table even if we had no functions + to put in it. This because the consumer has no way to tell the + difference between an empty table that we omitted and failure to + generate a table that would have contained data. */ if (info_section_emitted) { unsigned long aranges_length = size_of_aranges (); - /* Empty .debug_aranges would contain just header and - terminating 0,0. */ - if (aranges_length - != (unsigned long) (DWARF_ARANGES_HEADER_SIZE - + 2 * DWARF2_ADDR_SIZE)) - { - switch_to_section (debug_aranges_section); - output_aranges (aranges_length); - } + switch_to_section (debug_aranges_section); + output_aranges (aranges_length); } /* Output ranges section if necessary. */
Hi, This PR was put on hold for a while since gdb didn't immediately need it. But the consensus seemed that it was a good idea to always output the address ranges (.debug_arange section) information if a CU (.debug_info section) was emitted. Because the consumer has no way to tell the difference between an empty table that we omitted and failure to generate a table that would have contained data. We recently discussed this again (see PR), and it still seems like a good thing. So here it a patch to just do that: 2011-04-26 Mark Wielaard <mjw@redhat.com> PR42288 * dwarf2out.c (dwarf2out_finish): Always call output_aranges () when info_section_emitted. Tested on i686-pc-linux-gnu, no changes in test results. Cheers, Mark