[Bug gas/18390] how to tell if the dwarf line generated is for literal pools ( re bug 12974 )

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18390

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |nickc at redhat dot com

--- Comment #1 from Nick Clifton <nickc at redhat dot com> ---
Hi Raymond,

  The only way that I can think of is that the entries refer to addresses
within the .text section, but they have a $d data symbol associated with them.

  For example, using the testcase from PR 12974, the line number table of the
assembled start.o binary looks like this:

 Line Number Statements:
  [0x00000028]  Extended opcode 2: set Address to 0x0
  [0x0000002f]  Special opcode 8: advance Address by 0 to 0x0 and Line by 3 to
4
  [0x00000030]  Special opcode 34: advance Address by 4 to 0x4 and Line by 1 to
5
  [0x00000031]  Special opcode 34: advance Address by 4 to 0x8 and Line by 1 to
6
  [0x00000032]  Special opcode 34: advance Address by 4 to 0xc and Line by 1 to
7
  [0x00000033]  Special opcode 34: advance Address by 4 to 0x10 and Line by 1
to 8
  [0x00000034]  Special opcode 34: advance Address by 4 to 0x14 and Line by 1
to 9
  [0x00000035]  Special opcode 36: advance Address by 4 to 0x18 and Line by 3
to 12
  [0x00000036]  Special opcode 37: advance Address by 4 to 0x1c and Line by 4
to 16
  [0x00000037]  Special opcode 34: advance Address by 4 to 0x20 and Line by 1
to 17
  [0x00000038]  Special opcode 34: advance Address by 4 to 0x24 and Line by 1
to 18
  [0x00000039]  Advance Line by -14 to 4
  [0x0000003b]  Special opcode 33: advance Address by 4 to 0x28 and Line by 0
to 4
  [0x0000003c]  Special opcode 41: advance Address by 4 to 0x2c and Line by 8
to 12
  [0x0000003d]  Special opcode 37: advance Address by 4 to 0x30 and Line by 4
to 16

The entries at 0x00000039 .. 0x0000003d refer to the literal pool.  If you look
at the symbol table for start.o then you will see:

  00000000 t $a
  00000028 t $d

Ie addresses 0x0 .. 0x27 contain code, but address 0x28 onwards contain data.  

I hope that this helps.

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.