MIPS: Handle manual calls of MIPS16 functions with a call stub
Daniel Jacobowitz
drow@false.org
Fri Feb 8 14:57:00 GMT 2008
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
More information about the Gdb-patches
mailing list