Re: readelf patch

[Nick Clifton <nickc at redhat dot com>]

Hi Dean,

> I have been using readelf recently, and have found some problems
> with it. Included with this email are the following changes:

Thanks for reporting this problems and supplying a patch to fix them.
I have checked in the patch along with this ChangeLog entry:

  binutils/ChangeLog
  2004-04-01  Dean Luick <luick@cray.com>

	* readelf.c (display_debug_pubnames): Align offset and data
	columns.
	(read_and_display_attr_value): Add missing break;
	(debug_displays): Enable the display of the .debug_pubtypes
	section.


> Problems noted but not fixed are:
> o There are many places in readelf where the upper 32 bits of a 64 bit value
>   are lost because the holder is a "long".  This only happens when reading
>   DWARF64 on a 32-bit machine.
> o Printing a 64-bit value by using two successive 32-bit read/print pairs
>   (e.g. when printing DW_FORM_ref8) doesn't produce a correct/good looking
>   result unless the target is big-endian.
>
> The above items were not fixed because of the lack of a known 64-bit value.
> E.g. uint64_t.  Is there a "correct" one to use?  bfd_vma doesn't seem like
> the right thing because it can be 32 bits.  Plus, the code is organized in
> such a manner as to imply that 64 bit support may not be present.

Correct - readelf should be able to work on a 32-bit host where the
host compiler does not support 64-bit types.  This is probably quite a
rare scenario, so it is quite likely that code enclosed in #ifdef BFD64...#endif
will be executed.  So using #ifdef BFD64 along with the bfd_vma type
should work.

Cheers
        Nick