Re: Error in readelf...

[Nick Clifton <nickc at cygnus dot com>]

Hi Scott,

: To be honest, I'm not sure this is a bug in readelf, or it is exposing a bug in
: one of the other tools or bfd.  It doesn't seem to be ARM specific however.
: 
: readelf -s /usr/X11R6/bin/XF86_SVGA
: 
: The program starts to dump its output and dies with the following error:
: 
: readelf: Error: Unable to seek to e5ac3c48 for version need aux (3)

: I had a breakpoint on the call to error in GET_DATA.  When it stopped I got the
: following results on my NetWinder:
: 
: (gdb) p vna_off
: $18 = 0xe5ac3c48
: (gdb) p offset
: $19 = 0x26fcc
: (gdb) p ivn.vn_aux
: $20 = 0x10
: 
: These numbers make no sense to me.  I currently distrust my debugger as I'm also
: actively debugging it.

Actually the problem is with the vna_next field being added to vna_off
at the end of the loop:

			      do
				{
				  Elf_External_Vernaux  evna;

				  GET_DATA (vna_off, evna,
					    "version need aux (3)");

				  ivna.vna_other = BYTE_GET (evna.vna_other);
				  ivna.vna_next  = BYTE_GET (evna.vna_next);
				  ivna.vna_name  = BYTE_GET (evna.vna_name);

				  vna_off += ivna.vna_next;
				}

When the code gets into difficulty, ivna.vna_next is 0xe353000f.
In fact both the vernaux record that is being decoded and the one
before it both look rather odd:

            Hash       Flags   Other   Name        Next
           --------------------------------------------------
1st entry: 0xbffff9c4  0xf8f0  0xa     0x02217364  0x000acf14
2nd entry: 0xbffff9c4  0xf8f0  0xe284  0xe200300f  0xe353000f


My problem is that I do not know what values these entries are
supposed to contain, so I do not know which, if any, of them are
corrupt.


: I can reproduce the problem with any of the X servers on
: my NetWinder.  I can also reproduce the problem on medusa.armlinux.org (its a
: Acorn Risc PC running Debian ARM Linux) using /usr/X11R6/bin/XF68_FBDev as
: well.  Rod has tried it on his Intel Red Hat boxes, and can reproduce the
: problem there.

Hmm, well I cannot reproduce the problem on my Red Hat box using the
XF86_FBDev installed there, but if I run it on a copy of XF68_FBDev
from your machine, I do get the problem.  This leads me to suggest that
maybe your copy is corrupt somehow ?  [Although the file names are
different.  Yours is "68" mine is "86".  Is this significant ?]

You could add extra code to test to see if 'vna_off' has been moved
outside of the section that is currently being dumped, although you
then have to start adding a whole slew of extra checks in the code
further on too.  (Believe me - I tried it).

Cheers
	Nick