Modify the linker script by

/* Inserting these two lines */ . = ALIGN(8); PROVIDE(__eh_frame = .); /* before .eh_frame rule */ .eh_frame : { KEEP (*(.eh_frame)) *(.eh_frame.*) }

How would I do this with rust-lld?

In my target.json, I tried to use linker: ld and then used the feature fde-gnu-eh-frame-hdr instead of fde-static, but that gives me an error saying that ld doesn't know the argument -Wl,--as-needed. That is why I believe I am stuck with rust-lld with flavour gnu, but that doesn't seem to recognise the __GNU_EH_FRAME_HDR. Is there a way I can make this work? Modifying the link script that rust-lld uses or with a build.rs or similar?

{
  "llvm-target": "x86_64-unknown-none",
  "arch": "x86_64",
  "os": "none",
  "executables": true,
  "linker-flavor": "ld.lld",
  "linker": "rust-lld",
  "panic-strategy": "unwind",
  ...
}

print! and eprint! macros were calling writeln! instead of write!.

Also why StdoutPrinter uses libc::printf but StderrPrinter uses libc::write? I think to avoid calling printf is better since the string is already formatted.

Looks like the LLVM 15 upgrade broke something:

   Compiling unwinding v0.1.4 (/private/tmp/unwinding)
inlinable function call in a function with debug info must have a !dbg location
  call void @_Unwind_Resume(ptr %40) #15
inlinable function call in a function with debug info must have a !dbg location
  call void @_Unwind_Resume(ptr %20) #15
inlinable function call in a function with debug info must have a !dbg location
  call void @_Unwind_Resume(ptr %50) #15
inlinable function call in a function with debug info must have a !dbg location
  call void @_Unwind_Resume(ptr %47) #15
LLVM ERROR: Broken module found, compilation aborted!
error: could not compile `unwinding`

I assume this is a rustc bug, so I've filed rust-lang/rust#101121 - but filing a bug here too, just in case.

Currently I use this to dump the used linker script to stdout and add in the eh_frames:

[target.x86_64-unknown-none]
rustflags = [
    "-C", "link-arg=-Wl,-verbose"
]

This worked ok but the problem is it is certainly not good accounting for multiple targets. For each build target we will need each linker script and that's a pretty big burden. Wonder if there is any possible way to extend from the existing linker script by patching or just stick it to some specific platforms as a setback?

PS: --eh-frame-hdr is broken in rust-lld. IDK why. I specified it directly in rustflags link-args, but even that didn't add in the GNU EH frames. That's the whole reason I needed linker script extension, or otherwise I could just use fde-gnu-eh-frame-hdr feature instead. This has something in common with #6

GNU ld on at least some platforms adds a symbol __GNU_EH_FRAME_HDR for the .eh_frame_hdr section. Add a cargo feature fde-gnu-eh-frame-hdr to enable use of this.

This PR proposes a feature called fde-deferred which, when selected, enables a new FDE finding strategy. This strategy depends on the following symbols, which may be defined by dependent crates:

extern "Rust" {
    // Required
    fn __unwinding_get_text_base(pc: usize) -> Option<usize>;

    // At least one of these must be defined
    fn __unwinding_get_eh_frame_hdr() -> Option<usize>;
    fn __unwinding_get_eh_frame() -> Option<usize>;
}

This strategy provides maximal flexibility, at the expense of requiring support from dependent crates. That is, the discovery of these base addresses is deferred to dependent crates.

As a concrete example of the usefulness of a feature like this, I'm using this crate in a bare microkernel userspace environment. In this instance, a program's PHDRs are made available to it in a nonstandard way. This fde-deferred feature would allow dependent runtime crates to pass the relevant base address information back to unwinding. In this case, for example, fde-deferred has the advantage of being linker-independent (unlike fde-gnu-eh-frame-hdr) and does not require a custom linker script (unlike fde-static).

If you are considering accepting this PR, then I will, of course, add documentation.

WIP support for ARM, can do backtrace on basic functions. Eventually, this PR will solve https://github.com/nbdd0121/unwinding/issues/3.

For a working (backtrace) example you can check https://github.com/arturkow2000/qemu-example/pull/1. You need to

export DEFMT_LOG=trace
export RUSTFLAGS=-Cforce-unwind-tables=on

before building app. For details see README in the repo.