From: Daniel Jacobowitz <drow@false.org>
To: Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Fix frame ID comparison problem on s390
Date: Thu, 20 May 2004 14:17:00 -0000 [thread overview]
Message-ID: <20040520141707.GB12221@nevyn.them.org> (raw)
In-Reply-To: <200405201331.PAA24924@faui1d.informatik.uni-erlangen.de>
On Thu, May 20, 2004 at 03:31:56PM +0200, Ulrich Weigand wrote:
> Hello,
>
> even after the siglongjmp patch, there was still one failure reported
> with the signull test case on s390(x).
>
> The reason turned out to be a problem with frame ID comparison. In
> the back trace we have
> handler
> <sigtramp>
> <NULL call>
> caller
>
> As the NULL call doesn't set up a stack frame, and because our CFA is
> determined by stack pointer at function entry, this means that the
> NULL call frame and the sigtramp frame have the same 'stack_addr'
> component of their respective frame IDs.
>
> Furthermore, the NULL call frame has 0 as 'code_addr' component of the
> frame ID, because the current PC is in fact 0.
>
> Due to the way frame ID comparison works, this causes the two IDs to
> compare equal: the stack_addr is equal, and a zero code_addr is
> considered a wild card matching any code_addr.
>
> This in turn causes the backtrace to abort since it encounters two
> frames with the same frame ID ...
I think the only reason this doesn't happen on i386 is that we appear
to use the SP at function entry rather than the SP at the call site,
and there's an implicit push of the return address.
Rather than cheat in the backend - most other backends will probably
have the same issue - I'd like to know what's actually using the code
wildcard.
--
Daniel Jacobowitz
next prev parent reply other threads:[~2004-05-20 14:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-20 13:31 Ulrich Weigand
2004-05-20 14:17 ` Daniel Jacobowitz [this message]
2004-05-24 13:45 ` Ulrich Weigand
2004-05-24 18:52 ` Andrew Cagney
2004-06-09 14:12 ` Ulrich Weigand
2004-06-09 14:55 ` Andrew Cagney
2004-06-16 13:48 ` Ulrich Weigand
2004-06-16 17:33 ` Andrew Cagney
2004-06-27 20:48 ` Ulrich Weigand
2004-06-27 21:48 ` Daniel Jacobowitz
2004-06-27 22:35 ` Ulrich Weigand
2004-06-27 22:59 ` Andreas Schwab
2004-06-27 23:11 ` Daniel Jacobowitz
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=20040520141707.GB12221@nevyn.them.org \
--to=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=weigand@i1.informatik.uni-erlangen.de \
/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