This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] microMIPS support (Linux signal trampolines)
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: macro at codesourcery dot com
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 19 May 2012 00:25:11 +0200 (CEST)
- Subject: Re: [PATCH] microMIPS support (Linux signal trampolines)
- References: <alpine.DEB.1.10.1204241843340.19835@tp.orcam.me.uk> <alpine.DEB.1.10.1205171611090.11227@tp.orcam.me.uk>
> Date: Fri, 18 May 2012 22:31:45 +0100
> From: "Maciej W. Rozycki" <macro@codesourcery.com>
>
> 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?