[lldb-dev] Shared Process plugin between Linux and BSD

Greg Clayton via lldb-dev lldb-dev at lists.llvm.org
Wed Dec 14 13:23:06 PST 2016


I am wondering if it would be better to make a common base class, like NativeProcessPtrace, where all of the common Ptrace stuff lives and then subclass and override the functions that are different. There seemed to be a bunch of "#if defined(NETBSD)" stuff in the second patch. Without extra code context in the diffs it is hard to see if the the function is all one or the other, or just a very small part is overridden. Code like this:

Error NativeProcessLinux::ReadMemory(lldb::addr_t addr, void *buf, size_t size,
                                     size_t &bytes_read) {
#if !defined(__NetBSD__)
  if (ProcessVmReadvSupported()) {
#else
  {
#endif
    // The process_vm_readv path is about 50 times faster than ptrace api. We
    // want to use
    // this syscall if it is supported.
@ -2145,7 +2173,11 @@ Error NativeProcessLinux::ReadMemory(lld
    remote_iov.iov_base = reinterpret_cast<void *>(addr);
    remote_iov.iov_len = size;

#if !defined(__NetBSD__)
    bytes_read = process_vm_readv(pid, &local_iov, 1, &remote_iov, 1, 0);
#else
    bytes_read = 0;
#endif
    const bool success = bytes_read == size;

    Log *log(GetLogIfAllCategoriesSet(LIBLLDB_LOG_PROCESS));


All the extra #defines are the C way of doing things and really make the code a bit messy. We should probably just have NativeProcessLinux and NativeProcessNetBSD that inherit from NativeProcessPtrace, and then each would override the ReadMemory function.

That is my opinion, I would also wait for opinions from the people that actually work on the NativeProcessLinux plug-in as their opinion will count more than mine. SVN blame can probably tell you who did most of it.

Greg Clayton


> On Dec 14, 2016, at 11:34 AM, Kamil Rytarowski via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Hello,
> 
> I've prepared two patches to make the Linux Process Plugin buildable on
> NetBSD.
> 
> The diff will help to transform the Linux process plugin to common code,
> shared between Linux and BSDs (FreeBSD, NetBSD).
> 
> lldb-git: Enable Linux Process plugin on NetBSD
> 
> https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=commitdiff;h=4b00674e876ebfe427743759de13ead420112fd4
> 
> lldb-git: Disable unbuildable code-fragments in the
> LinuxProcessPlugin/NetBSD
> 
> https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=commitdiff;h=e1ef012c16ab7729918ae367150b13bf0d77650b
> 
> Comments to the disabled code:
> 
> 1. Thread resume/suspend operation - to be implemented on NetBSD with
> ptrace(2).
> 
> 2. PTRACE_SETSIGINFO - equivalent currently unsupported, I will need to
> add support for it in ptrace(2).
> 
> 3. PTRACE_O_TRACEEXEC, PTRACE_O_TRACECLONE, PTRACE_O_TRACEEXIT -
> equivalent to be implemented.
> 
> 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).
> 
> 7. SIGTRAP has currently only two si_code values (specified by POSIX).
> 
> 8. No SI_TKILL available.
> 
> 9. There is no process_vm_readv/process_vm_writev call available.
> 
> 10. __WALL and __WNOTHREAD are Linux specific, but they have their
> counterparts.
> 
> 11. The cpu_set_t structure and appropriate functions have similar
> counterparts on NetBSD.
> 
> 12. No <sys/procfs.h> and no dependency of procfs (/proc) is acceptable,
> everything shall be accessible through ptrace(2) and sysctl(7).
> 
> 13. personality.h - unsupported as header/function call, compatibility
> with other OSes (mostly Linux) implemented on syscall level.
> 
> 14. Process, system thread (lwp) and POSIX (pthread_t) thread are not
> the same on NetBSD, unlike some other systems and cannot be mixed.
> 
> 
> 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.
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev



More information about the lldb-dev mailing list