From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14586 invoked by alias); 28 Apr 2004 20:53:52 -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 14579 invoked from network); 28 Apr 2004 20:53:51 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 28 Apr 2004 20:53:51 -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 i3SKroKI019032 for ; Wed, 28 Apr 2004 16:53:50 -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 i3SKrov24449; Wed, 28 Apr 2004 16:53:50 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 524F22B9D; Wed, 28 Apr 2004 16:53:53 -0400 (EDT) Message-ID: <409019E1.9060704@gnu.org> Date: Wed, 28 Apr 2004 20:53: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/rfa] hppa-linux target, 2nd try References: <20040424192614.GD2923@tausq.org> <408FD4B0.1000706@gnu.org> <20040428160005.GO3965@tausq.org> In-Reply-To: <20040428160005.GO3965@tausq.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-04/txt/msg00646.txt.bz2 >>>+static struct insn_pattern hppa_sigtramp[] = { >>>> >+ /* ldi 0, %r25 or ldi 1, %r25 */ >>>> >+ { 0x34190000, 0xfffffffd }, >>>> >+ /* ldi __NR_rt_sigreturn, %r20 */ >>>> >+ { 0x3414015a, 0xffffffff }, >>>> >+ /* be,l 0x100(%sr2, %r0), %sr0, %r31 */ >>>> >+ { 0xe4008200, 0xffffffff }, >>>> >+ /* nop */ >>>> >+ { 0x08000240, 0xffffffff }, >>>> >+ { 0, 0 } >>>> >+}; >> >>> >>> hmm, perhaps the mask can be integrated into tramp-frame.[hc], anyone? > > > well, hppa still can't use it because of the variable offset in the > stack frame to locate the trampoline :( As with the following comment? > +/* (This is derived from MD_FALLBACK_FRAME_STATE_FOR in gcc.) > + > + Unfortunately, because of various bugs and changes to the kernel, > + we have several cases to deal with. > + > + In 2.4, the signal trampoline is 4 bytes, and pc should point directly at > + the beginning of the trampoline and struct rt_sigframe. > + > + In <= 2.6.5-rc2-pa3, the signal trampoline is 9 bytes, and pc points at > + the 4th word in the trampoline structure. This is wrong, it should point > + at the 5th word. This is fixed in 2.6.5-rc2-pa4. > + > + To detect these cases, we first take pc, align it to 64-bytes > + to get the beginning of the signal frame, and then check offsets 0, 4 > + and 5 to see if we found the beginning of the trampoline. This will > + tell us how to locate the sigcontext structure. > + > + 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. */ The method is passed the start address of the trampoline vis: /* Initialize a trad-frame cache corresponding to the tramp-frame. FUNC is the address of the instruction TRAMP[0] in memory. */ void (*init) (const struct tramp_frame *self, struct frame_info *next_frame, struct trad_frame_cache *this_cache, CORE_ADDR func); and from that it should be possible to compute the offset. Andrew