Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de>
Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Fix frame ID comparison problem on s390
Date: Mon, 24 May 2004 18:52:00 -0000	[thread overview]
Message-ID: <40B24476.6070605@gnu.org> (raw)
In-Reply-To: <200405241345.PAA26969@faui1d.informatik.uni-erlangen.de>

Daniel Jacobowitz wrote:


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.


I have no idea -- maybe this is obsolete by now?

The following patch simply removes the wild card feature, and it works
for s390 without test suite regressions (and fixes the signull failure
as well).
I've tried to look at the other platforms, but they appear not to be
using the wild card feature either ...
Symbol table code often returns 0 to indicate a failed lookup (here a 
search for the function containing pc).  That zero can end up in the 
frame ID.  Look at calls to get_frame_func / frame_func_unwind (which 
I've proposed eliminating).

From memory architectures that do not implement dummy ID unwind also 
end up with wild-card IDs (fortunatly the dummy-frame code works around 
this).

Broken tramp unwinders often leave the .code address zero (see paragraph 
#1 for why).

Andrew




  reply	other threads:[~2004-05-24 18:52 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
2004-05-24 13:45   ` Ulrich Weigand
2004-05-24 18:52     ` Andrew Cagney [this message]
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=40B24476.6070605@gnu.org \
    --to=cagney@gnu.org \
    --cc=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