[PATCH v8] Add pretty printers for the NPTL lock types

[Pedro Alves]

On 06/22/2016 10:44 PM, Martin Galvan wrote:
> I've confirmed the test is failing because of a gdb bug:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=20291

(The difference is that nowadays gdb doesn't use libthread_db.so
thread create event breakpoints, which were masking the issue.)

> 
> I'll be working on fixing that bug, but I don't think that should
> block the merging of this patch. Right now I'm using set
> scheduler-locking on to grab the child thread's ID for more rigurous
> testing. We can either leave it as it is, knowing it's a gdb bug, or
> remove the check for the child thread's ID (for now at least).

- Workaround:

  Can you work around it by setting a breakpoint that the child
  trips on?  Once the breakpoint triggers, you can switch back to
  the parent, and continue/step it, and the child won't run further,
  due to "set scheduler-locking on".

- Hang stepping over pthread_create?

  Note that if there's synchronization (mutex/futex/whatnot) between
  the parent/child threads inside glibc's pthread_create, then making gdb's
  "set scheduler-locking on" lock the child thread _immediately_, such
  that it is never ever scheduled -- that is, never let it run as soon as
  we collect the initial PTRACE_EVENT_CLONE-injected SIGSTOP -- 
  then trying to "step"/"next"/"continue to breakpoint" over pthread_create
  will hang, with the parent waiting forever for the child to
  unlock the mutex/futex/whatnot.

- Why it works with older GDBs, probably:

  Since libthread_db thread create event breakpoints force synchronization
  inside (see nptl/pthread_create.c:__pthread_create_2_1), it seems to me
  that with older GDBs you don't see that hang by chance, because
  the child still runs a bit before the thread create event breakpoint
  is hit by the parent, probably enough to have the child unlock the
  synchronization lock.

Thanks,
Pedro Alves