GDB reports Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x21b99

[Darius]

When using the toolchain to build a project for the Cypress FX3 it works, but running GDB gives..
[ur 23:21] ~/work/micro/ussio/ussio01 >bsdmake TCHAIN=/usr/local/gcc-arm-none-eabi-4_7-2013q3 TCHAIN_VER=4.7.4 debug
/usr/local/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-gdb -x /Users/darius/work/micro/ussio/ussio01/gdb.cfg main.elf
GNU gdb (GNU Tools for ARM Embedded Processors) 7.4.1.20130913-cvs
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /Users/darius/work/micro/ussio/ussio01/obj/main.elf...done.
0x00000000 in ?? ()
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000053 pc: 0x40007f50
MMU: enabled, D-Cache: enabled, I-Cache: enabled
JTAG tap: fx3.cpu tap/device found: 0x07926069 (mfg: 0x034, part: 0x7926, ver: 0x0)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000053 pc: 0x40007fa0
MMU: enabled, D-Cache: enabled, I-Cache: enabled
NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'.
NOTE! Severe performance degradation without working memory enabled.
NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'.
cpsr (/32): 0x60000053
/Users/darius/work/micro/ussio/ussio01/gdb.cfg:26: Error in sourced command file:
Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x1d164 [in module /Users/darius/work/micro/ussio/ussio01/obj/main.elf]

This happens using the prebuilt OSX binaries for 4.7-2012q4, 4.7-2013q3 and 4.8-2014q4.
I am using OSX 10.9, uname -a says
Darwin ur.dons.net.au 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64

I have a working toolchain that I installed using Home Brew a while ago which reports as..
[ur 23:17] ~ >/usr/local/Cellar/gcc-arm-none-eabi/20120614/bin/arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/Cellar/gcc-arm-none-eabi/20120614/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc-arm-none-eabi/20120614/libexec/gcc/arm-none-eabi/4.6.2/lto-wrapper
Target: arm-none-eabi
Configured with: /private/tmp/homebrew-gcc-arm-none-eabi-20120614-RPZI/gcc-arm-none-eabi-4_6-2012q2-20120614/src/gcc/configure --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=arm-none-eabi --prefix=/usr/local/Cellar/gcc-arm-none-eabi/20120614 --enable-languages=c,c++ --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-lto --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-sysroot=/usr/local/Cellar/gcc-arm-none-eabi/20120614/arm-none-eabi --with-gmp=/private/tmp/homebrew-gcc-arm-none-eabi-20120614-RPZI/gcc-arm-none-eabi-4_6-2012q2-20120614/build-macosx/host-libs/usr --with-mpfr=/private/tmp/homebrew-gcc-arm-none-eabi-20120614-RPZI/gcc-arm-none-eabi-4_6-2012q2-20120614/build-macosx/host-libs/usr --with-mpc=/private/tmp/homebrew-gcc-arm-none-eabi-20120614-RPZI/gcc-arm-none-eabi-4_6-2012q2-20120614/build-macosx/host-libs/usr --with-ppl=/private/tmp/homebrew-gcc-arm-none-eabi-20120614-RPZI/gcc-arm-none-eabi-4_6-2012q2-20120614/build-macosx/host-libs/usr --with-cloog=/private/tmp/homebrew-gcc-arm-none-eabi-20120614-RPZI/gcc-arm-none-eabi-4_6-2012q2-20120614/build-macosx/host-libs/usr --with-libelf=/private/tmp/homebrew-gcc-arm-none-eabi-20120614-RPZI/gcc-arm-none-eabi-4_6-2012q2-20120614/build-macosx/host-libs/usr --with-host-libstdcxx=-lstdc++ --with-pkgversion='GNU Tools for ARM Embedded Processors' --with-extra-multilibs=armv6-m,armv7-m,armv7e-m
Thread model: single
gcc version 4.6.2 20120613 (release) [ARM/embedded-4_6-branch revision 188521] (GNU Tools for ARM Embedded Processors)

