DS-5 FVP debugger always shows "Failed to load symbols for "Hello World.axf""

Connected to stopped target ARM FVP - Cortex-A8

Execution stopped at: S:0x00000000

loadfile "G:\常用文件夹\ARM Related\DS-5 Workspace\Hello World\Debug\Hello World.axf"

S:0x00000000   SVCLE    #0xdfdfcf

Loaded section ER_RO: S:0x00008000 ~ S:0x000093B3 (size 0x13B4)

Loaded section ER_RW: S:0x000093B4 ~ S:0x000093C3 (size 0x10)

Loaded section ER_ZI: S:0x000093C4 ~ S:0x0000951F (size 0x15C)

Entry point S:0x00008000

ERROR(CMD685-IMG54):

! Failed to load symbols for "Hello World.axf"

! Failed to demand load DWARF debugging information: section .debug_info, offset 0xb

cd "G:\常用文件夹\ARM Related\DS-5 Workspace"

Working directory "G:\常用文件夹\ARM Related\DS-5 Workspace"

set debug-from main

start

Starting target with no symbolic information loaded

Execution stopped at: S:0x00008000

WARNING(CMD399-COR168):

! Failed to start the target

! No function named "main" could be found

WARNING(CMD407): Trying the entry point instead

S:0x00008000   BL       {pc}+8 ; 0x8008

wait

break -p "G:\常用文件夹\ARM Related\DS-5 Workspace\TestProjecct\main.c":32

WARNING(CMD452-COR167):

! Breakpoint 2 has been pended

! No compilation unit matching "G:/常用文件夹/ARM Related/DS-5 Workspace/TestProjecct/main.c" was found

condition 2

break-script 2 ""

ignore 2 0

break-stop-on-cores 2

unsilence 2

Breakpoint 2 unsilenced

This is what command view looks like

This part

...

ERROR(CMD685-IMG54):

! Failed to load symbols for "Hello World.axf"

! Failed to demand load DWARF debugging information: section .debug_info, offset 0xb

...

indicates that the debug information in the image is corrupt.

Where did the image come from?  Is it one of the supplied examples or did you build the image yourself?  If so, what compiler and options did you use?

Perhaps you can attach the image to this thread.

I compiled it by myself, it's ARM compiler 5. And here is the file

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.

Ta,

Matt

Matt, Thanks for confirming the issue. I have rolled back to v5.22. Let us know when the issue is resolved. Thanks