Re: [RFA] MIPS16 FP manual call/return fixes

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

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