This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix unwind handling for hppa


On Sat, Apr 17, 2004 at 01:05:36AM -0700, Randolph Chung wrote:
> Frame unwinding on hppa was broken when the frame unwind started at a 
> location before the current frame is created (as noted by the comment
> below). This patch fixes it and brings the failure count on 
> hppa2.0w-hp-hpux11 down from 1000 to 668, and on hppa-linux from 2700+ 
> to 1214. still some ways to go :) 
> 
> Many thanks to Dan for patiently answering my questions.
> 
> ok to commit?

Nope, a couple of things:

> +    if (frame_relative_level (next_frame) >= 0 || 
> +        frame_pc_unwind (next_frame) >= 
> +	hppa_skip_prologue (frame_func_unwind (next_frame)))

Andrew and I just had this same discussion with MIPS.  Problems with
this line include:
  - your formatting is wrong; operators always come at the beginning
    of the line.
  - Checking the frame level is wrong.  It's wrong both in practice and
    in principle: in practice, the next frame could be a dummy frame
    or a signal frame.  There's a test case in the testsuite which
    covers this.

    In principle, the point is to unwind without magic knowledge of the
    next frame.  At least, that's what Andrew insists.  I don't think
    that I agree; I think the knowledge of whether we got from this
    frame to the next frame via a call is a legitimate piece of
    information to use during unwinding and can save a lot of
    inefficient code analysis.  But that's unsettled.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]