This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] microMIPS support (Linux signal trampolines)


> 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]