Re: [BUG] Regression in 2.14.90 (relative to 2.13.90)

[Nick Clifton <nickc at redhat dot com>]

Hi Carlo,

> The correct output would give an entry with PC = 0.  And you get
> (just like me) two entries with both a non-zero PC, which is the
> bug.  If you would *compile/link* the test case with binutils
> 2.3.90, then you would see different results, which is correct.

Ok - I think I was mistaken when I reported that the current sources
generate a non-0 address table for the discard wa2.C compilation
unit.  Looking further into the "readelf -wl" output of the a.out file
built from wa.c and wa2.c using todays gcc/binutils I get this:

     The File Name Table:
      Entry	Dir	Time	Size	Name
      1	0	0	0	wa.C
      2	0	0	0	wa.h
    
     Line Number Statements:
      Set File Name to entry 2 in the File Name Table
      Extended opcode 2: set Address to 0x8048488
      Special opcode 9: advance Address by 0 to 0x8048488 and Line by 4 to 5
      Special opcode 90: advance Address by 6 to 0x804848e and Line by 1 to 6
      Advance PC by 14 to 804849c
      Extended opcode 1: End of Sequence
    
Which looks OK, right ?  Then further down we have this:

     The File Name Table:
      Entry	Dir	Time	Size	Name
      1	0	0	0	wa2.C
      2	0	0	0	wa.h
    
     Line Number Statements:
      Set File Name to entry 2 in the File Name Table
      Extended opcode 2: set Address to 0x0
      Special opcode 9: advance Address by 0 to 0x0 and Line by 4 to 5
      Special opcode 90: advance Address by 6 to 0x6 and Line by 1 to 6
      Advance PC by 14 to 14
      Extended opcode 1: End of Sequence
    
Indicating, I think, that the discarded definition of f() has not had a
valid address range set for it.

I am attaching the entire "readelf -wl" output in case I am just
missing something obvious, or just not understanding the situation
properly.

Cheers
        Nick

Attachment: a.out.readelf.wl
Description: Output of \"readelf -wl\" run on a.out built from wa.C and wa2.C