Re: [hpux] interesting but difficult to unwind code

[Carl Burch <cdb@cup.hp.com>]

> > > 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.
  
   If you have our odump tool, "odump -comp a.out" will show you the 
compiler and options used to build each object for a PA32 executable :

spider cdb_debug 78: odump -comp ../gdb | more

Compilation Unit Dictionary from ../gdb:

Index Chunk     Language                                    Name
        Product_id ; Version_id
        Compile time ; Source time

	...

   5   0  HPC                                                ../../../Src/gnu/gd
b/main.c
/CLO/Components/WDB/build/hppa1.1-hp-hpux11.00/gdb
ccom options =  -g -DAportable -Oq00,al,ag,cn,Lm,sz,Ic,vo,lc,mf,Po,es,rs,sp,in,v
c,pi,fa,pe,Rr,Fl,pv,pa,nf,cp,lx,st,ap,Pg,ug,lu,lb,uj,dp,fs,bp,wp,cl,mo,xn,Ex,mp,
rp,ap,dn,Sg,pt,kt,Em,pc,np! -ESconstlit -Ae
driver_command =   /CLO/BUILD_ENV/opt/ansic/bin/cc -Ae -D_LOAD_MODULE_DESC_EXT +
DAportable -D_PSTAT64  -g +Ww2223 -D__HP_CURSES -DSEEK_64_BITS -D__HP_CURSES -DS
EEK_64_BITS -I. -I../../../Src/gnu/gdb -I../../../Src/gnu/gdb/config -DHAVE_CONF
IG_H -I../../../Src/gnu/gdb/../include/opcode -I../../../Src/gnu/gdb/../readline
/.. -I../bfd -I../../../Src/gnu/gdb/../bfd -I../../../Src/gnu/gdb/../include -I.
./../../Src/gnu/gdb/../../BUILD_ENV/usr/include -I../../../Src/gnu/gdb/../includ
e/elf -I../intl -I../../../Src/gnu/gdb/../intl -DUI_OUT=1 -DTUI=1 -I../../../Src
/gnu/gdb/tui

          HP92453-01  ; W113101
          Compile Time: Thu Dec 08 2005 23:21:13.000000000 PST
          Source  Time: Thu Nov 17 2005 02:36:02.000000000 PST

   For PA64 objects the more familiar elfdump tool shows the same info via
the -dc option.

> > I downloaded this wdb binary from HP's website and their documentation
> > also seems to suggest that it is compiled with HP compilers.

   That's right.

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

   That optimization is done by the HP PA-RISC compilers under the
+Oentrysched option.  Here's what the man page has to say about it :

      +O[no]entrysched
                     Perform [do not perform] instruction scheduling on a
                     subprogram's entry and exit code sequences.  This
                     optimization can occur at optimization levels 1, 2, 3,
                     and 4.  The default is +Onoentrysched.

The unwind implications are that an aggressive form of (Ada-style) unwind
called context restoration won't work, but regular stack tracebacks do.

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

> > >> (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.

   There are two bits in the "struct unwind_table_entry" defined in
config/pa/tm-hppa.h (at least in the WDB sources) that cover alloca() use
and +Oentrysched use:

    unsigned int sched_entry_seq:1;     /* 25 */
		...
    unsigned int alloca_frame:1;        /* 35 */

Unfortunately, even HP gdb doesn't print out those fields for a "maintenance
print unwind" command

						- Carl Burch
						  HP WDB Team