This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [hpux] interesting but difficult to unwind code
- From: Carl Burch <cdb at cup dot hp dot com>
- To: gdb at sources dot redhat dot com
- Cc: brobecker at adacore dot com, dave at hiauly1 dot hia dot nrc dot ca, randolph at tausq dot org
- Date: Fri, 9 Dec 2005 10:47:15 -0800 (PST)
- Subject: 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.
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