The rogue messages were coming from my code, I just wasn’t sure what the call stack looked like, because some unexpected things were getting skipped (which was the bug). I added more .trace logs and got what I needed, but it would be nice to know if there’s a way to glean the call stack somehow. It would make a REALLY handy tool if it’s hiding out somewhere.
I’m pretty sure normal binaries built with any of the cloud compilers have optimization turned on too high and all of the symbols are stripped so save code space, so it’s not practical to get a usable call stack.
When you’re running debug builds and using the GDB debugger you can see full call stacks, but that’s because it has access to the the full, non-stripped elf files. User code does not.
Don’t laugh but I have faked this out by adding debug messages to the start and end every function in question.That way I get a “stack trace” in the debug log or serial port output for my code at least. This can be hard if there are multiple early returns from a function, but that is not a best practice.
As @rickkas7 said, you need to build locally using gcc so that you have the symbol table and full ELF files in order to debug some complicated things.
The solution to that is to create a small class that logs in the constructor and destructor, then stack allocate an instance of the class in the function. It will automatically log the exit regardless of how many returns there are.
I love this approach! I tried it but when the destructor executes the name is no longer there? Instead of ‘myFunction’ supposedly stored in the private field ‘name’, I’ll get what looks like a pointer… IE: ‘8i’