| Age | Commit message (Collapse) | Author |
|
PT_LWPINFO from FreeBSD is almost never intended to be expressed with
PT_LWPINFO in NetBSD. PT_GET_SIGINFO reads siginfo_t with the signal
information about the event, on FreeBSD siginfo_t is merged into
ptrace_lwpinfo and returns the thread that received the event (not the
first one in a list like on NetBSD).
|
|
|
|
that are needed by the new dtrace. these don't do anything yet,
but dtrace doesn't mind. I'll do a full resync to the latest FreeBSD
libproc / librtld_db later.
|
|
Also use PRIxPTR instead of PRIuPTR, which is apparently misused.
|
|
|
|
This header in this context is freebsdism.
|
|
is a 32-bit or 64-bit process. the interface is from freebsd
but the implementation is different.
needed by dtrace.
|
|
|
|
in that we use lp_lwpid as an input to say which lwp to operate on.
freebsd passes the lwpid as the pid, which works fine there
since freebsd has globally unique LWP IDs which are also distinct
from process IDs. the libproc interface that uses this ptrace() call
is only supposed to return info for the process's representative LWP,
so just initialize pl_lwpid to 1 before using it.
|
|
only attempt to look up symbols in the dynsym table if the object
actually has one, which a separate debuginfo file does not.
|
|
|
|
|
|
|
|
The workaround was confused when MKLLVM was set, but HAVE_LLVM was not.
Solution suggested by joerg.
|
|
|
|
of continue, so that we don't get kernel diagnostic messages about
detaching traced processes.
|
|
|
|
uintptr_t on 32 bit machines, so cast to it.
|
|
|
|
|