From: Andrew Cagney <cagney@gnu.org>
To: Randolph Chung <randolph@tausq.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfa] hppa-linux target, 2nd try
Date: Wed, 28 Apr 2004 20:53:00 -0000 [thread overview]
Message-ID: <409019E1.9060704@gnu.org> (raw)
In-Reply-To: <20040428160005.GO3965@tausq.org>
>>>+static struct insn_pattern hppa_sigtramp[] = {
>>>> >+ /* ldi 0, %r25 or ldi 1, %r25 */
>>>> >+ { 0x34190000, 0xfffffffd },
>>>> >+ /* ldi __NR_rt_sigreturn, %r20 */
>>>> >+ { 0x3414015a, 0xffffffff },
>>>> >+ /* be,l 0x100(%sr2, %r0), %sr0, %r31 */
>>>> >+ { 0xe4008200, 0xffffffff },
>>>> >+ /* nop */
>>>> >+ { 0x08000240, 0xffffffff },
>>>> >+ { 0, 0 }
>>>> >+};
>>
>>>
>>> hmm, perhaps the mask can be integrated into tramp-frame.[hc], anyone?
>
>
> well, hppa still can't use it because of the variable offset in the
> stack frame to locate the trampoline :(
As with the following comment?
> +/* (This is derived from MD_FALLBACK_FRAME_STATE_FOR in gcc.)
> +
> + Unfortunately, because of various bugs and changes to the kernel,
> + we have several cases to deal with.
> +
> + In 2.4, the signal trampoline is 4 bytes, and pc should point directly at
> + the beginning of the trampoline and struct rt_sigframe.
> +
> + In <= 2.6.5-rc2-pa3, the signal trampoline is 9 bytes, and pc points at
> + the 4th word in the trampoline structure. This is wrong, it should point
> + at the 5th word. This is fixed in 2.6.5-rc2-pa4.
> +
> + To detect these cases, we first take pc, align it to 64-bytes
> + to get the beginning of the signal frame, and then check offsets 0, 4
> + and 5 to see if we found the beginning of the trampoline. This will
> + tell us how to locate the sigcontext structure.
> +
> + Note that with a 2.4 64-bit kernel, the signal context is not properly
> + passed back to userspace so the unwind will not work correctly. */
The method is passed the start address of the trampoline vis:
/* Initialize a trad-frame cache corresponding to the tramp-frame.
FUNC is the address of the instruction TRAMP[0] in memory. */
void (*init) (const struct tramp_frame *self,
struct frame_info *next_frame,
struct trad_frame_cache *this_cache,
CORE_ADDR func);
and from that it should be possible to compute the offset.
Andrew
prev parent reply other threads:[~2004-04-28 20:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-24 19:26 Randolph Chung
2004-04-25 0:25 ` Joel Brobecker
2004-04-25 0:30 ` Randolph Chung
2004-04-28 15:54 ` Andrew Cagney
2004-04-25 6:07 ` Randolph Chung
2004-04-28 15:58 ` Andrew Cagney
2004-04-28 16:00 ` Randolph Chung
2004-04-28 20:53 ` Andrew Cagney [this message]
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=409019E1.9060704@gnu.org \
--to=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=randolph@tausq.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