Disambiguating symbols by module

Disambiguating symbols by module

[Alexander Miloslavskiy]

Hello,

I spend much time debugging Java with GDB.

In order to obtain current Java callstack, I do this:
(gdb) call (void)ps()

The problem is, the function's name is too short and gdb confuses it 
with a variable in a different library:

(gdb) info var ^ps$
File ../../cipher/blowfish.c:
256:	static const u32 ps[18];

(gdb) info function ^ps$
Non-debugging symbols:
0x00007ffff6d7a3b0  ps

Here, the symbol I want is a non-debugging symbol. This also means that 
I can't disambiguate it by the source file name.

Is there a syntax to disambiguate the symbol?

Re: Disambiguating symbols by module

[Matt Rice]

On Thu, Sep 2, 2021 at 8:48 PM Alexander Miloslavskiy via Gdb
<gdb@sourceware.org> wrote:0x00007ffff6d7a3b0
>
> Hello,
>0x00007ffff6d7a3b0
> I spend much time debugging Java with GDB.
>
> In order to obtain current Java callstack, I do this:
> (gdb) call (void)ps()
>
> The problem is, the function's name is too short and gdb confuses it
> with a variable in a different library:
>
> (gdb) info var ^ps$
> File ../../cipher/blowfish.c:
> 256:    static const u32 ps[18];
>
> (gdb) info function ^ps$
> Non-debugging symbols:
> 0x00007ffff6d7a3b0  ps
>
> Here, the symbol I want is a non-debugging symbol. This also means that
> I can't disambiguate it by the source file name.
>
> Is there a syntax to disambiguate the symbol?

Been a while since I've needed to do this, but IIRC you can just set a
breakpoint using the symbol address too, like:

(gdb) break *0x00007ffff6d7a3b0

I don't know of or believe there is any nicer syntax like
object_file.o:symbol_name, which one could imagine might be possible.

Re: Disambiguating symbols by module

[Alexander Miloslavskiy]

On 03.09.2021 17:31, Matt Rice wrote:
> Been a while since I've needed to do this, but IIRC you can just set a
> breakpoint using the symbol address too, like:
> 
> (gdb) break *0x00007ffff6d7a3b0
> 
> I don't know of or believe there is any nicer syntax like
> object_file.o:symbol_name, which one could imagine might be possible.

Thanks!

Right, currently in order to call 'ps()' I have to manually do the 
following:

(gdb) info function ^ps$
Non-debugging symbols:
0x00007ffff6d7a3b0  ps

(gdb) call (void)0x00007ffff6d7a3b0()

That is, I manually find the address, then use it to call the function.

I'd like to avoid that extra first step somehow and have some 
address-independent command.

Re: Disambiguating symbols by module

[Matt Rice]

On Fri, Sep 3, 2021 at 2:35 PM Alexander Miloslavskiy
<alexandr.miloslavskiy@gmail.com> wrote:
>
>
>
> On 03.09.2021 17:31, Matt Rice wrote:
> > Been a while since I've needed to do this, but IIRC you can just set a
> > breakpoint using the symbol address too, like:
> >
> > (gdb) break *0x00007ffff6d7a3b0
> >
> > I don't know of or believe there is any nicer syntax like
> > object_file.o:symbol_name, which one could imagine might be possible.
>
> Thanks!
>
> Right, currently in order to call 'ps()' I have to manually do the
> following:
>
> (gdb) info function ^ps$
> Non-debugging symbols:
> 0x00007ffff6d7a3b0  ps
>
> (gdb) call (void)0x00007ffff6d7a3b0()
>
> That is, I manually find the address, then use it to call the function.
>
> I'd like to avoid that extra first step somehow and have some
> address-independent command.

I don't really know of any satisfactory solution then...
The best workaround I can come up with is to put the address in a
convience variable (which could perhaps be automated with some python
scripts in your gdbinit, to gain some address independence).

(gdb) set $ps = 0x00007ffff6d7a3b0

With that, you can at least use:
(gdb) call (void)($ps)()

I haven't tried it, but if you look at
https://sourceware.org/systemtap/wiki/MakeDoWithoutDebugInfo
Given that there is some probe support in gdb, maybe there is a way to
make use of
kprobe.module(NAME).function(FUNCTION) to get the address.

Re: Disambiguating symbols by module

[Alexander Miloslavskiy]

On 03.09.2021 17:53, Matt Rice wrote:
> I don't really know of any satisfactory solution then...
> The best workaround I can come up with is to put the address in a
> convience variable (which could perhaps be automated with some python
> scripts in your gdbinit, to gain some address independence).

Right, I think that a startup python script could work, if there are no 
better solutions. Thanks!

Re: Disambiguating symbols by module

[Martin Simmons]

>>>>> On Fri, 3 Sep 2021 17:57:42 +0300, Alexander Miloslavskiy via Gdb said:
> 
> Right, I think that a startup python script could work, if there are no 
> better solutions. Thanks!

If the short function name is just for convenience and you can rename it
to something longer, then you can define a short-named user command to
call it

define callps
call (void)the_unique_ps_function()
end

__Martin

Re: Disambiguating symbols by module

[Alexander Miloslavskiy]

On 03.09.2021 19:06, Martin Simmons wrote:
> If the short function name is just for convenience and you can rename it
> to something longer, then you can define a short-named user command to
> call it

Thanks! Unfortunately, the code I'm debugging is outside my control. 
It's the Java's JDK that comes from packet manager in Linux. The other 
symbol, which stands in my way, is also outside my control.

Re: Disambiguating symbols by module

[Christian Biesinger]

On Thu, Sep 2, 2021 at 4:49 PM Alexander Miloslavskiy via Gdb
<gdb@sourceware.org> wrote:
> Here, the symbol I want is a non-debugging symbol. This also means that
> I can't disambiguate it by the source file name.
>
> Is there a syntax to disambiguate the symbol?

The python API lets you do this:
gdb.lookup_objfile("libfoo").lookup_global_symbol("ps")

But I don't recall if you can call functions in the inferior from Python.

Christian

Re: Disambiguating symbols by module

[Alexander Miloslavskiy]

On 03.09.2021 19:25, Christian Biesinger wrote:
> The python API lets you do this:
> gdb.lookup_objfile("libfoo").lookup_global_symbol("ps")

Thanks! Unfortunately it seems that gdb does not return non-debugging 
symbols this way. I can get the offending symbol with this approach, but 
not the desired one.

Anyways, while trying that, I figured that the offending symbol comes 
from a dbgsym package that I never meant to install. It somehow slipped 
through to my machine two years ago, too late to figure how it happened. 
After uninstalling it, there is no longer the other symbol to confuse 
gdb, so I can now simply

(gdb) call (void)ps()

This means that my problem is now solved.