Re: MIPS: Handle manual calls of MIPS16 functions with a call stub

[Daniel Jacobowitz <drow@false.org>]

On Fri, Feb 08, 2008 at 02:23:03PM +0000, Maciej W. Rozycki wrote:
> > I think that using mips_pc_is_mips16 can be made to work, by analogy
> > to ARM.  I'd look at this myself, but I don't think I'm set up to run
> 
>  It is much more than that, but I think it can be done with some 
> adjustments to pointer_to_address(), address_to_pointer() and 
> integer_to_address() methods.  If DWARF-2 records could be treated as 
> pointers (which they are given how the linker processes them) rather than 
> addresses then such a setup should work.  That should be done above the 
> level of the DWARF-2 interpreter, as losing the LSB from relative data 
> often contained in records would result in an accumulative error.

Hmm.  This sounds believable, but it may react badly with other
platforms.  We'll have to experiment.

> > mips16 tests (yet).  Should I be able to do this with just the GDB
> > simulator and a board file?
> 
>  I have attached the "mips-sim-sde32" board description file I use and the 
> necessary linker script.  You should be able to use it, though there may 
> be pitfalls.  When running tests you need -Wa,-O0 to disable branch 
> swapping as it makes MIPS16 code inconsistent with DWARF-2 information in 
> a fatal way.

Thanks.

> > I don't understand.  The stub is not annotated with debug information
> > in the example you posted earlier in the thread.  It's only "inside
> > the block" physically in the assembly file and for the purposes of
> > confusing gas (it probably puts the symbol and first instruction in
> > different frags, the first of which is zero length, breaking whatever
> > gas uses to annotate the symbol value).  It's not covered by the range
> > [.LFB20, .LEB20] because those labels are in the text section.
> 
>  It is still covered by the .loc directive and therefore recognised to be 
> a part of the code corresponding to the first line of the function.  It 
> makes single-stepping through it possible -- including correct frame 
> discovery as required by `nexti'/`step'/`next' (not `stepi' though).

This makes more sense, but not quite... I see how the .loc covers it.
That should get it into .debug_line.  However it shouldn't affect the
symbol table, or the frame unwinders... I must be missing something,
but I'll figure it out eventually.

-- 
Daniel Jacobowitz
CodeSourcery