[Lldb-commits] [PATCH] D30981: Remove HostThreadLinux/Free/NetBSD

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In https://reviews.llvm.org/D30981#701902, @krytarowski wrote:

> 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.


https://reviews.llvm.org/D30981