tweedegolf/stackdump

A set of rust crates for making stack dumps and getting stack traces out of them

stackdump's Issues

Support DW_TAG_typedef

Cannot compile on 32-bit system

I get the error that bitvec's BitView trait is not implemented on u64.
https://docs.rs/bitvec/1.0.1/src/bitvec/store.rs.html#194-195

Support bit locations instead of only byte locations

So far it hasn't come up, but all sizes and offsets are in bytes so far. This is likely not good enough.
C bitfields for example won't work with that.

Internally, all variable data already uses a bitvec, so it's mostly a matter of switching all bytes to bits.

Capturing stack fails, calculating stack_size too big.

Summary

When stack capture is created, the stack_size is calculated. Debugging our project I see that this is calculated to be 536875968, which is rather large, and seems to rather be a memory address, 0x200013c0.

Story

So I realized that I cannot print the stack capture on start, but fpu and core registers are fine with this:

    if is_capture_made() {
        reset_capture_made();

        info!("STACKCAPTURE {=[u8]:x}", unsafe {
            STACK_CAPTURE
                .assume_init_ref()
                .bytes()
                .collect::<Vec<u8, 0x4000>>()
        });
        info!("CORECAPTURE {=[u8]:x}", unsafe {
            CORE_REGISTERS_CAPTURE
                .assume_init_ref()
                .bytes()
                .collect::<Vec<u8, 128>>()
        });
        info!("FPUCAPTURE {=[u8]:x}", unsafe {
            FPU_REGISTERS_CAPTURE
                .assume_init_ref()
                .bytes()
                .collect::<Vec<u8, 256>>()
        });

0.000000 INFO CORECAPTURE [2, 0, 0, 10, 0, 9c, b6, 3, 20, 28, e7, 0, 20, 70, e7, 0, 20, 27, ea, 0, 20, 28, e7, 0, 20, 70, e7, 0, 20, 28, e7, 0, 20, e8, b6, 3, 20, 6, 0, 0, 0, b0, d3, 0, 20, 1, 0, 0, 0, e7, 7, 0, 0, 0, 0, 0, 0, 98, b6, 3, 20, 21, eb, 3, 0, a0, 75, 4, 0]
└─ src/main.rs:108
0.000000 INFO FPUCAPTURE [2, 0, 1, 20, 0, 0, 0, 8c, 42, 0, 0, a0, 42, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
└─ src/main.rs:114

Then I tried to debug the issue, (but debug itself became the issue, then we solved that) and saw that stack_size value turns out to be something resembling a memory address.

The issue is that I still can't debug in opt = 0 , therefore cannot follow what is going wrong there.
Some data (will provide)

Improve crossplatformness

Currently only cortex m is supported.
However, a lot of tracing code (except for stack unwinding) is almost cross platform.

This should be cleaned up so it can be reused for new platforms.

Set up CI

No support for big endian targets

Pretty much all code assumes little endian because this is by far the most common architecture.
This only becomes important when a big-endian arch needs to be supported

Support multiple binaries

Often, devices run multiple binaries at the same time. For example: a bootloader and a main application.
If you make a stackdump at any arbitrary point, then it could be of either of the two binaries and if you try to decode with the wrong one you'll get an error.

Handle recursive types

Somehow I didn't see this one coming even though it's obvious.

Embassy defines a TaskHeader: https://github.com/embassy-rs/embassy/blob/db685c04049449ac3e4f256f2e7e26dad550d94c/embassy/src/executor/raw/mod.rs#L49
It has a run_queue_item.
The RunQueueItem has a pointer to a TaskHeader: https://github.com/embassy-rs/embassy/blob/db685c04049449ac3e4f256f2e7e26dad550d94c/embassy/src/executor/raw/run_queue.rs#L9

This causes the type deduction code to go in an infinite loop, leading to a stackoverflow.
This probably needs some kind of type caching to fix where it recognizes that it has already read this type and just copy it from the cache.

No support for multiple address spaces

It is assumed all memory lives in the same address space while that is not necessarily the case for all architectures.

Possible Cortex-M breakage

There are some changes being made to cortex-m-rt as described here: knurling-rs/probe-run#382

Since stackdump was inspired by probe-run it's very well possible that something will go wrong with unwinding the bottom frame as well. This should be tested again.

Fail gracefully on populating RegisterData and MemoryRegions from iterators

Currently, RegisterData and MemoryRegion panic in their FromIterator::from_iter implementations if:

• the first item does not match the expected identifier
• the iterator does not contain enough items

This is undesirable when handling possibly corrupted data. I propose adding a non-panicking way to build RegisterData and MemoryRegion objects from byte iterators

Improve speed

Tracing is getting a little bit slow.
In one of my work projects it now takes ~3 secs to complete.

Support `RequiresMemory` evaluation step

Got an error:

Required step of location evaluation logic not implemented: RequiresMemory { address: 537114872, size: 4, space: None, base_type: UnitOffset(0) }

fn capture accepts 3 arguments but examples have 4.

In the examples and README's the capture function accepts 4 arguments.

stackdump_capture::cortex_m::capture(
                &mut *STACK_CAPTURE.as_mut_ptr(),
                &mut *CORE_REGISTERS_CAPTURE.as_mut_ptr(),
                &mut *FPU_REGISTERS_CAPTURE.as_mut_ptr(),
                &cs,
            );

But it is defined to accept 3 arguments in the source.

/// Capture the core & fpu registers and the stack
#[cfg(has_fpu)]
pub fn capture<const SIZE: usize>(
    stack: &mut ArrayMemoryRegion<SIZE>,
    core_registers: &mut ArrayRegisterData<16, u32>,
    fpu_registers: &mut ArrayRegisterData<32, u32>,
) {
    capture_core_registers(core_registers);
    capture_fpu_registers(fpu_registers);
    capture_stack(
        core_registers
            .register(stackdump_core::gimli::Arm::SP)
            .unwrap(),
        stack,
    );
}

resulting in this error:

error[E0061]: this function takes 3 arguments but 4 arguments were supplied
  --> src/common.rs:53:13
   |
53 |               stackdump_capture::cortex_m::capture(
   |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
56 |                   &mut *FPU_REGISTERS_CAPTURE.as_mut_ptr(),
   |  _________________________________________________________-
57 | |                 &cs,
   | |                 ---
   | |_________________|_|
   |                   | help: remove the extra argument
   |                   unexpected argument of type `&&CriticalSection`
   |
note: function defined here
  --> /Users/mali/.cargo/registry/src/index.crates.io-6f17d22bba15001f/stackdump-capture-0.4.0/src/cortex_m.rs:23:8
   |
23 | pub fn capture<const SIZE: usize>(
   |        ^^^^^^^