Page MenuHomePhabricator

Remove HostThreadLinux/Free/NetBSD
ClosedPublic

Authored by labath on Mar 15 2017, 7:13 AM.

Details

Summary

These classes existed only because of the GetName() static function,
which can be moved to a more natural place anyway. I move the linux
version to NativeProcessLinux (and get rid of ProcFileReader), the
freebsd version to ProcessFreeBSD (and fix a bug where it was using the
current process ID, instead of the inferior pid), and remove the NetBSD
version (which was probably incorrect anyway, as it assumes the current
process instead of the inferior.

I also add an llgs test to that verifies thread names are read
correctly.

Diff Detail

Repository
rL LLVM

Event Timeline

labath created this revision.Mar 15 2017, 7:13 AM
krytarowski edited edge metadata.Mar 15 2017, 11:25 AM

remove the NetBSD version (which was probably incorrect anyway, as it assumes the current process instead of the inferior.

Yes, I had issues with this and I wanted to take rid of it completely during the last month. I'm patching it out in my local LLDB tree... (I also noted it in one of my TNF blog posts that I delayed it for future until it will be researched properly and have real-like user within the debugger).

We cannot call pthread_getname_np and pthread_setname_np of an inferior process, because it's limited to the current one.

FreeBSD offers a way to read inferiors thread name via PT_LWPINFO (and surrounding calls to iterate over all native threads in a tracee) and read td_name. Alternatively use kvm(3) or sysctl(7) interfaces for the same purpose. (I can see in the patch that the sysctl(7) way is used).

Currently these calls for set/get thread name were moved to LLVM. I haven't checked other systems but the NetBSD one must be called for the current process.

The original NetBSD version was ported from FreeBSD... and it inherited its oddness that used to bite me. Another important note - the NetBSD LLVM version works only for pthread_t (POSIX threads), not native threads. There is also no interface exposed for users to translate native thread (LWP) <-> POSIX thread (pthread_t), it's not a lack of feature but the design that pthread_t is fully opaque. I'm not sure what's the purpose of the LLVM interface, whether to use pthread_t for the current process or any process & native thread like what might happen on Linux. I verified that other interfaces use pthread_t API out there and I accepted that revision.

Should I implement an interface to investigate tracee's thread name [on NetBSD] in ptrace(2)? I didn't want to introduce a ptrace(2) calls for set/get thread name, as thread name stored in the kernel is shadowed in pthread_t in our libpthread(3) (this field is called pt_name). It might be a remnant from the M:N thread model from the past (pre-5.0 NetBSD release)... If there is a use-case from a debugger point of view to set a new name, I will add dedicated calls.

I think it's cleaner and simpler to use the ptrace(2) API on FreeBSD.

I was thinking about adding set/get inferiors's thread name (PT_SET_LWPNAME / PT_GET_LWPNAME are a good guess) from the checkpointing point of view... on the other hand full-process snapshoting can be done reliably mostly/only from the kernel, not from userland (at least on NetBSD)... so this apparently limits users of this interface to tracers...

If there is no real-life use-case I will implement GetName with sysctl(7) on NetBSD (after merging this code).

krytarowski added inline comments.Mar 15 2017, 11:41 AM
source/Plugins/Process/FreeBSD/FreeBSDThread.cpp
128 ↗(On Diff #91869)

Besides my other notes about dedicated ptrace(2) call for reading thread name on FreeBSD, I'm not sure whether FreeBSD supports "online" debugging (there was a dedicated GDB term I forgot right now) of a running process. If so, there is no need extra space approach.

Currently these calls for set/get thread name were moved to LLVM. I haven't checked other systems but the NetBSD one must be called for the current process.

The original NetBSD version was ported from FreeBSD... and it inherited its oddness that used to bite me. Another important note - the NetBSD LLVM version works only for pthread_t (POSIX threads), not native threads. There is also no interface exposed for users to translate native thread (LWP) <-> POSIX thread (pthread_t), it's not a lack of feature but the design that pthread_t is fully opaque. I'm not sure what's the purpose of the LLVM interface, whether to use pthread_t for the current process or any process & native thread like what might happen on Linux. I verified that other interfaces use pthread_t API out there and I accepted that revision.

Yes, the versions in LLVM are for the current process (in fact, current thread) only, which is fine for usage as a debuggee. In the debugger we need another set of functions which will read the names from the process we are debugging, and may be implemented using completely different means.

Should I implement an interface to investigate tracee's thread name [on NetBSD] in ptrace(2)? I didn't want to introduce a ptrace(2) calls for set/get thread name, as thread name stored in the kernel is shadowed in pthread_t in our libpthread(3) (this field is called pt_name). It might be a remnant from the M:N thread model from the past (pre-5.0 NetBSD release)... If there is a use-case from a debugger point of view to set a new name, I will add dedicated calls.

Displaying the thread name in the debugger is definitely useful, but not all that important on the grand scale of things. If the kernel already knows about the name, then I'd recommend reading it out from there, although for non-critical functionality like this you could make the case for keeping the kernel interface simple (although, then I don't know why is the kernel storing the name in the first place). I don't know what a real use case for *setting* a thread name from a debugger would be. I suppose someone might want to do that eventually, but it's probably not that useful, so it may be better to just leave it out for now.

I think it's cleaner and simpler to use the ptrace(2) API on FreeBSD.

I am not familiar with the FreeBSD APIs so I'd leave that to the FreeBSD maintainer.

krytarowski accepted this revision.Mar 16 2017, 11:31 AM

Thank you for your explanation. I will use approach similar to FreeBSD on NetBSD.

I agree that leaving the FreeBSD code is best for the maintainers - it's good enough.

This revision is now accepted and ready to land.Mar 16 2017, 11:31 AM
krytarowski added inline comments.Mar 16 2017, 2:57 PM
packages/Python/lldbsuite/test/tools/lldb-server/thread-name/main.cpp
6 ↗(On Diff #91869)

I overlooked it.

int
pthread_setname_np(pthread_t thread, const char *name, void *arg);

It should be:

::pthread_setname_np(::pthread_self(), "%s", name);
This revision was automatically updated to reflect the committed changes.