- This topic has 14 replies, 3 voices, and was last updated 3 years, 11 months ago by
.
-
Posts
-
Hi all,
is there a tutorial or howto for Static Stack Analysis?
I opened the Embedded Memory Explorer and got the message “Function contains jumps to invalid addresses.” on all listed entries (functions).
Hi,
We have just published a tutorial showing the stack analysis here: https://visualgdb.com/tutorials/arm/stack/static/
As a quick check, could you confirm that the “Disassembly” view in the memory explorer works correctly? If yes, we will add further diagnostic logging to the stack analyzer and should be able to pinpoint it.
Hi,
is there any solution to this issue available?
If i create a project with STM processors, the “Static Stack Analysis” works correct.
On my Project with the LPC54628, using the LPCXpresso SDK 2.6, i see the same behaviour as above with the message “Function contains jumps to invalid addresses.”.The “Disassembly” view in the memory explorer works correctly.
The toutorial mentions a possibility to adapt the script/tool, but how did I not realize.
Kind Regards
No problem. First of all, please try right-clicking on the function entries that did not get analyzed correctly and select “View Analysis Log”. This should highlight the code paths triggering various warnings.
You can then customize the analyzer by cloning the following project: https://github.com/sysprogs/VisualGDBExtensibilityExamples/tree/master/PlatformSpecificStackAnalyzers/ARM. Simply build the ARMStackUsageAnalyzer.dll file and copy it into <VisualGDB Directory>\StackAnalyzers, replacing the version shipped with VisualGDB. You can then use another Visual Studio instance to step through ARM-specific stack analysis logic or to modify it to support project-specific cases.
The Disassembly view would show the results once you select a specific function on top of the view.
Hi,
the log views:
Running verbose stack analysis for EthernetPhyCheckState…
***Starting code path at 0x00020764 with stack depth = 0
###HasJumpsToUnreadableAddressesI’ve download the project and found the line , the log view point to, but if i try to build it, there are a couple of errors, because the include “using VisualGDBExtensibility;” fails.
The Dissassembly works as expected.
No problem. Please try right-clicking on the project node in Solution Explorer and select Add->Reference->Browse, then pick the full path to VisualGDBExtensibility.dll in the VisualGDB’s directory. This should resolve the build errors.
Hi,
i can debug the dll now, but that doesn’t really help me (and i don’t really know what happens).
There is the Line 129 in ARMStackUsageAnalyser.cs:
“foreach (var insn in _Host.TryReadInstructions(path.Address))”
where the return of the ‘TryReadInstructions’ with a valid function-address returns zero every time and produces the error message ‘HasJumpsToUnreadableAddresses’.
‘TryReadInstructions’ is somewhere outside the debug context and i can not reach it.
Do you have any further suggestions?
Thanks, this partially explains what is going on. TryReadInstructions() is implemented inside VisualGDB. It uses the objdump tool to disassemble the instructions at the specified address.
Most likely, something in the objdump output is preventing VisualGDB from handling this correctly. Would you be able to share the ELF file with us via our support page so that we can try reproducing the issue (please also mention the exact address that is not loaded correctly and the function that triggers it)? If not, we can provide instructions on getting the necessary information from the dump file, although it might take a few extra iterations.
I found a clue why the static stack analysis is failing. In the project where I noticed it, the firmware does not start at address 0x0. The project has a bootloader that resides there.
The firmware starts at address 0x10000 and the bootloader jumps to this address.
I cannot provide the ELF-file, but I have provided a simple example project (where the analysis worked) with the other start address, and the analysis fails.Sorry, most likely the file was too large to be uploaded. Would you be able to upload it to a file sharing service (e.g. Dropbox) and share a link with us?
Thanks, we have reproduced the problem and fixed it in the following build: VisualGDB-5.5.5.3599.msi
Let us know if you encounter further issues and we will be happy to help.
- You must be logged in to reply to this topic.