On Fri, Feb 29, 2008 at 10:05 AM, Nicholas Nethercote
> On Thu, 28 Feb 2008, Bart Van Assche wrote:
> > [ Just subscribed to the valgrind-users mailing list ]
> > Regarding DRD and linuxthreads: of course DRD should compile with the
> > linuxthreads header files. The compilation issue should be fixed by
> > this time (can't retest that right now).
> > Currently neither DRD nor Helgrind work reasonably with linuxthreads.
> > Both tools can be ported to linuxthreads, but this would take
> > considerable work (at least for DRD).
> Is it worth just aborting immediately, with a message "sorry, DRD doesn't
> work on LinuxThreads matches". If it doesn't work "reasonably", don't try
> to work at all -- otherwise people may try it, not realise that it doesn't
> work well with LinuxThreads, and conclude (erroneously) that it's no good.
Good idea, but how to test which threading library is in use ? Some
Linux distributions distribute both linuxthreads and the NPTL with
their version of glibc, make one library the default, and allow to
select the other library via LD_LIBRARY_PATH=... So the only reliable
way to detect which threading library is in use is to test this at run
time. The only run-time test I know of is to create a thread that
calls getpid(), and to compare the result with the getpid() result in
the creator thread. For linuxthreads both PID's will be different, for
NPTL these will be identical. Such a test has to run as client code.
But adding such a test in DRD's or Helgrind's client code would be
difficult since both tools already intercept pthread_create() and
This is why DRD does not yet try to find out which threading library is in use.