The underlying eBPF mechanism requires elevated privileges to access kernel tracing infrastructure. Root access or CAP_BPF/CAP_SYS_ADMIN capabilities are needed.
Both uprobe and GDB modify target process instructions (inserting breakpoints). Using them together may lead to conflicts and unpredictable behavior.
eBPF helper functions do not support handling page faults, which may cause failures when reading virtual addresses in the target process. This is a design limitation of eBPF.
Reference: https://lists.iovisor.org/g/iovisor-dev/topic/accessing_user_memory_and/21386221
Although eBPF technically supports modifying process behavior to some extent, GhostScope is designed as a read-only tool and cannot modify program state, variable values, or control flow. This ensures safety in production environments.
Currently only supports Linux operating system due to its core dependency on eBPF and uprobe.
Primary focus is on C language, which has the best support. C++ and Rust are supported with limitations - advanced language features such as Rust async functions and C++ templates have limited support and require significant effort to improve gradually.
For interpreted languages (Lua, Python, Ruby, etc.), only the interpreter itself can be traced (since interpreters are typically implemented in compiled languages). Tracing script code is technically feasible but requires substantial development time. JIT language support is an even more distant goal.
Currently only supports x86_64 (AMD64) architecture. Other platforms (such as ARM64) are technically feasible but require time for adaptation and testing.
Based on uprobe implementation, each probe trigger incurs a context switch overhead plus eBPF program execution time. If probes are set on hot paths, they may significantly impact the monitored process performance. Use with caution.
Uses ring buffer to pass events between eBPF programs and userspace. If event generation rate exceeds userspace consumption capacity, the kernel will drop events, leading to trace data loss. GhostScope's error reporting is not yet comprehensive (will learn from bpftrace's approach in the future); avoid setting too many probes on high-frequency paths.
Primarily tested and validated with DWARF 5 format. Theoretically supports DWARF 2-5, but other versions may have compatibility issues. Some DWARF expression instructions are not yet supported for conversion to eBPF (purely due to implementation not being completed yet) and will provide clear error messages when encountered.
Compiler optimizations (-O2, -O3) can cause variables to be optimized away or generate complex DWARF expressions. GhostScope will attempt to parse them, including inline function support, but some variables may be inaccessible (shown as OptimizedOut) because the compiler optimized them away.
GhostScope scans /proc/PID/maps at startup to obtain loaded dynamic library information. As long as GhostScope is started after dlopen, tracing works normally. Future plans include dynamically monitoring process dlopen behavior for better user experience.
When using -t <exec_path> (start from an executable path), global variables are currently not supported. Resolving global variables at runtime requires ASLR section offsets derived from the target process's /proc/<pid>/maps (per-module offsets for .text/.rodata/.data/.bss). In -t mode there is no known PID context to safely compute and populate these offsets into the eBPF-side map, so global variables are disabled. Use -p <pid> mode to enable globals (offsets are computed and populated automatically).