Re: [PATCH] Tiny 64-bit Dwarf2 glitch

[Daniel Berlin <dberlin at dberlin dot org>]

On Tuesday, June 25, 2002, at 04:15  PM, Jason Eckhardt wrote:

> On Tue, 25 Jun 2002, Kevin Buettner wrote:
>
> > >     /* Read in the prologue.  */
> > > !   lh.total_length = read_4_bytes (abfd, line_ptr);
> > > !   line_ptr += 4;
> > > !   offset_size = 4;
> > > !   if (lh.total_length == 0xffffffff)
> > Why are you eliminating the escape mechanism that indicates 64-bit
> > offsets?
>   Note that I didn't eliminate it, I replaced it with a check of
>   unit->addr_size. I chose to do this because:
>   1. The "escape mechanism" isn't working for at least one back-end
>      (elf64-bigmips). That is, it isn't returning 0xffffffff to
>      indicate 64-bit offsets (this probably needs investigating too,
>      but it is peripheral to what I'm currently trying to solve).
No, it's not.
The dwarf2 64bit extensions that are used by MIPS specify that it should.

>   2. Even if it did work, I believe the new check is more explanatory/
>      explicit than checking if read_4_bytes returned some hard-coded
>      escape constant value. If this is incorrect, or undesirable,
>      please explain why.
Because we don't know at that point what the unit address size is for that unit! The length comes *before* the unit, not *after* it. We can't look at some previous CU to determine whether *this* unit is 64 bit or not.
You are assuming it's a file of *all* 64bit dwarf2, or *all* 32bit dwarf2.  The 0xffffffff is there specifically so you can mix the two, and know what's up.
The hard-coded escape value is the standardized way that this is done.
http://www.eagercon.com/dwarf/issues/991102-1.htm

>   But setting that issue aside, the original code appears bogus
>   (even assuming the escape mechanism works):
>
>     /* Read in the prologue.  */
>     lh.total_length = read_4_bytes (abfd, line_ptr);
>     line_ptr += 4;
>     offset_size = 4;
>     if (lh.total_length == 0xffffffff)
>       {
>         lh.total_length = read_8_bytes (abfd, line_ptr);
>         line_ptr += 8;
>         offset_size = 8;
>       }
>
>   Can you see the obvious problem?
No, it's actually correct.
"
p52
p77 .debug_line
        Per compilation unit if the length field is the
        distinguished value 0xffffffff then
        the following value is the 64bit true length
        followed by the 16 bit version and the 64 bit
        prolog length.

        In other words, given the distinguished value,
        the 'uword' and 'sword' are 64 bits.
"

So
/*Read length */
total length = read_4_bytes(line_ptr);
/* No matter what, move 4 bytes ahead, since we are either done with the length, or need to the read the next 8 bytes to get the 64 bit length, as per the standard */
line_ptr += 4;
/* AFAWK, the offset is size 4 */
offset_size = 4;
/* If it was the special value */
if (length == 0xffffffff)
{
/* Read the next 8 bytes */
	total length = read_8_bytes (line_ptr);
  	/* Move past it */
line_ptr += 8
/* Set the offset size */
	offset size = 8
}

>   The current patch solved my problem for both 32 and 64-bit ELF64/mips
>   binaries, whereas the original code fails miserably.
It shouldn't solve *anything*, actually.
Its broken.

>   If someone has a better way to correct the defect, please let me know.
>   This defect prevents a binary analysis tool I'm working on from
>   functioning properly.