From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15147 invoked by alias); 18 May 2012 22:25:34 -0000 Received: (qmail 15132 invoked by uid 22791); 18 May 2012 22:25:33 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 May 2012 22:25:19 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id q4IMPDXw022774; Sat, 19 May 2012 00:25:13 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id q4IMPBiD031110; Sat, 19 May 2012 00:25:11 +0200 (CEST) Date: Fri, 18 May 2012 22:25:00 -0000 Message-Id: <201205182225.q4IMPBiD031110@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: macro@codesourcery.com CC: gdb-patches@sourceware.org In-reply-to: (macro@codesourcery.com) Subject: Re: [PATCH] microMIPS support (Linux signal trampolines) References: Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00721.txt.bz2 > Date: Fri, 18 May 2012 22:31:45 +0100 > From: "Maciej W. Rozycki" > > To see if we need to check whether the execution mode selected matches > the given trampoline I have checked what the bit patterns of all the > trampoline sequences decode to in the opposite instruction set. This > produced useless or at least unusual code in most cases, for example: > > microMIPS/EB, o32 sigreturn, decoded as MIPS: > 30401017 andi zero,v0,0x1017 > 00008b7c dsll32 s1,zero,0xd > > MIPS/EL, o32 sigreturn, decoded as microMIPS: > 1017 2402 addi zero,s7,9218 > 000c 0000 sll zero,t0,0x0 > > However in some corner cases reasonable code can mimic a trampoline, for > example: > > MIPS/EB, n32 rt_sigreturn, decoded as microMIPS: > 2402 sll s0,s0,1 > 1843 0000 sb v0,0(v1) > 000c 0f3c jr t0 > > -- here the first instruction is a 16-bit one making things nastier even > as there are some other microMIPS instructions whose first 16-bit halfword > is 0x000c and therefore matches this whole trampoline pattern. On some OSes the signal trampolines are guaranteed to have a certain alignment. Is that the case for MIPS Linux as well perhaps? Or would that not help you? > Index: gdb-fsf-trunk-quilt/gdb/tramp-frame.c > =================================================================== > --- gdb-fsf-trunk-quilt.orig/gdb/tramp-frame.c 2012-02-24 15:23:42.000000000 +0000 > +++ gdb-fsf-trunk-quilt/gdb/tramp-frame.c 2012-05-18 20:03:53.775469792 +0100 > @@ -87,6 +87,12 @@ tramp_frame_start (const struct tramp_fr > enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); > int ti; > > + /* Check if we can use this trampoline. */ > + if (tramp->validate) > + pc = tramp->validate (tramp, this_frame, pc); > + if (pc == 0) > + return 0; I suppose chances are small we'll ever have a platform with trampolines at address 0, but nevertheless, wouldn't it be more correct to write if (tramp->validate) { pc = tramp->validate (tramp, this_frame, pc); if (pc == 0) return 0; } as you're checking for the magic return value?