Re: Oldest supported Linux kernel version (require PTRACE_EVENT_CLONE?)

[Antoine Tremblay <antoine.tremblay@ericsson.com>]

> The ongoing work to make gdbserver support software single-stepping itself,
> necessary for tracepoints on ARM, MIPS and other architectures where the
> CPU doesn't offer a hardware single-step facility, trips on these magic
> breakpoints -- the question of how to fit the new software single-step
> mechanism with those breakpoints naturally comes up.
>

I would like to add some details to this :

Today, the only reason there has been some software single stepping 
logic in gdbserver is to get over these magic breakpoints.

This is done with very basic single stepping logic like :

/* We only place breakpoints in empty marker functions, and thread 
locking is outside of the function.  So rather than importing software 
single-step, we can just run until exit.  */
static CORE_ADDR
arm_reinsert_addr (void)
{
   struct regcache *regcache = get_thread_regcache (current_thread, 1);
   unsigned long pc;
   collect_register_by_name (regcache, "lr", &pc);
   return pc;
}

The comment illustrates the assumption that we will single step only 
those magic breakpoints and not other code.

Other unintended situations like if we were to single step because we 
executed a conditional breakpoint we would get into issues.

Thus this patch disabled the conditional breakpoints : 
https://sourceware.org/ml/gdb-patches/2015-04/msg01110.html

Today, work is ongoing to implement proper software single step support.

However, in gdbserver linux-low, we equate the implementation of 
breakpoint_reinsert_addr that is used for the thread magic breakpoints 
to software single step support.

This is a problem as if some implementations of this operation 
(reinsert_addr) are correct and others are not and only there for the 
thread magic breakpoints, we can't enable features based solely software 
single step support has some would be broken.

To keep the incorrect implementations and allow the new proper ones at 
the same time we would need to implement fallback code and it quickly 
becomes ugly and confusing with multiple checks for legacy software 
single step or proper software single step...

> However, PTRACE_EVENT_CLONE was first introduced in Linux 2.5.46,
> released in November 2002.
>
> So I think it's reasonable to just remove support for kernels that
> don't support PTRACE_EVENT_CLONE, and sidestep the libthread_db
> breakpoints issues entirely.
>

Indeed however, we may not have to add all this legacy logic to the 
code, removing this support would enable the removal of the incorrect 
implementations of the reinsert_addr operation. And addition of the 
proper ones while keeping only one operation and check for software 
single step.