Commit c48cddbdb0 ("libdrgn: ppc64: fix stack unwinding since Linux
v5.11 and before v4.20") is the only change necessary for Linux v6.2.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
get_registers_from_frame_pointer() has a sanity check that the unwound
frame pointer must be greater than the current frame pointer. This is
generally true if the entire program is using frame pointers, but not
necessarily otherwise. In particular, if the program is a Linux kernel
configured with ORC, most of the time, rbp is a general purpose
register; it is only used as a frame pointer in special cases without
unwinder information like BPF programs. Those cases are exactly when we
want the frame pointer unwinder, but depending on what the caller was
using rbp for, the frame pointer unwinder might bail prematurely.
Let's remove the sanity check. In the worst case, this could lead us off
into the weeds chasing pointers, but the iteration limit in
drgn_get_stack_trace() prevents that from being dangerous.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
ppc64's crash_setup_regs() calls ppc_save_regs(), which isn't exported.
So, we need to provide our own implementation. At this point, we might
as well just copy the implementations of crash_setup_regs() for x86-64
and AArch64 and stop trying to use crash_setup_regs().
Signed-off-by: Omar Sandoval <osandov@osandov.com>
When the architecture is missing virtual address translation or the
kernel is configured with SLOB, print_annotated_stack() will not
identify slab objects.
Fixes: 05041423c7 ("drgn.helpers.common.stack: add print_annotated_stack helper function")
Signed-off-by: Omar Sandoval <osandov@osandov.com>
identify_address() is supposed to be best-effort, but if it is called on
an architecture without virtual address translation support, it will
raise a NotImplementedError. Let's catch and ignore it.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
It's useful to check in on a long run without needing to scroll back and
check whether each kernel version passed or failed.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
linux_kernel_get_initial_registers_ppc64() depends on the size of struct
pt_regs, but this has changed multiple times, in:
- Linux kernel commit 4c2de74cc869 ("powerpc/64: Interrupts save PPR on stack rather than
thread_struct") (in v4.20)
- Linux kernel commit 66f93c5a02d5 ("powerpc/64: Fix kernel stack
16-byte alignment") (in v4.20)
- Linux kernel commit 8e560921b58c ("powerpc/book3s64/pkeys:
Store/restore userspace AMR/IAMR correctly on entry and exit from
kernel") (in v5.11)
It also depends on the overhead stored before struct pt_regs on the
stack, which changed in Linux kernel commit cd52414d5a6c ("powerpc/64:
ELFv2 use minimal stack frames in int and switch frame sizes") (in
v6.2).
We can handle all of these cases by reading the previous r1 from memory
instead of computing it from a hard-coded size and finding the struct
pt_regs based on that r1 and the actual size of struct pt_regs.
Reported in #232.
Reported-by: Sourabh Jain <jainsourabh679@gmail.com>
Signed-off-by: Omar Sandoval <osandov@osandov.com>
I changed the default workflow permissions to be restrictive, but I
forgot that the vmtest build needs to upload assets. Add write
permissions for the contents scope, which seems to cover asset uploads.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
The vmtest build is silently failing to upload kernel builds. We're not
checking for HTTP errors, so let's see if that provides some
information.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
This should fix the "HTTP Error 403: rate limit exceeded" errors we've
been seeing. (I don't know if GitHub Actions used to do this
automatically or they started being stricter about rate limits.)
Signed-off-by: Omar Sandoval <osandov@osandov.com>
We're getting a bunch of test failures with "HTTP Error 403: rate limit
exceeded" from the GitHub API. The API apparently includes additional
information in the response, so let's print that so that we can figure
out which limit we're hitting.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
The Linux kernel apparently enables -Wundef, so although #if is correct,
it results in a warning. Use #ifdef instead.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
The only relocation type I saw in Debian's kernel module debug info was
R_390_32. R_390_8, R_390_16, R_390_64, R_390_PC16, R_390_PC32, and
R_390_PC64 are trivial to support, as well. The Linux kernel supports
many more, but hopefully they won't show up for debug info.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
I've had lots of reports that turned out to be due to missing debug info
(e.g., #161, #175, #231, and more offline). A big part of the problem is
probably that the warning gets lost among the startup information. Let's
move the warning to be the last thing we print and also color it.
After the debug info discovery rework, we can print more specific
advice, but this is better than nothing.
Closes#41.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
Konrad Borowski pointed out that add_to_possibly_null_pointer() relies
on GCC-specific behavior:
https://fosstodon.org/@xfix/109542070338182493. CONTRIBUTING.rst
mentions that we assume that casting between pointers and integers does
not change the bit representation, but we might as well document it
here, too.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
The current test case only checks that getting a stack trace succeeds.
By having the test kernel module create a struct pt_regs, we can
actually test that we get a reasonable stack trace.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
for_each_page() can return offline pages that don't actually exist.
Fixing this is difficult (see #228), but working around it by catching
FaultError is easy. Document the recommended usage.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
CONFIG_SLOB was renamed to CONFIG_SLOB_DEPRECATED during the Linux 6.2
merge window. Let's prepare for that now before rc1 is released.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
Currently, looking up a type with template arguments results in an
"invalid character" syntax error on the "<" character. The DWARF index
includes template arguments in indexed names, so we need to do lookups
including the template arguments. Full support for this would require
parsing the template argument list syntax and normalizing it or looking
it up as an AST in some way. For now, it's at least an improvement to
pass the user's string verbatim. To do so, kludge it by adding a token
containing everything from "<" to the matching ">" to the C++ lexer and
appending that to the identifier.
Co-authored-by: Omar Sandoval <osandov@osandov.com>
Signed-off-by: Omar Sandoval <osandov@osandov.com>
Signed-off-by: Kevin Svetlitski <svetlitski@meta.com>
Commit 89eb868e95 ("helpers: make find_task() work on recent kernels")
made radix_tree_lookup() and radix_tree_for_each() work for basic
XArrays. However, it doesn't handle a couple of more advanced features:
multi-index entries (which old radix trees actually also supported) and
zero entries. It has also been really confusing to explain to people
unfamiliar with the radix tree -> XArray transition that they should use
helpers named radix_tree for a structure named xarray.
So, let's finally add xa_load(), xa_for_each(), and some additional
auxiliary helpers. The non-recursive xa_for_each() implementation is
based on Kevin Svetlitski's C implementation from commit 2b47583c73
("Rewrite linux helper iterators in C"). radix_tree_lookup() and
radix_tree_for_each() share the implementation with xa_load() and
xa_for_each(), respectively, so they are mostly interchangeable.
Fixes: #61
Signed-off-by: Omar Sandoval <osandov@osandov.com>
I wanted to add tests for the radix tree helpers, but found that they
have never worked for Linux 4.4. Linux 4.4 has been EOL for almost a
year, so rather than going out of our way to support it, let's just stop
testing it. I'm not going to go back and remove existing support for
4.4 (yet), but I'm also not going to make sure future changes support
it.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
I want to add support for multi-index XArray entries. This requires
CONFIG_XARRAY_MULTI. The easiest way to enable that is by enabling
CONFIG_TRANSPARENT_HUGEPAGE. We'll probably also want to test helpers
for transparent hugepages themselves later, so let's also enable
CONFIG_READ_ONLY_THP_FOR_FS.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
We're calling Py_BuildValue() with the "k" format for unsigned long but
passing the enum value itself, which is promoted to int. I don't know
whether there are any ABIs where this matters in practice, but let's use
"K" and cast to unsigned long long explicitly to be safe.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
Instead, define the list of constant classes in one place so we can
generate all 3 places that need it.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
PyUnicode_FSConverter() already handles os.PathLike, so we only need to
handle None and save the string and length.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
It feels icky to write code that, for example, passes a uint64_t to
PyLong_FromUnsignedLongLong(). In practice it's fine, but it's much
nicer to have conversion functions specifically for the stdint.h types.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
This DWARF tag is used by C++ classes which take a variable number
of template parameters, such as std::variant and std::tuple.
Signed-off-by: Alastair Robertson <ajor@meta.com>
Thanks to commit c08f6be52a ("vmtest: kbuild: add
CONFIG_MODULE_UNLOAD=y"), I was finally able to try unloading the test
kernel module and found a trivial copy-and-paste error. Fix it.
Fixes: 42e7d474d1 ("drgn.helpers.linux.mm: add compound page helpers")
Signed-off-by: Omar Sandoval <osandov@osandov.com>
While reviewing #214, I realized that we have very little documentation
for drgn_architecture_info (and platform internals in general). Let's
document all of the important stuff, and in particular how to add
support for new architectures.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
While documenting struct drgn_architecture_info, I realized that
demangle_return_address() is difficult to explain. It's more
straightforward to define this functionality as demangling any registers
that are mangled when using CFI rather than just the return address
register.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
