This is the mail archive of the
mailing list for the binutils project.
Re: ppc32/objdump : retrieving the symbol's name behind the GOT offset ?
- From: "yon ar c'hall" <yon dot ar dot chall at gmail dot com>
- To: Cary Coutant <ccoutant at google dot com>, "yon ar c'hall" <yon dot ar dot chall at gmail dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Sat, 11 Jan 2014 10:58:36 +0100
- Subject: Re: ppc32/objdump : retrieving the symbol's name behind the GOT offset ?
- Authentication-results: sourceware.org; auth=none
- References: <CAOJvutOWO-bzLnZQiCM9_xFjP++DKMCZ-1pEZHp_By_jyEmaNQ at mail dot gmail dot com> <CAHACq4pinZpJLbJ5_5v9Ap7VSOGmQ8sVLbDBi7kBb4z0bBz=qg at mail dot gmail dot com> <20140110232507 dot GC5390 at bubble dot grove dot modra dot org>
On Sat, Jan 11, 2014 at 12:25 AM, Alan Modra <firstname.lastname@example.org> wrote:
> On Fri, Jan 10, 2014 at 03:08:53PM -0800, Cary Coutant wrote:
>> > When it's related to the access to an object via the GOT,
>> > objdump/ppc32 produces such disassembled code :
>> > lwz r9,-32764(r30)
>> > Is there any mean (with objdump, or any other tool) for quickly
>> > retrieving the corresponding real symbol's name of the targeted object
>> > (local or global) ?
>> You'll need to scan the dynamic relocations for the relocation that
>> applies to that particular GOT entry. That relocation will give you
>> the symbol table index (in .dynsym) of the corresponding symbol.
> Yeah, that's what I do by hand. It's particularly messy with
> -mminimal-toc code (ie. two levels of GOT). In that case r30 isn't
> pointing at _GLOBAL_OFFSET_TABLE_ so it's not a matter of simply
> looking at _GLOBAL_OFFSET_TABLE_ - 32764. You need to first find
> the r30 value..
Gasp, tricky indeed... Would -mminimal-toc be the only pitfall of its kind ?