PATCH: Output dwarf debug info only when needed

H . J . Lu hjl@lucon.org
Tue Jun 11 15:12:00 GMT 2002


On Tue, Jun 11, 2002 at 06:00:38PM -0400, Daniel Jacobowitz wrote:
> On Tue, Jun 11, 2002 at 02:45:56PM -0700, H . J . Lu wrote:
> > On Tue, Jun 11, 2002 at 02:07:43PM -0700, Richard Henderson wrote:
> > > On Tue, Jun 11, 2002 at 01:59:43PM -0700, H . J . Lu wrote:
> > > >    /* If no debug information was recorded, nothing to do.  */
> > > > -  if (all_segs == NULL && files_in_use <= 1)
> > > > +  if (all_segs == NULL
> > > > +      && (debug_type != DEBUG_DWARF2 || files_in_use <= 1))
> > > 
> > > This is wrong.  When the compiler is emitting .file and .loc
> > > directives, debug_type == DEBUG_NONE.
> > > 
> > 
> > I don't know what I was thinking :-). How about this patch?
> 
> Oddly, even without this patch the extra .file information is not put
> into a section.  I'd rather know why not before changing this... it's
> not obvious to me.

# cat f.s
        .file 1 "f.c"
# gcc -f c.s
# readelf -S f.o 
There are 8 section headers, starting at offset 0x90:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf
Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0
0
  [ 1] .text             PROGBITS        00000000 000034 000000 00  AX  0   0
4
  [ 2] .data             PROGBITS        00000000 000034 000000 00  WA  0   0
4
  [ 3] .bss              NOBITS          00000000 000034 000000 00  WA  0   0
4
  [ 4] .debug_line       PROGBITS        00000000 000034 000021 00      0   0
1
  [ 5] .shstrtab         STRTAB          00000000 000055 000038 00      0   0
1
  [ 6] .symtab           SYMTAB          00000000 0001d0 000050 10      7   5
4
  [ 7] .strtab           STRTAB          00000000 000220 000001 00      0   0
1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

The .debug_line section shouldn't be necessary.


H.J.



More information about the Binutils mailing list