This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PATCH: binutils/1436: "readelf -u" doesn't work on Linux 2.6 kernel modules
- From: "H. J. Lu" <hjl at lucon dot org>
- To: James E Wilson <wilson at specifix dot com>
- Cc: David Mosberger-Tang <David dot Mosberger at acm dot org>,binutils at sources dot redhat dot com
- Date: Sat, 8 Oct 2005 14:21:12 -0700
- Subject: Re: PATCH: binutils/1436: "readelf -u" doesn't work on Linux 2.6 kernel modules
- References: <20051007203045.GA13941@lucon.org> <1128735914.375.88.camel@aretha.corp.specifix.com>
On Fri, Oct 07, 2005 at 06:45:14PM -0700, James E Wilson wrote:
> On Fri, 2005-10-07 at 13:30, H. J. Lu wrote:
> > * readelf.c (ABSADDR): New.
> > (dump_ia64_unwind): Use ABSADDR to get the unwind info address.
>
> The patch looks mostly OK, except it seems curious that of the 4 uses of
> tp->*.offset in that function, you only fixed one. Thus your patch
> looks incomplete. The fact that you have a macro makes it look like you
> may have tried fixing more of them and then backed off. However, I
> can't tell if the patch really is incomplete, or if you intentionally
> decided only to fix one of them.
>
> There is also the issue that tp->start is passed into
> find_symbol_for_address, and then the offset field is used without also
> using the section offset. So that code looks suspiciously wrong also,
> but it does seem to be working OK as I am getting function names in the
> output.
>
> Investigating, your patch gives consistent results with what happens
> with earlier binutils for object files, but not for executables where a
> VMA instead of an offset appears for the start and end addresses.
> However, I am seeing an offset instead of a VMA for the info address.
> So the old tools seem to be inconsistent on this, giving different
> answers for executables and object files (VMA vs section offset), and
> giving different answers for executables for start/end and info (VMA vs
> section offset).
>
> Shouldn't be just fix all of them to use the VMA and be completely
> consistent everywhere?
I checked unwind info on a few executables and shared libraries. My
modified readelf gives the same results as the old one. My patch should
only affect .o files since the section index comes from unwind
relocation. If there are no relocations in executables and shared
libraries, address == offset there.
>
> It is true that only the one place affected by your patch needs to be
> changed to avoid the core dump, as that is the only place where we
> compute an address and then dereference it.
That is correct and this is the only place where we need the address
instead of the offset.
H.J.