Closed lulf closed 2 years ago
Is the correct way forward to modify the thumb.rs to catch this sp modification so that the calculated value is correct?
yes, I assume the machine code analysis is not handling the sp decrement in that first str
instruction
I got this the wrong way around! The sp value is calculated correctly by cargo-call-stack, but the analysis from stack-sizes claims 0 stack usage for all the outlined functions.
Using stack-sizes
on the elf directly confirms this. It seems to be the case that all "OUTLINED_FUNCTION" reports a stack size of 0. What's the correct course of action here? Is this information simply missing from the .stack-sizes or should there be a guard in cargo-call-stack to filter outlined function symbols?
stack_sizes::analyze_object
produces a map from symbol (function) name to its stack usage. if the map does not contain the OUTLINED_FUNCTION
symbols it could be that llvm does not produce stack usage information, or it could be a bug in the stack_sizes
crate. if it's the former we could use the information from call-stack's machine code analysis.
if the map does contain the OUTLINED_FUNCTION
symbols and reports a stack usage of 0 that would be a bug in llvm. in that case, we could work around the bug by using the heuristic: if it's OUTLINED_FUNCTION*
and stack usage is zero then use the info from call-stack's machine code analysis.
is the code that runs into the issue public? if not, could you run nm -CSn
on the ELF file and report here the lines that contain the OUTLINED_FUNCTION*
symbols? I'm wondering if these OUTLINE_FUNCTIONS
are not proper functions but rather labels. In assembly you can write something like:
.global my_fun
my_fun:
nop
my_label:
b my_label
my_fun
is a proper function. my_label
is a label but both will be symbols reported by nm
; each should have different flags in the ELF metadata (e.g. global vs local). I wonder if the OUTLINED_FUNCTION*
looks like a label and stack_sizes
or call-stack is doing something wrong
The only output with OUTLINED_FUNCTION is this:
0003fe8e 00000024 t OUTLINED_FUNCTION_13
The project is public, you can find it here:
https://github.com/drogue-iot/drogue-device/tree/main/examples/nrf52/microbit/bt-mesh
running cargo call-stack --bin microbit-bt-mesh
in that folder should produce the error.
thanks for the link. I had a look and this seems to be a llvm bug. all the OUTLINED_FUNCTIONS_*
symbols (or rather their addresses) are included in the .stack_sizes
section but they all appear there with a stack usage of 0 even the ones that actually do use the stack.
I couldn't find a bug report and would have a hard time producing a small repro case to submit a bug report so I'll pass on that.
I'll add some workarounds to call-stack to deal with this.
v0.1.11 includes a workaround for this issue
I have an application that triggers this assert in
cargo-call-stack
:originating from this code
Running objdump reveals the instructions for OUTLINED_FUNCTION_13:
And it looks like it is supposed to use 8 bytes of stack.
Is the correct way forward to modify the thumb.rs to catch this sp modification so that the calculated value is correct?