From mboxrd@z Thu Jan 1 00:00:00 1970 From: Randolph Chung To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfa/hppa] Use frame pointer for unwinding Date: Sun, 16 May 2004 17:03:00 -0000 Message-id: <20040516170257.GM566@tausq.org> References: <20040516020703.GZ566@tausq.org> <40A78B63.9020102@gnu.org> X-SW-Source: 2004-05/msg00472.html > The unwinder shouldn't need to doing things conditional on the type of > the next frame. Let me see if i can rework this a bit. The problem is that when you have: signal frame normal frame the stack pointer in the dummy frame is wrong. the dummy frame uses the sp returned by push_dummy_call () as the sp, but the unwinder follows the frame pointer saved by the signal trampoline, and they don't match. > What does ``Variable_Frame'' mean? 9. Variable_Frame (bit 17): Indicates that this region.s frame may be expanded during the region.s execution (using the Ada dynamic frame facility). Such frames require different unwinding techniques. actually what you are probably interested in is this: 26. alloca_frame (bit 35): This bit is set if alloca() is used and has been inlined. This indicates gr3 or gr4 may contain the previous sp value. For some reason this latter flag is named differently in the gdb sources compared to what's in the documentation. Anyway, I spoke with Dave Anglin (hppa gcc maintainer) about this. The problem is that currently gcc/binutils does not correctly implement the alloca_frame bit. The frame pointer is maintained in the case of a variable-sized frame, but there is no flag set in the unwind record, and the frame layout is slightly different compared to the HP compiler. It's one of the things that should be fixed in gcc eventually. Also Dave has observed that the Save_SP bit is set only for gcc; with the HP compiler this is not set. Finally, with the HP compiler the frame pointer can be maintained either in r3 or r4. It's not clear yet how this works. Some more experimentation/disassembling HP code is required :-( I will add some comments to the code about this situation. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/