From: Randolph Chung <randolph@tausq.org>
To: Jim Blandy <jimb@red-bean.com>
Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches@sources.redhat.com
Subject: Re: [hppa] FYI: confusion in unwind descriptor field meaning
Date: Sat, 12 Nov 2005 04:59:00 -0000 [thread overview]
Message-ID: <4375624D.1070202@tausq.org> (raw)
In-Reply-To: <8f2776cb0511111838m64d478d9s2e04db338fbf7fc8@mail.gmail.com>
>>For that matter, how do you find the beginning of the function without
>>unwind data?
>
> Linker symbols. If you don't have them, then prologue analysis isn't useful.
This is what I meant - on hppa, even without linker symbols, we can
still do prologue analysis because the ABI mandates unwind records. So
we can actually do unwinding more robustly based on the unwind records.
This is especially useful when you have mixed code compiled with
different flags and/or have been stripped.
We have this comment in hppa-tdep.c:
/* We used to use frame_func_unwind () to locate the beginning of the
function to pass to skip_prologue (). However, when objects are
compiled without debug symbols, frame_func_unwind can return the
wrong
function (or 0). We can do better than that by using unwind
records. */
>>OTOH, if you can combine all the prologue analysis code in hppa-tdep.c
>>and make it more robust, I think it will certainly be a good thing.
>
> In my experience, the new analysis framework (which I've kind of been
> forgetting about for a while now) makes things a lot more robust. I
> wrote it because I was getting fed up with corrupted backtraces
> debugging GDB on the S/390. With the new framework, I got a
> multi-page backtrace through optimized code the first time. It makes
> a big difference.
Yes, I saw some of the discussions about the new framework and I think
it's a very good thing. gdb on hppa-linux can do pretty good backtraces
now with optimized code. On hpux we still have some work to do. In
either case, as Mark pointed out, the code is rather ugly so doing some
cleanup with some more structure will be nice.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
next prev parent reply other threads:[~2005-11-12 3:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-09 23:55 Joel Brobecker
2005-11-10 1:27 ` Randolph Chung
2005-11-10 1:31 ` Joel Brobecker
2005-11-10 1:32 ` Randolph Chung
2005-11-10 19:18 ` Randolph Chung
2005-11-11 11:22 ` Joel Brobecker
2005-11-12 3:32 ` Randolph Chung
2005-11-12 4:22 ` Jim Blandy
2005-11-12 4:39 ` Jim Blandy
2005-11-12 4:59 ` Randolph Chung [this message]
2005-11-12 5:07 ` Jim Blandy
2005-11-12 13:21 ` Randolph Chung
2005-11-12 17:08 ` Jim Blandy
2005-11-13 15:38 ` Randolph Chung
2005-11-13 18:27 ` Daniel Jacobowitz
2005-11-19 19:15 ` Randolph Chung
2005-11-13 18:23 ` Joel Brobecker
2005-11-13 18:28 ` Daniel Jacobowitz
2005-11-13 18:36 ` Joel Brobecker
2005-11-13 18:45 ` Daniel Jacobowitz
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=4375624D.1070202@tausq.org \
--to=randolph@tausq.org \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@red-bean.com \
/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