From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5241 invoked by alias); 7 May 2004 15:44:13 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5218 invoked from network); 7 May 2004 15:44:12 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 7 May 2004 15:44:12 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i47FiB0o031515 for ; Fri, 7 May 2004 11:44:11 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i47FiAv17154; Fri, 7 May 2004 11:44:10 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 220DD2B9D; Fri, 7 May 2004 11:44:11 -0400 (EDT) Message-ID: <409BAECA.8010607@gnu.org> Date: Fri, 07 May 2004 15:44:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] sigaltstack fixes for hppa-linux References: <20040504150219.GJ3965@tausq.org> <409A92F0.2050209@gnu.org> <20040507023627.GG3965@tausq.org> <20040507150758.GJ3965@tausq.org> In-Reply-To: <20040507150758.GJ3965@tausq.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-05/txt/msg00203.txt.bz2 >>> well, only because the hppa sigtramp unwinder is slightly broken :-) for >>> the sigtramp frame it current uses the sp stored in the sigcontext as >>> the frame base. instead it should probably use the handler's stack. > > > here's a fixed version. No frame.c modifications needed :) > > one question related to this: i noticed that some of the tests are > failing when: > - a breakpoint is placed in the signal trampoline (e.g. "finish" from > the signal handler) > - we try to unwind from the signal trampoline frame > > they fail because breakpoints are not yet disabled when the unwinding > starts (get_frame_id() is called early on in handle_inferior_event, > which runs through the unwinders) > > Are the unwinders that do code matching supposed to deal with the case > where there are breakpoints inserted in the code stream? or does this > point to something else that is broken? Yes, use frame*memory* and it will work (see tramp-frame.c: tramp_frame_start()) (and yes, having those memory routines possibly include breakpoints is just weird). Feel free to fix any other HP unwinders with a follow-on commit. Some suggested tweaks before committing follow: > 2004-05-06 Randolph Chung > > * hppa-linux-tdep.c (hppa_linux_sigtramp_find_sigcontext): Pass in pc > instead of sp, handle sigaltstack case. > (hppa_linux_sigtramp_frame_unwind_cache): Adjust calls to > hppa_linux_sigtramp_find_sigcontext, and set base to the frame of the > signal handler and not that of the caller. > (hppa_linux_sigtramp_unwind_sniffer): Adjust calls to > hppa_linux_sigtramp_find_sigcontext. > > Index: hppa-linux-tdep.c > =================================================================== > RCS file: /cvs/src/src/gdb/hppa-linux-tdep.c,v > retrieving revision 1.2 > diff -u -p -r1.2 hppa-linux-tdep.c > --- hppa-linux-tdep.c 7 May 2004 05:48:49 -0000 1.2 > +++ hppa-linux-tdep.c 7 May 2004 06:24:07 -0000 > @@ -282,7 +284,7 @@ hppa_linux_skip_trampoline_code (CORE_AD > Note that with a 2.4 64-bit kernel, the signal context is not properly > passed back to userspace so the unwind will not work correctly. */ > static CORE_ADDR > -hppa_linux_sigtramp_find_sigcontext (CORE_ADDR sp) > +hppa_linux_sigtramp_find_sigcontext (CORE_ADDR pc) > { > unsigned int dummy[HPPA_MAX_INSN_PATTERN_LEN]; > int offs = 0; > @@ -291,6 +293,12 @@ hppa_linux_sigtramp_find_sigcontext (COR > static int pcoffs[] = { 0, 4*4, 5*4 }; > /* offsets to the rt_sigframe structure */ > static int sfoffs[] = { 4*4, 10*4, 10*4 }; > + CORE_ADDR sp; > + > + /* Most of the time, this will be correct. The one case when this will > + fail is if the user defined an alternate stack, in which case the > + beginning of the stack will not be pc & 63. */ > + sp = (pc & ~63); Use align_down() (I never trust C's sign extension rules). Andrew