This is the mail archive of the gdb@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: Oldest supported Linux kernel version (require PTRACE_EVENT_CLONE?)



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.


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