Previously, there was a bug on PTRACE_EVENT_FORK in which the forked
child process inherits all installed breakpoints due to their interrupt
instructions being resident in memory at the time of the fork, but the
debugger initializes the new process model with an empty list of
breakpoints.

There are some differing opinions on what the correct behavior ought to
be here, but at a minimum these two realities must be brought into sync
to prevent data corruption or any process crash of the fork child.

For the time being, manually "uninstall" the residual breakpoint
interrupts from a newly forked child that we attach to, leaving it with
no breakpoints of any kind.  Process model initialization in the
debugger is left as-is.

Signed-off-by: Matt Hunter <m@lfurio.us>

On exec, the program image and address space completely changes, so any
previously established breakpoints going forward are meaningless.  Even
if we are re-execing the same actual program, ASLR may invalidate the
addresses of BPs, let alone if the program is modified/recompiled.

The act of performing the exec already "uninstalls" any breakpoints by
reloading the memory space, adapt to this by simply freeing our list of
managed breakpoints from the debugger, without any additional
processing.

Signed-off-by: Matt Hunter <m@lfurio.us>

Signed-off-by: Matt Hunter <m@lfurio.us>

Add initial 32-bit ARM support and additionally build out internal
breakpoint design to allow the use of single-step oriented breakpoints.

* arm32:
  Always prune step breakpoints when uninstalling from memory
  Update detect_breakpoint() to better handle single stepping
  Add architecture-specific single step support
  Add 32-bit ARM architecture params

On completion of an initial single step, we can and should discard these
breakpoints, even though the thread may not be "stopping" and go on to
continue in free-run.  They have served their purpose at this point and
we would like to avoid any other thread encountering them.

Also, whenever uninstall_breakpoints() is called, it is because we are
cycling a process's threads and are about to run resume_threads() which
currently does the work of re-computing a thread's step breakpoints if a
previous single step was interrupted, whether or not the step
breakpoints for that instant have already been figured.  So this also
addresses a bug where one thread, with repeatedly interrupted single
steps, would accumulate more and more redundant breakpoint entries until
it was finally able to proceed and eventually stop.

Signed-off-by: Matt Hunter <m@lfurio.us>

A stopped thread should sometimes restart, even if a breakpoint
interrupted a single step.  detect_breakpoint() and its interaction with
wait_thread() is updated such that any restart during a single step
scenario properly "requeues" the thread's run intent, by preserving the
doing/donext flags.

Furthermore, detect_breakpoint() ditches its call to get_breakpoint()
and considers any and all breakpoints impacting the current thread PC,
since they may each suggest different restarting requirements.  In
effect, the thread will only remain stopped if at least one relevant
breakpoint allows it to do so.

This reverts commit 5589a9e3afd5 ("Ignore breakpoints during
singlestep").

Signed-off-by: Matt Hunter <m@lfurio.us>

ARM 32-bit is the first platform added to misplays which lacks
underlying hardware support for single step traps - so the kernel does
not implement PTRACE_SINGLESTEP in this case.

We will work around this in a similar way as gdb does and how the kernel
used to do it until 2011.  arm_singlestep() implements logic which
disassembles the program's current instruction and analyzes it to
determine all possible next locations - eg: the next instruction in
memory, or the jump target of a branch instruction, etc.  This logic is
dynamically dispatched by the debugger core if an ARM build is running
in 32-bit mode.

arm_singlestep() uses breakpoints to stop execution at it's computed
next locations.  However, misplays is currently very careful about
controling the use of breakpoints in order to avoid issues with thread
single steps - so a new flag (called "step") is added to breakpoints to
enable the debugger to selectively install this subset of breakpoints
for each thread's single step action, and more or less keep treating
thread free-run as normal.  install_breakpoints() is updated to take a
"step" parameter to control which set of breakpoints is installed at any
given time.

resume_threads() is updated to perform this new single step dynamic
dispatch, and manage the installation of step breakpoints.

add_breakpoint() is also given a "step" parameter.  This initializes the
flag for the new breakpoint, but crucially is used to sort the new
breakpoint into the process breakpoint list.  Since step breakpoints
will always be installed first, prioritize them in the list so that
uninstall_breakpoints() doesn't corrupt memory when it runs the list
backward to remove them.

Signed-off-by: Matt Hunter <m@lfurio.us>

Signed-off-by: Matt Hunter <m@lfurio.us>

Signed-off-by: Matt Hunter <m@lfurio.us>

If dbg_attach fails, it calls this function to clean up before the
process in added to the main process list, so list_remove() is invalid.

Signed-off-by: Matt Hunter <m@lfurio.us>