Re: [PATCH] TLS access support in cross- Linux GDB

[Pedro Alves <palves at redhat dot com>]

On 06/08/2017 11:20 AM, Gary Benson wrote:

> I really don't think this approach is right for mainline GDB.  It's
> embedding glibc implementation details into GDB, things like alignment
> and structure offsets which may change at any time.  I'm mainly
> looking at the code in init_target_dep_constants, but there's other
> stuff e.g. the definition of TLS_PRE_TCB_SIZE in tls.h.  You're
> relying on *so* much stuff not changing, but glibc makes no such
> guarantees.

I agree.  My own take on this:

The whole point of libthread_db is to insulate debuggers from
libc's internals.

If the idea of a single libthread_db build that can be used to
cross debug multiple architectures (and a range of glibc versions,
I suppose) makes sense, then I think you should be pushing it to
glibc/nptl_db upstream directly.  

I.e., what would need to change in libthread_db.so and gdb that would
make it possible for GDB to just load libthread_db.so and have
it be usable in cross core debugging scenarios?

Presumably, some decisions made at libthread_db's compile time
would have to be adjusted to be deferred to run time?

It is my understanding that the current libthread_db.so implementation was
actually designed with this run-time selection in mind, and that's
why it has things like:

  /* The method of locating a thread's th_unique value.  */
  enum
    {
      ta_howto_unknown,
      ta_howto_reg,
      ta_howto_reg_thread_area,
      ta_howto_const_thread_area
    } ta_howto;

and then uses if/switch around enums like that at run time, instead
of selecting the right methods at compile time.  Maybe what's there
is only usable currently in biarch scenarios, though, I'm not
sure.

By largely copying over libthread_db into gdb and tweaking it, we'd
effectively be stating that gdb is going to take care of libthread_db's
maintenance, and taking care of making our version workable against
perhaps a range of different glibc versions when glibc internals change.

That doesn't seem like a good approach to me.  If handling multiple
archs and versions in a single source copy of libthread_db makes sense,
then I think it'd make much more sense to do that in glibc/libthread_db
proper, than in gdb.  Was that option considered?

Thanks,
Pedro Alves