Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: Randolph Chung <randolph@tausq.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] Fix unwind handling for hppa
Date: Wed, 21 Apr 2004 21:53:00 -0000	[thread overview]
Message-ID: <4086ED46.2050809@gnu.org> (raw)
In-Reply-To: <20040421151820.GI17842@tausq.org>

>>> For an example, look
>>> at the s390's stub unwinder.
> 
> 
> hrm, afaict s390 used the same idea as in my original patch -- because
> it can be unwinding in the epilogue (or in the prologue in hppa's case)
> only in the innermost frame, it only checks this case when 
> frame_relative_level (frame) < 0 ....

I ment s390_stub_*.  (I didn't realise that a call to 
frame_relative_level had snuck back into -tdep code, sigh).   Which 
tries to identify frameless (not frame pointer) stackless (no allocated 
stack) leaf functions and thunk code.

> what am i missing?
> 
> anyway i've rewritten it so it doesn't do this... instead it stops
> prologue analysis after it hits the pc like several other targets, and
> uses this to adjust the sp/pc values.

I actually thought I had the HP code already stopping at PC, oops.

> is this one better? i'm not very sure the "read_register()" call below
> is correct. (i.e. should i be going through the regcache or something?)

See comments below.

> Index: hppa-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
> retrieving revision 1.147
> diff -u -p -r1.147 hppa-tdep.c
> --- hppa-tdep.c	17 Apr 2004 17:41:10 -0000	1.147
> +++ hppa-tdep.c	21 Apr 2004 15:10:09 -0000
> @@ -2039,5 +2085,6 @@ hppa_frame_cache (struct frame_info *nex
>    CORE_ADDR this_sp;
>    long frame_size;
>    struct unwind_table_entry *u;
> +  CORE_ADDR end_pc;
>    int i;
>  
> @@ -2084,15 +2146,18 @@ hppa_frame_cache (struct frame_info *nex
>       GCC code.  */
>    {
>      int final_iteration = 0;
> -    CORE_ADDR pc;
> -    CORE_ADDR end_pc;
> +    CORE_ADDR pc, prologue_end;
>      int looking_for_sp = u->Save_SP;
>      int looking_for_rp = u->Save_RP;
>      int fp_loc = -1;
> -    end_pc = skip_prologue_using_sal (frame_func_unwind (next_frame));
> -    if (end_pc == 0)
> -      end_pc = frame_pc_unwind (next_frame);
> +
> +    prologue_end = hppa_skip_prologue (frame_func_unwind (next_frame));

Is hppa_skip_prologue needed?  skip_prologue_using_sal doesn't touch the 
inferior so is more light weight.

> +    end_pc = frame_pc_unwind (next_frame) - 4;

No, the edge case of the test is wrong:

   for (...; ... && pc <= end_pc; ...

should be:

	... pc < end_pc

> +    if (prologue_end != 0 && end_pc > prologue_end)
> +      end_pc = prologue_end;
> +
>      frame_size = 0;
> +
>      for (pc = frame_func_unwind (next_frame);
>  	 ((saved_gr_mask || saved_fr_mask
>  	   || looking_for_sp || looking_for_rp
> @@ -2104,7 +2169,7 @@ hppa_frame_cache (struct frame_info *nex
>  	char buf4[4];
>  	long status = target_read_memory (pc, buf4, sizeof buf4);
>  	long inst = extract_unsigned_integer (buf4, sizeof buf4);
> -	
> +
>  	/* Note the interesting effects of this instruction.  */
>  	frame_size += prologue_inst_adjust_sp (inst);
>  	
> @@ -2207,6 +2272,7 @@ hppa_frame_cache (struct frame_info *nex
>  	if (is_branch (inst))
>  	  final_iteration = 1;
>        }
> +    end_pc = pc;
>    }
>  
>    {
> @@ -2214,26 +2280,50 @@ hppa_frame_cache (struct frame_info *nex
>         the current function (and is thus equivalent to the "saved"
>         stack pointer.  */
>      CORE_ADDR this_sp = frame_unwind_register_unsigned (next_frame, HPPA_SP_REGNUM);
> -    /* FIXME: cagney/2004-02-22: This assumes that the frame has been
> -       created.  If it hasn't everything will be out-of-wack.  */
> -    if (u->Save_SP && trad_frame_addr_p (cache->saved_regs, HPPA_SP_REGNUM))
> -      /* Both we're expecting the SP to be saved and the SP has been
> -	 saved.  The entry SP value is saved at this frame's SP
> -	 address.  */
> -      cache->base = read_memory_integer (this_sp, TARGET_PTR_BIT / 8);
> +
> +    if (frame_pc_unwind (next_frame) >= end_pc)

as the result of the above, this will need tweaking.

> +      {
> +        if (u->Save_SP && trad_frame_addr_p (cache->saved_regs, HPPA_SP_REGNUM))
> +          {
> +            /* Both we're expecting the SP to be saved and the SP has been
> +	       saved.  The entry SP value is saved at this frame's SP
> +	       address.  */
> +            cache->base = read_memory_integer (this_sp, TARGET_PTR_BIT / 8);
> +          }
> +        else
> +          {
> +            /* The prologue has been slowly allocating stack space.  Adjust
> +	     the SP back.  */
> +            cache->base = this_sp - frame_size;
> +          }
> +      }
>      else
> -      /* The prologue has been slowly allocating stack space.  Adjust
> -	 the SP back.  */
> -      cache->base = this_sp - frame_size;
> +      {
> +	/* This frame has not yet been created. */
> +        cache->base = this_sp;
> +      }
> +
>      trad_frame_set_value (cache->saved_regs, HPPA_SP_REGNUM, cache->base);
>    }
>  
>    /* The PC is found in the "return register", "Millicode" uses "r31"
>       as the return register while normal code uses "rp".  */
>    if (u->Millicode)
> -    cache->saved_regs[PCOQ_HEAD_REGNUM] = cache->saved_regs[31];
> +    {
> +      if (trad_frame_addr_p (cache->saved_regs, RP_REGNUM))
> +        cache->saved_regs[PCOQ_HEAD_REGNUM] = cache->saved_regs[31];
> +      else
> +	trad_frame_set_value (cache->saved_regs, PCOQ_HEAD_REGNUM,
> +			      read_register (31));
> +    }
>    else
> -    cache->saved_regs[PCOQ_HEAD_REGNUM] = cache->saved_regs[RP_REGNUM];
> +    {
> +      if (trad_frame_addr_p (cache->saved_regs, RP_REGNUM))
> +        cache->saved_regs[PCOQ_HEAD_REGNUM] = cache->saved_regs[RP_REGNUM];
> +      else
> +	trad_frame_set_value (cache->saved_regs, PCOQ_HEAD_REGNUM,
> +			      read_register (RP_REGNUM));

use frame_register_unwind et.al.

Andrew



  reply	other threads:[~2004-04-21 21:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-17  7:32 Randolph Chung
2004-04-17 16:35 ` Daniel Jacobowitz
2004-04-17 16:43   ` Randolph Chung
2004-04-17 16:54     ` Daniel Jacobowitz
2004-04-17 18:13       ` Randolph Chung
2004-04-21 14:55   ` Andrew Cagney
2004-04-21 15:18     ` Randolph Chung
2004-04-21 21:53       ` Andrew Cagney [this message]
2004-04-22  0:06         ` Randolph Chung
2004-04-22  0:49           ` Andrew Cagney
2004-04-22  2:38             ` Randolph Chung
2004-04-22  2:54             ` Randolph Chung
2004-04-22  3:00             ` Randolph Chung
2004-04-22 19:27               ` Andrew Cagney
2004-04-23  3:12                 ` Randolph Chung
2004-04-23  3:40                   ` Daniel Jacobowitz
2004-04-24  0:03                   ` Andrew Cagney

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=4086ED46.2050809@gnu.org \
    --to=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=randolph@tausq.org \
    /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