Re: [PATCH] Expect SI_KERNEL si_code for a MIPS software breakpoint trap

[Pedro Alves <palves@xxxxxxxxxx>]

Hi Maciej,

>  As to the kernel side with the observations made in this discussion I 
> think we should set the trap code for SIGTRAP signals issued with BREAK 
> instructions to TRAP_BRKPT unconditionally, regardless of the code used.  
> This won't of course affect encodings which send a different signal such 
> as SIGFPE.
> 
>  We're lacking a code suitable for (conditional) trap instructions.  I 
> think TRAP_TRAP or suchlike needs to be added.

Yeah, looks like it.

>> Hardware breakpoint hits are distinguished from software breakpoint hits,
>> because they're reported with "hwbreak", not "swbreak":
>>
>>  @item hwbreak
>>  The packet indicates the target stopped for a hardware breakpoint.
>>  The @var{r} part must be left empty.
> 
>  Umm, any requirements for this?  We have MIPS data hardware breakpoint 
> support in the Linux kernel (regrettably not for instructions, but that 
> could be added sometime), but I can't see TRAP_HWBKPT being set for them, 
> they just use generic SI_KERNEL as everything else right now.

Can userspace/ptrace still tell whether a hardware breakpoint triggered by
consulting debug registers, similarly to how it can for watchpoints,
with PTRACE_GET_WATCH_REGS, and looking at watchhi ?

(assuming this comment is correct):

/* Target to_stopped_by_watchpoint implementation.  Return 1 if
   stopped by watchpoint.  The watchhi R and W bits indicate the watch
   register triggered.  */

static int
mips_linux_stopped_by_watchpoint (struct target_ops *ops)
{


This is not reachable today, due to lack of TRAP_* in si_code, but I
think that can be fixed.


The only use for hwbreak currently is to know whether to ignore hardware
breakpoint traps gdb can't explain (gdb assumes they're a delayed event for
a hw breakpoint that has since been removed):

  /* Maybe this was a trap for a hardware breakpoint/watchpoint that
     has since been removed.  */
  if (random_signal && target_stopped_by_hw_breakpoint ())
    {
      /* A delayed hardware breakpoint event.  Ignore the trap.  */
      if (debug_infrun)
	fprintf_unfiltered (gdb_stdlog,
			    "infrun: delayed hardware breakpoint/watchpoint "
			    "trap, ignoring\n");
      random_signal = 0;
    }

So if the server claims it supports this stop reason, but then doesn't
send it for hw breakpoint trap, users will see their programs
occasionally stop for random spurious SIGTRAPs (if they use hardware
breapoints).

If the server does _not_ claim support for the swbreak/hwbreak stop
reason, then the old moribund breakpoints heuristic kicks in:

  /* Check if a moribund breakpoint explains the stop.  */
  if (!target_supports_stopped_by_sw_breakpoint ()
      || !target_supports_stopped_by_hw_breakpoint ())
    {
      for (ix = 0; VEC_iterate (bp_location_p, moribund_locations, ix, loc); ++ix)
	{
	  if (breakpoint_location_address_match (loc, aspace, bp_addr)
	      && need_moribund_for_location_type (loc))
	    {
	      bs = bpstat_alloc (loc, &bs_link);
	      /* For hits of moribund locations, we should just proceed.  */
	      bs->stop = 0;
	      bs->print = 0;
	      bs->print_it = print_it_noop;
	    }
	}
    }

Thanks,
Pedro Alves