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

[Daniel Jacobowitz <drow at false dot org>]

On Mon, Feb 04, 2008 at 04:13:48PM +0000, Maciej W. Rozycki wrote:
>  I have tried your suggestion of using mips_pc_is_mips16() in 
> mips_write_pc(), but it only removes some of the regressions.  I think 
> your proposal could work if the LSB of MIPS16 addresses was explicitly 
> cleared throughout processing within GDB as all the DWARF-2 records 
> referring to such addresses are currently meant to have it set.  This is 
> obviously because the R_MIPS_32 relocation is used for them as well as 
> where an address of a function is taken for the purpose of making a call, 
> so all these places are treated the same by the linker and GDB is prepared 
> to it.

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.

Honestly, I'm not just trying to be difficult.  But having two targets
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.

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
mips16 tests (yet).  Should I be able to do this with just the GDB
simulator and a board file?

>  Obviously the problem in the first place is in the way the stub is 
> annotated with debugging information.  Moving it outside the block 
> describing the associated actual function breaks backtracing and 
> single-stepping quite badly if I recall correctly.

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.

> The DWARF-3 spec actually provides for such special code fragments
> by the means of the DW_AT_trampoline attribute, but GCC does not
> really have any infrastruture for handling it yet, except from
> recognising the name of the attribute.  Until that is adopted I
> think we should have means to handle stubs regardless and even once
> GCC has been updated I think older binaries should be kept supported
> by reasonable means.

I'm not suggesting that we shouldn't.

-- 
Daniel Jacobowitz
CodeSourcery