From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: randolph@tausq.org (Randolph Chung)
Cc: brobecker@adacore.com, gdb@sources.redhat.com
Subject: Re: [hpux] interesting but difficult to unwind code
Date: Fri, 09 Dec 2005 04:55:00 -0000 [thread overview]
Message-ID: <200512090455.jB94tEJq006334@hiauly1.hia.nrc.ca> (raw)
In-Reply-To: <4398FB10.1050307@tausq.org> from "Randolph Chung" at Dec 9, 2005 11:33:36 am
> > No, this code has been compiled by GCC. The save of the frame
> > pointer at the incomming stack pointer address is the clue. SAVE_SP
> > should be set to indicate this. This should allow unwinding
> > through this function...
>
> hrm, is there a way to verify this other than the above? The fact that
> the "args_stored" flag is set in the unwind record is also a bit
> surprising, as (afaict) gcc doesn't emit this flag.
>
> I downloaded this wdb binary from HP's website and their documentation
> also seems to suggest that it is compiled with HP compilers.
I've changed my mind. This code is compiled by a HP compiler. So,
it better be ABI compliant. I was confused by the code that has been
moved into the prologue.
GCC doesn't set "args_stored". The register saves for r4, r5 and r6
are in different locations than gcc would use. On checking, the frame
marker copy is slightly different. Gcc doesn't copy slot at "-10" and
we actually save the previous stack pointer at sp - 4 when the frame
pointer is needed.
> >> 1) it has a branch right in the middle of the prologue at +16. This is a
> >> call to strlen()
> >
> > Interesting. It looks ok from a functional standpoint.
>
> Yes, but I've never seen gcc do this.... does it?
I've never seen it but in theory it could.
> >> (gdb) maintenance print unwind execute_command
> >> unwind_table_entry (0x40286424):
> >> region_start = 0xcb44c <execute_command>
> >> region_end = 0xcb798 <execute_command+844>
> >> flags = Args_stored Save_RP
> >
> > I don't understand why you don't see SAVE_SP in the flags.
It looks as if r3 is used as the argument pointer (previous stack pointer)
but there aren't any flag bits set to indicate this. The only indication
is the copy at 0x000cb454. I guess if you detect this you have to take
it as a matter of faith that the contents of r3 don't change.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
next prev parent reply other threads:[~2005-12-09 4:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-09 0:08 Randolph Chung
2005-12-09 0:44 ` John David Anglin
2005-12-09 3:33 ` Randolph Chung
2005-12-09 4:55 ` John David Anglin [this message]
2005-12-09 18:47 Carl Burch
2005-12-10 0:43 ` John David Anglin
2005-12-11 14:45 ` Randolph Chung
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=200512090455.jB94tEJq006334@hiauly1.hia.nrc.ca \
--to=dave@hiauly1.hia.nrc.ca \
--cc=brobecker@adacore.com \
--cc=gdb@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