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/hppa/rfa] unwind fix for functions with no debug info
Date: Wed, 03 Nov 2004 22:24:00 -0000	[thread overview]
Message-ID: <41895A80.1090500@gnu.org> (raw)
In-Reply-To: <20041103174449.GD4249@tausq.org>

Randolph Chung wrote:
> The attached patch fixes a problem reported by Dave Anglin and others.
> When compiled without debug information, static functions have no symbol
> table entry in gdb. In this case, frame_func_unwind returns the starting
> address of the previously visible function. Using that to do unwinding
> causes all sorts of brokeness.... 

(frame_func_unwind can also return zero.)

> On hppa, each properly defined function has an unwind record which gives
> the starting and ending address of the function. We can use that to
> do unwinding more properly.
> 
> Tested on hppa-linux with no regressions.
> 
> Ok to apply?
> 
> randolph
> 
> 2004-11-03  Randolph Chung  <tausq@debian.org>
> 
> 	* hppa-tdep.c (hppa_frame_cache): Avoid using frame_func_unwind () to
> 	locate the beginning of the function.  When objects are compiled without
> 	debug symbols, frame_func_unwind can return the wrong function.  We
> 	can do better than that by using unwind records.
> 	(hppa_frame_this_id): Likewise.

Ok for 6.3 and mainline with a comment/change log tweak:

The convention is for the ChangeLog to record what was changed while the 
code records why it was changed.  Consequently, the ChangeLog should 
read something like:

hppa-tdep.c (hppa_frame_cache): Use frame_pc_unwind instead of 
frame_func_unwind () to locate the unwind entry.

and the the corresponding code gets the rationale for doing things the 
current way:

/* Avoid using frame_func_unwind () to locate the beginning of the 
function.  When objects are compiled without debug symbols, 
frame_func_unwind can return the wrong function.  We can do better than 
that by using unwind records.  */

(the GNU coding standard discusses this further)

Andrew


> Index: hppa-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
> retrieving revision 1.175
> diff -u -p -r1.175 hppa-tdep.c
> --- hppa-tdep.c	31 Oct 2004 21:09:28 -0000	1.175
> +++ hppa-tdep.c	3 Nov 2004 16:18:40 -0000
> @@ -1580,7 +1580,7 @@ hppa_frame_cache (struct frame_info *nex
>    cache->saved_regs = trad_frame_alloc_saved_regs (next_frame);
>  
>    /* Yow! */
> -  u = find_unwind_entry (frame_func_unwind (next_frame));
> +  u = find_unwind_entry (frame_pc_unwind (next_frame));


>    if (!u)
>      {
>        if (hppa_debug)
> @@ -1630,7 +1630,7 @@ hppa_frame_cache (struct frame_info *nex
>         symbol information.  hppa_skip_prologue also bounds the returned
>         pc by the passed in pc, so it will not return a pc in the next
>         function.  */
> -    prologue_end = hppa_skip_prologue (frame_func_unwind (next_frame));
> +    prologue_end = hppa_skip_prologue (u->region_start);
>      end_pc = frame_pc_unwind (next_frame);
>  
>      if (prologue_end != 0 && end_pc > prologue_end)
> @@ -1638,7 +1638,7 @@ hppa_frame_cache (struct frame_info *nex
>  
>      frame_size = 0;
>  
> -    for (pc = frame_func_unwind (next_frame);
> +    for (pc = u->region_start;
>  	 ((saved_gr_mask || saved_fr_mask
>  	   || looking_for_sp || looking_for_rp
>  	   || frame_size < (u->Total_frame_size << 3))
> @@ -1881,8 +1881,14 @@ static void
>  hppa_frame_this_id (struct frame_info *next_frame, void **this_cache,
>  			   struct frame_id *this_id)
>  {
> -  struct hppa_frame_cache *info = hppa_frame_cache (next_frame, this_cache);
> -  (*this_id) = frame_id_build (info->base, frame_func_unwind (next_frame));
> +  struct hppa_frame_cache *info;
> +  CORE_ADDR pc = frame_pc_unwind (next_frame);
> +  struct unwind_table_entry *u;
> +
> +  info = hppa_frame_cache (next_frame, this_cache);
> +  u = find_unwind_entry (pc);
> +
> +  (*this_id) = frame_id_build (info->base, u->region_start);
>  }
>  
>  static void


  reply	other threads:[~2004-11-03 22:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-03 17:48 Randolph Chung
2004-11-03 22:24 ` Andrew Cagney [this message]
2004-11-03 22:37   ` Randolph Chung
2004-11-04  0:15     ` 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=41895A80.1090500@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