Re: Latest readelf change broke (generally) readelf -s

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Nov 06, 2002 at 06:59:36PM +0100, Hans-Peter Nilsson wrote:
> I think for all targets, and particularly ld-cris/libdso-2.d for
> cris-axis-linux-gnu:
> 
> Running /home/hp/binutils/cvs_latest/src/binutils/testsuite/binutils-all/readelf.exp ...
> Version /dsk/c0t3s2/hptmp2/autobuildbinu/binu/binutils/readelf 20021106
> FAIL: readelf -s
> ...
> Running /home/hp/binutils/cvs_latest/src/ld/testsuite/ld-cris/cris.exp ...
> FAIL: ld-cris/libdso-2
> 
> I don't really see the need for readelf formatting changes like
> this, corresponding to this snippet from ld.log for readelf -s:
> 
> regexp "^     1: 00000000     0 SECTION LOCAL  DEFAULT    1 $"
> line   "     1: 00000000     0 SECTION LOCAL  DEFAULT 0x0001 "
> 
> It was caused by this:
> 
> 2002-11-06  Hiroyuki Machida  <machida@sm.sony.co.jp>
> 
> 	* readelf.c (get_symbol_index_type): Add hex number to
> 	PROCESSOR-specific, OS-specific, reserved and unknown symbol
> 	types.
> 
> People *will* depend on readelf formatting -- even outside the
> testsuite. ;-|   I'll fix ld-cris/libdso-2.d.

People already depend on it in lots of scripts.
IMNSHO the "%3d" -> "0x%04x" change should be reverted.
Typically there are just a few sections and then 
   104: 4206eee0   168 FUNC    GLOBAL DEFAULT   11 _IO_default_finish@@GLIBC_2.0
is more readable than:
   104: 4206eee0   168 FUNC    GLOBAL DEFAULT 0x000b _IO_default_finish@@GLIBC_2.0
Also, in readelf -S section header numbers are printed in decimal and having
to translate in your mind hex to decimal or back when finding what symbol
is in what section is a nightmare.

	Jakub