Oldest supported Linux kernel version (require PTRACE_EVENT_CLONE?)

Oldest supported Linux kernel version (require PTRACE_EVENT_CLONE?)

[Pedro Alves]

Hi,

GDB currently has no guideline on the oldest version of the
Linux kernel gdb supports.

For every new feature the kernel introduces, we keep old
fallback code, and as time (years) goes by, we keep the old code
working, and tend to leave it in place.

As a result we're probably carrying around old code that works
around bugs and missing features in ancient kernels that nobody
expects new gdb to ever run on.

Such fallback code obviously increases maintenance burden, often
confuses newcomers, and sometimes influences design decisions deep
in the ptrace backends and sometimes in the remote protocol.

For example, on systems that don't support PTRACE_EVENT_CLONE, both gdb
and gdbserver coordinate with libthread_db.so to insert breakpoints at magic
locations in libpthread.so, in order to thread creation and thread death.

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.

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.

Comments?

Thanks,
Pedro Alves

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

[Antoine Tremblay]

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

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

[Doug Evans]

On Thu, Oct 15, 2015 at 4:38 AM, Pedro Alves <palves@redhat.com> wrote:
>...
> 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.

SGTM