I started to use DS-5 recently and applied for a evaluation license for professional version.
I followed instructions strictly from this page DS-5 Documentation & Resources / Tutorials / Getting Started with ARM DS-5 | ARM DS-5 Development Studio
But I got this error message, like this picture shows
This make me can't debug from source-level. I can't set breakpoint into c file , but i can set breakpoint into disassembly file. Is there any solutions?
Hi, When i debug the Arm Trusted Firmware with DS-5,i use the add-symbol-file command to add the symbol files. But there are some errors. add-symbol-file /home/zm/devel/fvp_optee/arm-trusted-firmware/build/fvp/debug/bl31/bl31.elf EL3:0x0 ERROR(CMD685-IMG54): ! Failed to load symbols for "bl31.elf" ! Failed to demand load DWARF debugging information: section .debug_info, offset 0xb So, how can i slove this problem?
Can you tell us which version of DS-5 you're using and if possible which DWARF format (2, 3, 4) you are using (this is usually down to a compiler option, but compilers tend to move their defaults around)? Is it possible to provide an example binary?
We have definitely had hints from some customers of an inability to load debug information and specifying DWARF3 (-g -gdwarf3 in GCC, for example) fixed it very simply. It seems as some compilers progress they generate information DS-5 somehow doesn't expect.
If you're a licensed DS-5 user you can ask this question through the normal ARM support channels, if you're worried about uploading code attachments to Community.
Hi:
The version of DS-5 is DS-5_v5.24.0, and the DWARF format is 3. I also try the DWARF format 2 and 4, but it occurs the same error.
Thank you.
According to the debug information, it's DWARF2 and seems to contain some GNU extensions of some sort -- is there any way you can add -gstrict-dwarf to the command line and see if DS-5 does better? Or actually specify (-gdwarf-3) DWARF3 or (-gdwarf-4) DWARF4 with or without -gstrict-dwarf -- any ideas on whether this is a GNU extension tripping DS-5 and whether a newer version of the standard removes the need for that extension, perhaps.
As a standards-compliant debugger, DS-5 tends not to support GNU extensions in that they can and do change at any time. Once they get codified and ratified in an actual DWARF specification, then Engineering will go and implement that stable support. However, DS-5 should probably not trip up on an extension field in this manner.
So, if you manage to figure out whether strict DWARF2, gcc DWARF3, strict DWARF3, gcc DWARF4, strict DWARF4 works okay in DS-5 we'd love to know.
Ta,
Matt
Matt,
DS-5 is rejecting the first Debug Info Entry (DIE) because the first entry specifies the working directory instead of a specific source file. The entry is probably legal (DWARF spec isn't that clear) and certainly it was accepted by previous DS-5 versions such as v5.22.
I gleamed the release notes hoping to get a clue as to what changed. Nothing stands out. Could you please check internally? For your info, here is the offending DIE entry:
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x9): GNU C 4.9.2 20140904 (prerelease) -mgeneral-regs-only -mstrict-align -mlittle-endian -mabi=lp64 -gdwarf-2 -g -O0 -O1 -std=c99 -ffreestanding -ffunction-sections -fdata-sections
<10> DW_AT_language : 1 (ANSI C)
<11> DW_AT_comp_dir : (indirect string, offset: 0xd7): /home/x/atf
<15> DW_AT_stmt_list : 0x0
<1><19>: ...
Compilation Unit @ offset 0x7e:
Length: 0x7b7 (32-bit)
Version: 2
Abbrev Offset: 67
Pointer Size: 8
Other entries would also have DW_AT_name to point to a specific source file. It would be great if you could find out why v5.24 won't accept this entry, or alternatively how to stop gcc from generating this entry.
Thanks
Hi 57hillside, zm290293817,
It looks like this is definitely a regression in DS-5, we've confirmed that it used to work and only affects DS-5 5.24.0.
We'll keep everyone updated on this thread as to when a new release of DS-5 contains a fix. Unfortunately any workaround for DS-5 5.24.0 would be non-trivial. If it's possible to use DS-5 5.23.1 then that would be our recommended solution for the time being.
Matt, Thanks for confirming the issue. I have rolled back to v5.22. Let us know when the issue is resolved. Thanks