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]

Re: PATCH: binutils/1436: "readelf -u" doesn't work on Linux 2.6 kernel modules


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.


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