Re: [RFA] MIPS/GDB: Fix the handling of MIPS16 thunks

[Richard Sandiford <rdsandiford@googlemail.com>]

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> On Wed, 11 Apr 2012, Richard Sandiford wrote:
>> > [Richard, I've cc-ed you as the MIPS port maintainer of GCC and binutils, 
>> > the producers of MIPS16 and some other thunks covered here, in case you 
>> > had anything to add, and just so that you know this issue is being 
>> > addressed now.]
>> 
>> Sounds like great work, thanks.  Hope it goes in.
>
>  Well, there's only this small issue of gdbarch_in_solib_return_trampoline 
> -- it shouldn't be too hard to overcome. :)
>
>> I don't really have anything constructive to say, but just out of
>> curiosity: we "fixed" call/return stubs to have unwind information for
>> GCC 4.7.  Do you happen to know whether the test passes with that change?
>
>  I am not completely sure as I haven't tried it/got to 4.7 yet (you may 
> remember I had troubles building the head of the tree; I saw you fixed 
> that at some point, thanks), but it looks to me the generic trampoline 
> stuff I rely on here is tangential to any particular frame unwinders (as 
> long as they get their details right, of course, which may not necessarily 
> be true in all cases, as it is with the heuristic unwinders), so it should 
> keep working.  I'll see if I can get to verifying this soon.
>
>  Did you actually add this unwind information for both the mips16.S pieces 
> and the compiler generated bits

Yes.  But like I say, the fix was only (suppoed to be) for what you
called call/return stubs, i.e. those in which the stub JALs to the target,
fiddles with the return value afterwards, then JRs back to the caller.
It wasn't intended to touch pure "run this code first" stubs like...

> (how about the PIC stubs produced by LD?)?  

...these.

> Does that happen to address the problem I reported here:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01067.html

'Fraid not.  It was a separate problem.

Richard