From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7756 invoked by alias); 9 Dec 2005 18:47:21 -0000 Received: (qmail 7749 invoked by uid 22791); 9 Dec 2005 18:47:20 -0000 X-Spam-Check-By: sourceware.org Received: from palrel11.hp.com (HELO palrel11.hp.com) (156.153.255.246) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 Dec 2005 18:47:17 +0000 Received: from smtp2.ptp.hp.com (smtp2.ptp.hp.com [15.1.28.240]) by palrel11.hp.com (Postfix) with ESMTP id 58EE83712F; Fri, 9 Dec 2005 10:47:16 -0800 (PST) Received: from adlwrk03.cup.hp.com (adlwrk03.cup.hp.com [15.244.96.190]) by smtp2.ptp.hp.com (Postfix) with ESMTP id 42EC91D1D8B; Fri, 9 Dec 2005 18:47:16 +0000 (UTC) Received: (from cdb@localhost) by adlwrk03.cup.hp.com (8.9.3 (PHNE_24419+JAGae58098)/8.7.3 TIS Messaging 5.0) id KAA08575; Fri, 9 Dec 2005 10:47:15 -0800 (PST) Date: Fri, 09 Dec 2005 18:47:00 -0000 From: Carl Burch Message-Id: <200512091847.KAA08575@adlwrk03.cup.hp.com> To: gdb@sources.redhat.com Subject: Re: [hpux] interesting but difficult to unwind code Cc: brobecker@adacore.com, dave@hiauly1.hia.nrc.ca, randolph@tausq.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00102.txt.bz2 > > > 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 > > >> region_end = 0xcb798 > > >> 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