This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: MIPS: Handle manual calls of MIPS16 functions with a call stub
- From: "Maciej W. Rozycki" <macro at mips dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb-patches at sourceware dot org, "Maciej W. Rozycki" <macro at linux-mips dot org>
- Date: Mon, 4 Feb 2008 16:13:48 +0000 (GMT)
- Subject: Re: MIPS: Handle manual calls of MIPS16 functions with a call stub
- References: <Pine.LNX.4.61.0801311703570.22816@perivale.mips.com> <20080131220315.GC5085@caradoc.them.org> <Pine.LNX.4.61.0802011009460.14889@perivale.mips.com>
On Fri, 1 Feb 2008, Maciej W. Rozycki wrote:
> > elsewhere)? Maybe mips_write_pc should use mips_pc_is_mips16; that's
> > how Thumb works, by always consulting the minimal symbol table to find
> > out whether an address should be called as MIPS16 or MIPS32.
>
> The ABI is different, so it is not enough to set the PC correctly -- more
> about it in the patch that is going through my regression testing at the
> moment. Though perhaps the other places could use mips_pc_is_mips16()
> too. On the other hand I feel setting the block's start address correctly
> is the right way to make the handling consistent throughout -- by using
> mips_pc_is_mips16() here and there some places may be omitted by accident.
> Hmm...
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.
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. 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.
Please note that for MIPS16 we have return stubs too. ;-)
Maciej