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
next prev parent 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