Sysprogs forums › Forums › VisualGDB › Static Stack Analysis
Tagged: Static Stack Analysis
- This topic has 14 replies, 3 voices, and was last updated 4 years, 6 months ago by thomasa.
-
AuthorPosts
-
November 8, 2018 at 23:00 #22643init.firstParticipant
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).
Attachments:
You must be logged in to view attached files.November 9, 2018 at 00:51 #22648supportKeymasterHi,
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.
January 27, 2020 at 11:36 #27266thomasaParticipantHi,
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
January 27, 2020 at 17:43 #27273supportKeymasterNo 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.
January 29, 2020 at 11:21 #27279thomasaParticipantHi,
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.
January 29, 2020 at 17:04 #27290supportKeymasterNo 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.
January 31, 2020 at 15:25 #27304thomasaParticipantHi,
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?
January 31, 2020 at 17:01 #27305supportKeymasterThanks, 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.
April 30, 2020 at 11:36 #28003thomasaParticipantI 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.April 30, 2020 at 11:42 #28004thomasaParticipantAh, maximum filesize…here is the Elf-File only.
April 30, 2020 at 12:19 #28005thomasaParticipantOk, with file-ending now…
April 30, 2020 at 16:09 #28006supportKeymasterSorry, 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?
May 3, 2020 at 10:45 #28027May 3, 2020 at 16:24 #28034supportKeymasterThanks, 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.
May 4, 2020 at 06:45 #28043thomasaParticipantThe static stack analysis now works. Thank you for the support.
-
AuthorPosts
- You must be logged in to reply to this topic.