From mboxrd@z Thu Jan  1 00:00:00 1970
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
Message-id: <40B24476.6070605@gnu.org>
References: <200405241345.PAA26969@faui1d.informatik.uni-erlangen.de>
X-SW-Source: 2004-05/msg00690.html

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