The code is built like so
[[ur 23:20] ~/work/micro/ussio/ussio01 >bsdmake TCHAIN=/usr/local/gcc-arm-none-eabi-4_7-2013q3 TCHAIN_VER=4.7.4
/usr/local/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-gcc -Os -pipe -Wall -I/Users/darius/work/micro/ussio/ussio01/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///inc -g -DTX_ENABLE_EVENT_TRACE -DDEBUG -DCYU3P_FX3=1 -D__CYU3P_TX__=1 -O0 -mcpu=arm926ej-s -mthumb-interwork -Wa,-adhlns=crc.lst -c /Users/darius/work/micro/ussio/ussio01/crc.c -o crc.o
/usr/local/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-gcc -Os -pipe -Wall -I/Users/darius/work/micro/ussio/ussio01/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///inc -g -DTX_ENABLE_EVENT_TRACE -DDEBUG -DCYU3P_FX3=1 -D__CYU3P_TX__=1 -O0 -mcpu=arm926ej-s -mthumb-interwork -Wa,-adhlns=main.lst -c /Users/darius/work/micro/ussio/ussio01/main.c -o main.o
/usr/local/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-gcc -Os -pipe -Wall -I/Users/darius/work/micro/ussio/ussio01/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///inc -g -DTX_ENABLE_EVENT_TRACE -DDEBUG -DCYU3P_FX3=1 -D__CYU3P_TX__=1 -O0 -mcpu=arm926ej-s -mthumb-interwork -Wa,-adhlns=dscr.lst -c /Users/darius/work/micro/ussio/ussio01/dscr.c -o dscr.o
/usr/local/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-gcc -Os -pipe -Wall -I/Users/darius/work/micro/ussio/ussio01/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///inc -g -DTX_ENABLE_EVENT_TRACE -DDEBUG -DCYU3P_FX3=1 -D__CYU3P_TX__=1 -O0 -mcpu=arm926ej-s -mthumb-interwork -Wa,-adhlns=cyfxtx.lst -c /Users/darius/work/micro/ussio/ussio01/../../lib/cyfx3sdk/1.3/firmware/common/cyfxtx.c -o cyfxtx.o
/usr/local/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-gcc -Os -pipe -Wall -I/Users/darius/work/micro/ussio/ussio01/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///inc -g -DTX_ENABLE_EVENT_TRACE -DDEBUG -DCYU3P_FX3=1 -D__CYU3P_TX__=1 -O0 -mcpu=arm926ej-s -mthumb-interwork -c /Users/darius/work/micro/ussio/ussio01/../../lib/cyfx3sdk/1.3/firmware/common/cyfx_gcc_startup.S
/usr/local/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-ld --no-wchar-size-warning --gc-sections -d -T /Users/darius/work/micro/ussio/ussio01/../../lib/cyfx3sdk/1.3/firmware/common/fx3_512k.ld crc.o main.o dscr.o cyfxtx.o cyfx_gcc_startup.o -Map=main.map --cref -o main.elf --entry CyU3PFirmwareEntry /Users/darius/work/micro/ussio/ussio01/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///lib/fx3_debug/cy_as0260.a /Users/darius/work/micro/ussio/ussio01/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///lib/fx3_debug/cyu3mipicsi.a /Users/darius/work/micro/ussio/ussio01/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///lib/fx3_debug/cyu3lpp.a /Users/darius/work/micro/ussio/ussio01/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///lib/fx3_debug/cyfxapi.a /Users/darius/work/micro/ussio/ussio01/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///lib/fx3_debug/cyu3threadx.a /usr/local/gcc-arm-none-eabi-4_7-2013q3/arm-none-eabi/lib/libc.a /usr/local/gcc-arm-none-eabi-4_7-2013q3/lib/gcc/arm-none-eabi/4.7.4/libgcc.a
/Users/darius/work/fx3/elf2img/elf2img -i main.elf -o main.img
Note: 256 bytes of interrupt vector code have been removed from the image.
      Use the "-vectorload yes" option to retain this code.

Unfortunately the FX3 libraries are proprietary :(
There is source for most of it but not ThreadX which it uses for threading, locks etc.

[Terry Guo (terry.guo)]

From the log you provide, I saw something like below:

-------------
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000053 pc: 0x40007fa0
MMU: enabled, D-Cache: enabled, I-Cache: enabled
-------------

Is your target a bare metal target? And what's the command in line 26 for below output?

-------------
/Users/darius/work/micro/ussio/ussio01/gdb.cfg:26: Error in sourced command file:
Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x1d164 [in module /Users/darius/work/micro/ussio/ussio01/obj/main.elf]
-------------

[Darius (darius-dons)]

Yes it is a bare metal target.

line 26 is
set $pc =0x40000000

I've attached the whole file.

[Terry Guo (terry.guo)]

Would you please dump the dwarf information encoded in the main.elf with following command?

arm-none-eabi-readelf -w main.o > main.dwf

As you said that your project is proprietary. I guess I can't ask you for the main.elf, but is it to ask for the main.dwf file? You can send it to my email <email address hidden>. We can start to discuss via email.

[Darius (darius-dons)]

I would happily send you my code, but unfortunately the binary is linked against Cypress' libraries :(

I think it would be OK to send the file you request though so I've attached it to the bug report.

[Terry Guo (terry.guo)]

According to the main.dwf, your main.elf is compiled by tool chain with version GNU C 4.6.2 20120613. Do you mean this main.elf can not work with gdb from gcc 4.7 and 4.8 release?

Have you tried to generate main.elf with tool chain from 4.7 or 4.8 releases? Can main.elf built with 4.8 release work with gdb from same release?

[Darius (darius-dons)]

Ugh sorry, I was in the wrong tree.

[Terry Guo (terry.guo)]

I am looking into following output:

-------------
/Users/darius/work/micro/ussio/ussio01/gdb.cfg:26: Error in sourced command file:
Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x1d164 [in module /Users/darius/work/micro/ussio/ussio01/obj/main.elf]
-------------

but unable to find a clue about "DIE at 0x1d164". From the main.dwf, there is no IDE located at address 0x1d164. Does anybody know how to explain the address "0x1d164"? Is it an absolute address from main.elf file?

[Darius (darius-dons)]

My original message was also done with another toolchain, sorry :( I tried 4 or 5 to try and find a working one to triage but no luck.

The correct error to go with the attached dwf file is..
Dwarf Error: Cannot find DIE at 0x0 referenced from DIE at 0x1d1b8 [in module /Users/darius/work/micro/ussio/ussio-dbg-bug/main.elf]

Sorry for the hassle.

Also, I just noticed that the address it complains about changes between builds sometimes, but I can't pin down why.
I have seen.. 0x22563 0x22090 0x1d1b8 0x22090

all with the same code, build options and toolchain.

The problem sometimes shows up when running line 1 (i.e. target ext :3333) or 26.

[Terry Guo (terry.guo)]

I just realized that I should ask for the dwarf dump of file main.elf rather than the main.o. The main.elf as the final image should contain more DIE entries than main.o then we may find that there is an DIE at offset 0x1d1b8 in .debug_info section. Would you please share the dwarf dump of file main.elf? If not suitable, you can just paste the entry at offset 0x1d1b8.

[Darius (darius-dons)]

Attached.
Note that when I ran it I saw this output..
[ur 20:14] ~/work/micro/ussio/ussio-dbg-bug >arm-none-eabi-readelf -w main.elf > main.dwf
readelf: Warning: Bogus end-of-siblings marker detected at offset 3053 in .debug_info section
readelf: Warning: Bogus end-of-siblings marker detected at offset 3054 in .debug_info section
readelf: Warning: Bogus end-of-siblings marker detected at offset 3055 in .debug_info section
readelf: Warning: Further warnings about bogus end-of-sibling markers suppressed

[Terry Guo (terry.guo)]

Below is the entry at offset 0x1d1b8, indeed there is a hole in field DW_AT_type:

 <2><1d1b8>: Abbrev Number: 105 (DW_TAG_formal_parameter)
    <1d1b9> DW_AT_name : thread_ptr
    <1d1c4> DW_AT_type : DW_FORM_ref_addr <0x0>
    <1d1c9> DW_AT_location : 0x7706 (location list)

It corresponds to the formal argument of function _tx_thread_system_suspend in file tx_thread_system_suspend.c which is built by armcc compiler. In order to reuse the existing type information, the DW_AT_type field can accept two kinds of things which then require two different solutions:

1) An offset in current compiler unit. The compiler used to compile current file is responsible for filling this hole with meaningful offset.

2) A relocatable offset for referring type defined in different compiler unit. The linker is responsible for fixing it with meaningful address.

So please help me to confirm below things:

1) What's the type of formal argument thread_ptr? Is this type defined in the same file where function _tx_thread_system_suspend lives? If they are in same file, then the armcc should fill the hole with meaningful offset.

