This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Fix frame ID comparison problem on s390
- From: Ulrich Weigand <weigand at i1 dot informatik dot uni-erlangen dot de>
- To: cagney at gnu dot org (Andrew Cagney)
- Cc: weigand at i1 dot informatik dot uni-erlangen dot de (Ulrich Weigand), drow at false dot org (Daniel Jacobowitz), gdb-patches at sources dot redhat dot com
- Date: Wed, 9 Jun 2004 16:12:53 +0200 (CEST)
- Subject: Re: [PATCH] Fix frame ID comparison problem on s390
Andrew Cagney wrote:
> 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).
So, what would you recommend to solve the problem of 'wildcard zero pc'
being confused with 'NULL pointer call'? Is my original back-end hack
OK with or, or do you have another target-independent suggestion?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de