This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [hpux] interesting but difficult to unwind code


> > 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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]