This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] MIPS16 FP manual call/return fixes
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org
- Date: Wed, 2 May 2012 23:28:11 +0200
- Subject: Re: [RFA] MIPS16 FP manual call/return fixes
- References: <alpine.DEB.1.10.1204231321310.19835@tp.orcam.me.uk> <87mx5y70mv.fsf@fleche.redhat.com> <alpine.DEB.1.10.1204302156230.19835@tp.orcam.me.uk> <20120501140457.GA1691@host2.jankratochvil.net> <alpine.DEB.1.10.1205011754050.18334@tp.orcam.me.uk>
On Tue, 01 May 2012 19:21:20 +0200, Maciej W. Rozycki wrote:
> OK, so let me put this another way. Here we have just returned from a
> function that we called. Obviously that function does exist somewhere no
> matter if symbol tables have been unloaded or whatever. How can we
> determine the address of that function?
We can no longer reliably do so.
> -- in a different way, presumably.
> We must have somehow established its address previously or we couldn't
> have called it. Is it possible to cache it somehow for example?
Yes, we could. In set_breakpoint_location_function is created
bp_gnu_ifunc_resolver, so cache it into 'struct bp_location' there (or even
into 'struct breakpoint', I do not see too much difference there)..
Then transfer this info when bp_gnu_ifunc_resolver_return is created from that
bp_gnu_ifunc_resolver.
I would be fine also with just some error there.
> Thanks for raising the issue of unloading symbol tables, that's an
> important point as to how MIPS16 and microMIPS symbols should be treated
> in general -- here I think it will only matter in the asynchronous mode.
No, even in synchronous mode. If you still do "stepi", "stepi", "stepi"...
you will get something like:
(gdb) start
(gdb) b strcmp
Breakpoint 2 at gnu-indirect-function resolver at 0x7ffff7aaa3d0: file ../sysdeps/x86_64/multiarch/strcmp.S, line 87.
(gdb) b *strcmp
Note: breakpoint 2 also set at pc 0x7ffff7aaa3d0.
Breakpoint 3 at 0x7ffff7aaa3d0: file ../sysdeps/x86_64/multiarch/strcmp.S, line 87.
(gdb) c
Continuing.
warning: Breakpoint 2 address previously adjusted from 0x004003c6 to 0x7ffff7aaa3d0.
Breakpoint 2, strcmp () at ../sysdeps/x86_64/multiarch/strcmp.S:87
87 cmpl $0, __cpu_features+KIND_OFFSET(%rip)
(gdb) maintenance info breakpoints
Num Type Disp Enb Address What
[...]
2 STT_GNU_IFUNC resolver keep y 0x00007ffff7aaa3d0 ../sysdeps/x86_64/multiarch/strcmp.S:87 inf 1
breakpoint already hit 1 time
3 breakpoint keep y 0x00007ffff7aaa3d0 ../sysdeps/x86_64/multiarch/strcmp.S:87 inf 1
breakpoint already hit 1 time
0 STT_GNU_IFUNC resolver return keep y 0x00007ffff7deb3be <_dl_fixup+446> inf 1 thread 1
stop only in thread 1
So you can see anything can happen now before we hit that breakpoint #0.
I can for example unload the glibc symbol file by 'nosharedlibrary' (which has
led to unrelated PR 14054 now).
Thanks,
Jan