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] Handle MIPS Linux SIGTRAP siginfo.si_code values


On Wed, 24 Feb 2016, Pedro Alves wrote:

> @@ -140,14 +140,32 @@ struct buffer;
>     in SPU code on a Cell/B.E.  However, SI_KERNEL is never seen
>     on a SIGTRAP for any other reason.
>  
> -   The generic Linux target code should use GDB_ARCH_IS_TRAP_BRKPT
> -   instead of TRAP_BRKPT to abstract out these peculiarities.  */
> +   The MIPS kernel uses SI_KERNEL for all kernel generated traps.
> +   Since:
> +
> +     - MIPS doesn't do hardware single-step
> +     - We don't need to care about exec SIGTRAPs, since we assume
> +       PTRACE_EVENT_EXEC.
> +     - The MIPS kernel doesn't support hardware breakpoints.
> +
> +   on MIPS, all we need to care about is distinguishing between
> +   software breakpoints and hardware watchpoints, which can be done by
> +   peeking the debug registers.

 I'm assuming spurious traps such as from trap instructions will still be 
delivered as such, right?

> +
> +   The generic Linux target code should use GDB_ARCH_IS_TRAP_* instead
> +   of TRAP_* to abstract out these peculiarities.  */
>  #if defined __i386__ || defined __x86_64__
>  # define GDB_ARCH_IS_TRAP_BRKPT(X) ((X) == SI_KERNEL)
> +# define GDB_ARCH_IS_TRAP_HWBKPT(X) ((X) == TRAP_HWBKPT)
>  #elif defined __powerpc__
>  # define GDB_ARCH_IS_TRAP_BRKPT(X) ((X) == SI_KERNEL || (X) == TRAP_BRKPT)
> +# define GDB_ARCH_IS_TRAP_HWBKPT(X) ((X) == TRAP_HWBKPT)
> +#elif defined __mips__
> +# define GDB_ARCH_IS_TRAP_BRKPT(X) ((X) == SI_KERNEL)
> +# define GDB_ARCH_IS_TRAP_HWBKPT(X) ((X) == SI_KERNEL)

 Shall I add the TRAP_BRKPT and TRAP_HWBKPT codes to the MIPS Linux kernel 
then or not?  If anything, this looks like a performance win to me, at no 
significant cost (any possible kernel overhead will be in the range of a 
couple processor instructions, which is nothing compared to an extra 
ptrace(2) call and all the associated processing).

  Maciej


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