I am communicating with Kamil about the possibility of sharing code between the two plugins. We plan to have a common base class for the shared functionality between the OSs. I have asked Kamil to perform this experiment, so we can identify which parts of the code can be shared in the first place. My thoughts on the noticed differences are below
>> >> Comments to the disabled code: >> >> 1. Thread resume/suspend operation - to be implemented on NetBSD with >> ptrace(2). This is going to be the trickiest part, as thread management works quite differently on the two OSs. we'll need to investigate more on how much we can reuse here >> >> 2. PTRACE_SETSIGINFO - equivalent currently unsupported, I will need to >> add support for it in ptrace(2). This value is currently only used in logging code, so we can just remove it from the code base. However, it's a useful thing to have for the future, so it may be worth making sure the NetBSD kernel supports it. >> >> 3. PTRACE_O_TRACEEXEC, PTRACE_O_TRACECLONE, PTRACE_O_TRACEEXIT - >> equivalent to be implemented. Do you mean "implemented in lldb-server" or "implemented in the kernel"? Being notified when the inferior exec()s would definitely be good. Tracing thread creation and exit is a nice-to-have but low priority. The only reason we used it on linux is because that's the only way to auto-attach to new threads, but I think that for you that will happen automatically. >> >> 4. No tracing of VFORK events implemented. >> >> 5. Hardware assisted watchpoints (debug registers on amd64) have their >> dedicated ptrace(2) API to set/unset watchpoints, they do not export raw >> debug registers. >> >> 6. Other ptrace(2) calls have their equivalents on NetBSD >> (PTRACE_PEEKUSER, PTRACE_POKEUSER etc). Cool, I guess that means we can share (Read|Write)Memory(WithoutTrap|). >> >> 7. SIGTRAP has currently only two si_code values (specified by POSIX). The code for decoding si_code values is already messy and in need of a rewrite. I think the act of decoding si_code values will need to be OS- (and maybe event architecture-) specific, but the actions taken upon individual events should be quite similar. >> >> 8. No SI_TKILL available. This is used because when a single thread in a process stops, we need to go and manually stop all other threads. The whole function around this should probably be moved into the linux-specific class, as you don't need to do anything special to interrupt a process (IIUC). >> >> 9. There is no process_vm_readv/process_vm_writev call available. These are used only as a preformance optimization on linux. If (PEEK|POKE)DATA work the same way, we can put that in the base class. Then, linux can override and do it's fancy thing. >> >> 10. __WALL and __WNOTHREAD are Linux specific, but they have their >> counterparts. We should probably have a waitpid wrapper, which adds any os-specific flags if necessary. We can put the EINTR handling there as well to make it's usage easier. >> >> 11. The cpu_set_t structure and appropriate functions have similar >> counterparts on NetBSD. This is only used to work around a bug in the linux arm64 kernels. I don't think you need to worry yourself with that. It can stay hidden in NativeThreadLinux::SingleStep >> >> 12. No <sys/procfs.h> and no dependency of procfs (/proc) is acceptable, >> everything shall be accessible through ptrace(2) and sysctl(7). We'll need to check whether the appropriate interfaces are in place to abstract this (I expect it to be the case), and add new ones if necessary. >> >> 13. personality.h - unsupported as header/function call, compatibility >> with other OSes (mostly Linux) implemented on syscall level. This was already dead code, and I have removed it. >> >> 14. Process, system thread (lwp) and POSIX (pthread_t) thread are not >> the same on NetBSD, unlike some other systems and cannot be mixed. I believe the code has already good separation between thread and process IDs, and doesn't use pthread_t, so this shouldn't be a problem. NetBSD-specific pthread_t debugging code can be contained in the NetBSD class. >> >> >> The currently missing features on the NetBSD side don't stop us from >> making a functional implementation, lacing interfaces might be added >> after getting the core part to work. Agreed. The only thing that slightly worries me is the lack of execve() tracing capability, if I understood correctly. While it probably may be possible to work without it. I'd think about adding it nonetheless. good luck, pl _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