2) Can you please find the type name of argument thread_ptr? Which linker are you using to link them together to form final main.elf file? The linker probably doesn't correctly resolve this hole.

[Darius (darius-dons)]

tx_thread_system_suspend is part of ThreadX in cyu3threadx.a - I don't have the source to that. Cypress licensed it for use with their part and built their library (which I can get the source for) around it.

arm-none-eabi-nm ~/work/fx3/EZ-USB\ FX3\ SDK/1.3/firmware/u3p_firmware/lib/fx3_debug/cyu3threadx.a
<snip>
tx_thread_initialize.o:
00000000 a BuildAttributes$$ARM_ISAv5$E$P$J$S$PE$A:L22$X:L11$S22$IEEE1$IW$USESV6$~STKCKD$USESV7$~SHL$OSPACE$EBA8$REQ8$PRES8$EABIv2
         w Lib$$Request$$armlib
00000000 N __ARM_grp..debug_abbrev.group.2_Am0000_lbphKItke$2_000000
00000000 N __ARM_grp..debug_info$stdlib.h$.2_IP0000_7cR$UmnN8f7_300000
00000000 N __ARM_grp..debug_info$string.h$.2_4v0000_Cy6u1kGYTV9_300000
<snip>
00000000 N __ARM_grp_.debug_macinfo$4
00000000 N __ARM_grp_.debug_pubnames$10
         U _tx_thread_current_ptr
