krytarowski added a comment. > 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). https://reviews.llvm.org/D30981 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
