japaric
Support static libraries
When building together with an external runtime, the builds cargo produces are static libraries (which are then linked by the runtime, eg. when using riot-wrappers). Could cargo-call-stack be modified to cater for those cases?
I've got it to load cdylibs partially with the attached patch (feeding it my staticlib declared as cdylib), but got stuck when ".stack_sizes section not found".
If the Cargo output is a single ELF object then, in theory, cargo-stack can support that compilation mode.
Your patch looks fine to me. The issue is that your build process is dropping the .stack_sizes section generated by -Z emit-stack-sizes. You'll need a custom linker script to force the linker to keep that section. In cortex-m-rt we use this. See the unstable book for more details about -Z emit-stack-sizes.
@chrysn cargo-call-stack no longer relies on the linker keeping the .stack_sizes section (i.e. no linker script magic is required) so you may want to give this another try.
Coming back to this from the angle of first forcing my component into a bin crate (by having a minimal example that is no_std, no_main but has a no_mangle'd _start symbol invoking my entry point), l think the largest challenge here will be functions outside Rust's control -- be they OS provided functions written in C (which I may or may not manage to make available when rebuilding with LLVM) or functions from one of those dreaded SDK blobs (hello Nordic and Silicon Labs).
From a usability perspective, not all is lost -- both those components may make a reasonable statement on what requirements they have on the stack (eg. Nordic says it's 1536 bytes when not using the FPU), either per function or more likely as a whole. Initially, there can be a note telling the user that "unavailable functions were calculated with a size of 0 and need to be considered in addition"; things may still be enhanced to collect the data from other sources.
Practically ... let's see :-)