00000000 T _tx_thread_info_get
         U _tx_thread_system_state
         U _tx_trace_buffer_current_ptr
         U _tx_trace_buffer_end_ptr
         U _tx_trace_buffer_start_ptr
         U _tx_trace_control_header_ptr
         U _tx_trace_simulated_time

Unfortunately I don't have a header file which declares tx_thread_system_suspend, however it does define tx_thread_suspend..
UINT tx_thread_suspend(TX_THREAD *thread_ptr);

TX_THREAD is a typedef'd struct.

The linker is /usr/local/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-ld used like..
/usr/local/gcc-arm-none-eabi-4_7-2013q3/bin/arm-none-eabi-ld --no-wchar-size-warning --gc-sections -d -T /Users/darius/work/micro/ussio/ussio-dbg-bug/../../lib/cyfx3sdk/1.3/firmware/common/fx3_512k.ld crc.o main.o dscr.o cyfxtx.o cyfx_gcc_startup.o -Map=main.map --cref -o main.elf --entry CyU3PFirmwareEntry /Users/darius/work/micro/ussio/ussio-dbg-bug/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///lib/fx3_debug/cy_as0260.a /Users/darius/work/micro/ussio/ussio-dbg-bug/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///lib/fx3_debug/cyu3mipicsi.a /Users/darius/work/micro/ussio/ussio-dbg-bug/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///lib/fx3_debug/cyu3lpp.a /Users/darius/work/micro/ussio/ussio-dbg-bug/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///lib/fx3_debug/cyfxapi.a /Users/darius/work/micro/ussio/ussio-dbg-bug/../../lib/cyfx3sdk/1.3/firmware/u3p_firmware///lib/fx3_debug/cyu3threadx.a /usr/local/gcc-arm-none-eabi-4_7-2013q3/arm-none-eabi/lib/libc.a /usr/local/gcc-arm-none-eabi-4_7-2013q3/lib/gcc/arm-none-eabi/4.7.4/libgcc.a
/Users/darius/work/fx3/elf2img/elf2img -i main.elf -o main.img

