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

["Jim Blandy" <jimb at red-bean dot com>]

On Feb 8, 2008 6:23 AM, Maciej W. Rozycki <macro@mips.com> wrote:
> On Mon, 4 Feb 2008, Daniel Jacobowitz wrote:
>
> > This is not how any other target that I know of handles extra PC bits.
> > I think it's going to cause a whole lot of other similar problems.  I
> > am reluctant to add new hooks to support storing additional bits in
> > addresses, when at the same time we have hooks that other targets use
> > - called from overlapping places - to remove extra bits from addresses.
>
>  Well, it is certainly the smallest change that fits the way the MIPS
> target is currently handled throughout the toolchain.  Not necessarily the
> best.
>
> > Honestly, I'm not just trying to be difficult.  But having two targets
>
>  Of course -- I would not have doubted.  I have been around for long
> enough.
>
> > solve the same problem in opposite ways makes the core of GDB a mess.
> > "Do line table entries include extra non-address bits" is not a
> > question that should have different answers on different targets.
> > Similarly for function block addresses.
>
>  Your proposal sounds clean enough for me to investigate it further.  In
> fact I have done so to some extent already.
>
> > 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.
>
>  Of course further adjustments might be needed to methods like read_pc(),
> write_pc() and unwind_pc() (I am not absolutely sure at this point yet)
> and perhaps elsewhere.  Just as a proof of concept, with some hacks to the
> DWARF-2 parser and elsewhere, including but not limited to functions
> mentioned, I got down to just three regressions compared to results with
> my proposal.  Now the question is whether a similar result may be achieved
> using properly architected code.  I'll have a look at it soon.
>
> > 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.
>
> > 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).
>
>   Maciej