This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Word size confusion in display_debug_ranges() in binutils-2.18/binutils/dwarf.c


Whilst messing with readelf -wR I noticed what looks to me like a
confusion in word sizes between the host and that pertaining to the
ELF file whose .debug_ranges section is to be displayed.  Specifically:

I built binutils-2.18 as 64-bit executables (on Core 2)

I did "readelf -wR" using said build, to examine .debug_ranges
sections in both 32-bit and 64-objects.

The problem is to do with the detection of so-called "base address"
specifiers in the range list info.  For a 64-bit object I get 

    Offset   Begin    End
    00000000 ffffffffffffffff 00000000 (base address)

which is correct, but on a 32-bit object

    Offset   Begin    End
    00000000 ffffffff 00000000 (start > end)

It should say "(base address)" instead of "(start > end)".

Looking at binutils-2.18/binutils/dwarf.c:2780 it's obvious why:

              /* Check base address specifiers.  */
              if (begin == -1UL && end != -1UL)
                {
                  base_address = end;
                  printf ("    %8.8lx %8.8lx %8.8lx (base address)\n",
                          offset, begin, end);
                  continue;
                }

Comparison against -1UL is at the host's word size.  But the DWARF3 spec
sec 2.17.3 ("Non-Contiguous Address Ranges") gives the impression, although
does not make it absolutely clear, that said values (begin, end) have a word 
size appropriate for the object file, not the host.

It would also mean that lines 2769, 2771 are bogus:

             begin = byte_get (start, pointer_size);

              end = byte_get (start, pointer_size);

begin and end are declared as unsigned long (== host word),
so these can only be correct when pointer_size == sizeof(unsigned long).

I attach two simple executables for testing purposes, 32-bit and 64-bit
versions of the same thing (test errs1.c from the Valgrind sources).
On a 64-bit platform, readelf -wR errs1-32 produces the result
below, with the incorrect "(start > end)" comment.

J

Contents of the .debug_ranges section:

    Offset   Begin    End
    00000000 ffffffff 00000000 (start > end)
    00000000 08048334 0804835a
    00000000 080482b0 080482bb
    00000000 080484fc 0804850f
    00000000 <End of list>
    00000028 ffffffff 00000000 (start > end)
    00000028 080482c5 080482c7
    00000028 08048514 08048518
    00000028 <End of list>

Attachment: errs1-32.bz2
Description: BZip2 compressed data

Attachment: errs1-64.bz2
Description: BZip2 compressed data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]