From: "Maciej W. Rozycki" <macro@mips.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sourceware.org, "Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: MIPS: Handle manual calls of MIPS16 functions with a call stub
Date: Mon, 04 Feb 2008 16:14:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.61.0802041149560.28589@perivale.mips.com> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2008-02-04 16:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-31 18:14 Maciej W. Rozycki
2008-01-31 22:08 ` Daniel Jacobowitz
2008-02-01 10:27 ` Maciej W. Rozycki
2008-02-01 14:19 ` Daniel Jacobowitz
2008-02-01 15:34 ` Maciej W. Rozycki
2008-02-01 16:58 ` Daniel Jacobowitz
2008-02-01 17:07 ` Maciej W. Rozycki
2008-02-01 17:15 ` Daniel Jacobowitz
2008-02-04 16:14 ` Maciej W. Rozycki [this message]
2008-02-04 16:39 ` Daniel Jacobowitz
2008-02-08 14:23 ` Maciej W. Rozycki
2008-02-08 14:57 ` Daniel Jacobowitz
2008-02-08 18:06 ` Jim Blandy
2008-02-08 18:08 ` Jim Blandy
2008-02-13 18:28 ` Maciej W. Rozycki
2008-02-13 20:54 ` Jim Blandy
2008-02-15 11:36 ` Maciej W. Rozycki
2008-02-18 13:32 ` Nigel Stephens
2008-02-18 16:28 ` Maciej W. Rozycki
2008-02-19 19:48 ` Michael Snyder
2008-02-22 16:38 ` Jim Blandy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.61.0802041149560.28589@perivale.mips.com \
--to=macro@mips.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=macro@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox