Hi there,
I'm developing a bare metal software on ARMv8 and encounter some issues and wanted to debug the code. I downloaded DS5, I'm not sure if that's community edition or not, and seems like there's a license issue when I trying to use it as 30-day eval. I can't take a screenshot at the moment, which seems like another issue that I couldn't log in my account via DS5.
Is there any one know if there's still a community edition DS5 available somewhere?
Thanks
fs
HiMy name is Stephen and I work at Arm."DS-5" has been superseded by the Arm Development Studio ("Arm DS"). Sorry, but there is no Community Edition of DS-5 available any more.However, a 30-day free trial of Arm DS 2021.2 Gold Edition can be downloaded from:developer.arm.com/.../evaluateYou'll need to register to obtain the evaluation license. Is that what you've done already? I've just tested this and was able to obtain a license successfully. Please could you (re)try?Best regardsStephen
Hi Stephen,
Thanks for that, I'm using that instead. Trying to get used to that with a bit problem when debugging my program, it could stop at the first instruction, but when I stepped, it would go somewhere really weird not the next instruction as I expected.
BTW, my program compiled with GNU tools, and haven't got recompiled in DS. But just run it in DS. Would that work?
Thanks,
Hello, I would be very interested in @fshark's question as well.
I have successfully compiled an ARM program using the command as follows:
`clang -g -target aarch64-linux-gnu -march=armv8.5-a+memtag+rng -fsanitize=memtag -O0 hello.c -o hello.out`
and when I try to execute this program using the ARM Development Studio, DS can successfully stop at the entry point, but when I step in, it basically hangs and doesn't go anywhere.
Furthermore, if I try to stop at the `main` instead, it hangs with a weird "waitForTargetToStop" command.
Hi bothYes, you can debug executable code generated by gcc or clang (or any other Arm toolchain that generates ELF/DWARF images) using the Arm DS Debugger.In both your cases, where code execution does not proceed as expected, perhaps some exception has occurred. Are you running/debugging code on an FVP model, or on real hardware?If running on a FVP model of an Armv8-A core, ensure that "-C bp.secure_memory=false" is added as a parameter when launching the model. Take a look at the supplied Examples for usage of this parameter. Also, check that you have loaded your code into the correct/expected area of memory, and that area of memory allows code to be executed there (e.g. is the MMU on or off?)Perhaps an exception is occurring (e.g. when trying to execute Neon instructions, but the FPU is not enabled, or the current EL configuration forbids it). Suggest you try enabling exception traps - in the Breakpoints view, select Manage Signals, enable all exception traps, then run again. Any exceptions will be shown in the Commands view.If your target supports "trace", capturing the history of instruction execution can also sometimes reveal unexpected run-time issues.Hope this helpsStephen