DWARF2 line number problem

DWARF2 line number problem

[Martin M. Hunt]

I have a problem and I'm not sure what the correct solution would be. 

I'm looking at gcc mips output.  The compilation unit says pointer size is 4, 
but the DWARF line section is setting the address to a sign-extended 8-byte 
value.  GDB cleverly ignores the actual size of the extended opcode and reads 
a 4-byte value then starts parsing the rest of the bytes as line opcodes!

Is it OK for DWARF to have 8-byte sign-extended addresses in a CU where the 
pointer size is 4 bytes?

How to fix GDB?  The problem is in dwarf_decode_lines() and there is even a 
comment documenting the bug ("ignore length").

           case DW_LNS_extended_op:
	      line_ptr += 1;	/* ignore length */
	      extended_op = read_1_byte (abfd, line_ptr);
	      line_ptr += 1;

Obviously we must check the length.  If we decide we must accept 8-byte 
lengths, then I guess we simply advance the pointer by 4 bytes before reading 
(for big-endian) or after reading (for little endian).  Any better 
suggestions?

-- 
Martin Hunt
GDB Engineer
Red Hat, Inc.

Re: DWARF2 line number problem

[Jim Blandy]

"Martin M. Hunt" <hunt@redhat.com> writes:

> I have a problem and I'm not sure what the correct solution would be. 
> 
> I'm looking at gcc mips output.  The compilation unit says pointer
> size is 4, but the DWARF line section is setting the address to a
> sign-extended 8-byte value.  GDB cleverly ignores the actual size of
> the extended opcode and reads a 4-byte value then starts parsing the
> rest of the bytes as line opcodes!

Could you compile your program with -save-temps -dA, and post the
assembly code?

Re: DWARF2 line number problem

[Martin M. Hunt]

On Tuesday 20 August 2002 10:13 pm, you wrote:
> "Martin M. Hunt" <hunt@redhat.com> writes:
> > I have a problem and I'm not sure what the correct solution would be.
> >
> > I'm looking at gcc mips output.  The compilation unit says pointer
> > size is 4, but the DWARF line section is setting the address to a
> > sign-extended 8-byte value.  GDB cleverly ignores the actual size of
> > the extended opcode and reads a 4-byte value then starts parsing the
> > rest of the bytes as line opcodes!
>
> Could you compile your program with -save-temps -dA, and post the
> assembly code?

I'll send it to you if you want, but the problem  is not there.

The problem appears to be either GAS or GDB depending on how we interpret the 
DWARF spec. 

GAS calculates the size of addresses to put in the line table from  
bfd_arch_bits_per_address() which returns 64 even though in the case of o32 
we are using a 32-bit ABI.  gas is passed "-32" on its command line, so 
perhaps it should be using this?

I am wondering why no one else has run into this problem?  Maybe I am missing 
something?  


-- 
Martin Hunt
GDB Engineer
Red Hat, Inc.

Re: DWARF2 line number problem

[Jim Blandy]

"Martin M. Hunt" <hunt@redhat.com> writes:
> On Tuesday 20 August 2002 10:13 pm, you wrote:
> > "Martin M. Hunt" <hunt@redhat.com> writes:
> > > I have a problem and I'm not sure what the correct solution would be.
> > >
> > > I'm looking at gcc mips output.  The compilation unit says pointer
> > > size is 4, but the DWARF line section is setting the address to a
> > > sign-extended 8-byte value.  GDB cleverly ignores the actual size of
> > > the extended opcode and reads a 4-byte value then starts parsing the
> > > rest of the bytes as line opcodes!
> >
> > Could you compile your program with -save-temps -dA, and post the
> > assembly code?
> 
> I'll send it to you if you want, but the problem  is not there.
> 
> The problem appears to be either GAS or GDB depending on how we
> interpret the DWARF spec.

In Dwarf 2, the size of an operand to DW_LNE_set_address is determined
by the `address_size' field of the compilation unit header.  If GDB
isn't using that value, then it's a GDB bug.  If GAS is putting one
size in the compilation unit header, and using a different size when
emitting line number information, then that's a GAS bug.