[Terry Guo (terry.guo)]

From the dwarf output, I can see the library is built with armcc 4.0.591. Then I did a small experiment with same tool chains, the armcc and gnu linker. Unfortunately everything works fine for me, the DW_FORM_ref_addr can be resolved to a correct value. When test final image inside gdb, it works well too. I tried all the tool chain you mentioned, all of them works fine.

Thus I believe the tool chain already can handle DW_FORM_ref_addr for normal cases. Looks to me that your issue isn't a common case. I am sorry that without further help from you, I think I couldn't provide more help. What I need is a way to reproduce this issue.

Here is bad DIE from your case:

 <2><1d1b8>: Abbrev Number: 105 (DW_TAG_formal_parameter)
    <1d1b9> DW_AT_name : thread_ptr
    <1d1c4> DW_AT_type : DW_FORM_ref_addr <0x0>
    <1d1c9> DW_AT_location : 0x7706 (location list)

Here is screen paste of my little experiment, you can see that DW_FORM_ref_addr is properly resolved.

 <2><c9>: Abbrev Number: 105 (DW_TAG_formal_parameter)
    <ca> DW_AT_name : ptr
    <ce> DW_AT_type : DW_FORM_ref_addr <0x150> <<< your case had a bad value here
    <d3> DW_AT_location : 0x16 (location list)
 <2><d7>: Abbrev Number: 94 (DW_TAG_variable)
    <d8> DW_AT_name : __result
    <e1> DW_AT_type : DW_FORM_ref1 <0xa9>
    <e3> DW_AT_location : 1 byte block: 50 (DW_OP_reg0 (r0))
    <e5> DW_AT_start_scope : 8
    <e6> DW_AT_artificial : 1
  Compilation Unit @ offset 0xec:
   Length: 0x7c (32-bit)
   Version: 3
   Abbrev Offset: 0x0
   Pointer Size: 4
 <0><f7>: Abbrev Number: 7 (DW_TAG_compile_unit)
    <f8> DW_AT_name : x.c
    <fc> DW_AT_producer : ARM C/C++ Compiler, RVCT4.0 [Build 591]
    <124> DW_AT_language : 1 (ANSI C)
    <126> DW_AT_comp_dir : /home/terguo01
    <135> DW_AT_stmt_list : 0x68
 <1><139>: Abbrev Number: 4 (DW_TAG_base_type)
    <13a> DW_AT_byte_size : 4
    <13b> DW_AT_encoding : 5 (signed)
    <13c> DW_AT_name : int
 <1><140>: Abbrev Number: 80 (DW_TAG_typedef)
    <141> DW_AT_name : TX_THREAD
    <14b> DW_AT_type : DW_FORM_ref1 <0x153>
    <14d> DW_AT_decl_file : 1
    <14e> DW_AT_decl_line : 6
    <14f> DW_AT_decl_column : 3
 <1><150>: Abbrev Number: 34 (DW_TAG_pointer_type)
    <151> DW_AT_type : DW_FORM_ref1 <0x140>

[Darius (darius-dons)]

OK, I am not really sure where to go from here though :(

I guess I could see if Cypress are willing to update the toolchain they use and see if that works - I don't think much for my chances though :)

[Terry Guo (terry.guo)]

How about you report this issue to Cypress? They should be able to reproduce the issue because they have sources and all required tool chain. It would be a plus to them if their libraries can work with more tool chain.

[Joey Ye (jinyun-ye)]

No response after long time. Not proved to be a toolchain bug. Mark it invalid