Re: [hpux] interesting but difficult to unwind code

Carl Burch
2005-12-09T18:47:21Z

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