crash: port rd command

[brenns10]

This implements almost every option for crash's rd command. With the identify_address_all() API it's now trivial to make the symbolized output identical to crash's. There are a lot of formatting options, which I tried to cover with a generic unit test suite that is independent from the kernel tests. And there are also linux kernel crash command tests.

The _print_memory() API will get used by the bt command to print the formatted memory between stack frames. I didn't think it merited being an exported helper API because it's so crash-specific. If necessary that can always be changed.

The only options missing are:

• -f to print dumpfile offsets. This is just too low-level for drgn, and I don't see an easy way to include it. I also have never used it myself.
• -m to print Xen host machine memory. In 2025 I'm not sure how relevant this is, and I don't think we actually support the Xen dumps necessary for this to even make sense.

Userspace memory is supported too, using the trick we discussed on matrix.

[brenns10]

The error on Python 3.8 is rather interesting. The test case intermixes positional arguments and optional arguments.

%crash> rd ffff981c2ac99bc0 -32 5
usage: rd [-e END] [-o OFFSET] [-p] [-d | -D] [-s] [-S] [-x] [-N] [-R] [-r RAW]
          [-8 | -16 | -32 | -64 | -a] [--drgn]
          address|symbol [count]
drgn: crash: rd: error: unrecognized arguments: 5

I guess I assumed that would work, but argparse doesn't allow it unless you explicitly use parse_intermixed_args(). (Though strangely it starts working in Python 3.12. I don't see anything specific in the changelog about it.)

Normally I don't use optional positionals (nargs='?') which I guess is why this is news to me. The crash rd command allows this invocation (rd ADDRESS -32 5) and it mentally makes sense to me, as far as the order of my thoughts when I run the command (read from ADDRESS in 32-bit units, and read 5 of them).

We could just enable parse_intermixed_args() for all commands, but I'm not 100% confident about it, because the docs indicate that some features won't work with it:

These parsers do not support all the argparse features, and will raise exceptions if unsupported features are used. In particular, subparsers, and mutually exclusive groups that include both optionals and positionals are not supported.

We could also allow commands to opt-in to intermixed args via a command line argument, or we could just accept that this is the way it is (and change the test). I honestly don't care too much about intermixed args. Maybe we can chat about it in today's meeting.

[brenns10]

For now, I've modified the test to not intermix positional & optional arguments. I also updated the text alignment to match crash's more accurately.

[brenns10]

Ok, this PR should be ready. It has every rd option except -m and -f. It supports userspace memory in the way we discussed on Matrix. And while they're not completed, the all-architecture tests are looking pretty good.

I'll probably look into adding the -fF[F] options for bt based on this next. So I think rd would make more sense to look at before bt, if you had to choose. It's also a more straightforward implementation, I think.

[osandov]

This is great, thank you. Just a few nitpicks.

[brenns10]

Thanks for the review. I think everything is addressed here. I noticed a funny error on my local tests, but it's reproducing on main so I think it's unrelated. I'm trying to avoid rebasing to make it easy to re-review, so crossing my fingers that it doesn't happen here. I'll file something separately for the test failure I got, if it's a real isuse.

[osandov]

Awesome, thanks!

The new hrtimer command test has been flaky, but I haven't gotten to the bottom of that yet. Is that the one you've seen?

[brenns10]

No, this is in the kmodify helpers:

======================================================================
ERROR: test_string_args (tests.linux_kernel.helpers.test_kmodify.TestCallFunction.test_string_args) [array pointer]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stepbren/repos/drgn/tests/linux_kernel/helpers/test_kmodify.py", line 183, in test_string_args
    self.assert_called(
  File "/home/stepbren/repos/drgn/tests/linux_kernel/helpers/test_kmodify.py", line 34, in assert_called
    return_value = call_function(self.prog["drgn_kmodify_test_" + name], *args)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/stepbren/repos/drgn/drgn/helpers/common/prog.py", line 115, in wrapper
    return f(args[0].prog_, *args, **kwds)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/stepbren/repos/drgn/drgn/helpers/experimental/kmodify.py", line 1501, in call_function
    implicit_convert(
TypeError: cannot convert 'char *' to incompatible type 'char *'

----------------------------------------------------------------------

It is only reproducing on my Oracle Linux laptop, not my Arch desktop or the Debian rootfs. I'm tracking it down a bit further but will file an issue if it is actually a bug.

[brenns10]

#569 :(