• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 2864 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DWARF files from TI compiler not compatible with GDB

FiSz
Prodigy 170 points


Hi,

I would like to use the official TI compiler/linker for MSP430 µC-series to generate a DWARF-compatible debug information, so that I can debug using tools like GDB. Currently (TI Compiler 4.4.3) this is not the case since GDB (latest version 7.7.1) crashes immediately after trying to read the files (other users posted the same issue as well). What are the differences to the standard DWARF-format and do you know a way to use GDB with programs compiled&linked with the TI compiler?

Kind regards,

Filip

  • 0
    TI__Guru**** 251200 points

    The TI compiler does not claim to work with gdb.  For instance, we don't test with gdb.  But we do emit Dwarf debug information.  MSP430 compiler version 4.4.x conforms to Dwarf version 3.  Is it possible the gdb you use expects a different version of Dwarf?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 170 points

    Hi George,


    as you say the TI compiler conforms to Dwarf v.3 and this is supposed to be standardized (see dwarfstd.org). GDB truly conforms to the standard and the version I use supports Dwarf v.3 and v.4. Moreover, GDB is used as a debugger with a variety of different compilers, not only GCC, as long as they can generate standard-conformant Dwarf output. I have found several posts in the Internet saying that the TI compiler uses symbols which are TI-specific and do not conform to the official Dwarf standard. This is why I want to clarify this issue here. I would be great to have a standardized output from the TI compiler and be able to use it with GDB for example for remote debugging.

    Thanks and regards!

    Filip

  • 0 in reply to FiSz
    Expert 1830 points

    FiSz said:

    GDB truly conforms to the standard

    How do you know that?

    FiSz said:

    and the version I use supports Dwarf v.3 and v.4.

    GDB 7.7 suffered from a problem that was fixed not too long ago: https://sourceware.org/bugzilla/show_bug.cgi?id=16822:1230:0

    Btw: GDB 7.7.1 is nowhere near the "latest version". It's from May 2014. The latest version seems to be 7.10. I suspect that using a more recent GDB would solve your problems.

    FiSz said:

    I have found several posts in the Internet saying that the TI compiler uses symbols which are TI-specific and do not conform to the official Dwarf standard.

    The dwarf standard explicitly permits the use of vendor-specific attributes.

    Markus

  • 0 in reply to Markus Moll
    Prodigy 170 points

    Thanks for your post Markus.

    > How do you know that?

    Sure, without looking into compiler sources, you can never know (for GDB you can actually do it) but obviously GDB is widely used and even built into commercial debug probes (GDB server).

    > GDB 7.7 suffered from a problem that was fixed not too long ago: https://sourceware.org/bugzilla/show_bug.cgi?id=16822:1230:0

    > Btw: GDB 7.7.1 is nowhere near the "latest version". It's from May 2014. The latest version seems to be 7.10. I suspect that using a more recent GDB would solve your problems.

    I can't open the link. But I use the latest version *for the MSP430-series* which this is about.

    > The dwarf standard explicitly permits the use of vendor-specific attributes.

    This is true. But they still have to conform to the standard syntax and would be ignored by GDB if they could not be recognized instead of crashing the debugger. As a matter of fact, the debugger should be more immune to crashes but I don't want to advocate for GDB superiority in any way but would just like to know how far TI compiler/linker conforms to the official Dwarf v.3 standard and if there is a reliable way to use its elf/dwarf output with GDB.

    Regards,

    Filip

  • 0 in reply to Markus Moll
    TI__Guru* 84285 points
    Markus is correct, this was a bug in GDB. There is a MIPS non-standard vendor-specific DWARF tag (DW_AT_MIPS_linkage_name, id 0x2007). Other non-MIPS toolchains found this to be a handy extension, so several toolchains also added a vendor-specific extension with that id (0x2007) meaning the same thing ; however, for each toolchain, it is still technically a vendor-specific DWARF extension. The TI DWARF tag values were chosen without knowledge of this non-standard extension, and chose 0x2007 for an unrelated DWARF tag, which is perfectly forming to the DWARF standard. GDB made the mistake of assuming 0x2007 was a truly universal tag, which is a non-DWARF-conforming assumption, and crashes when it sees TI's vendor extension. Yes, it would have been nice if TI had avoided the bug in GDB by avoiding that particular tag value, but that ship has sailed.
  • 0 in reply to FiSz
    TI__Guru* 84285 points

    FiSz said:
    [I] would just like to know how far TI compiler/linker conforms to the official Dwarf v.3 standard and if there is a reliable way to use its elf/dwarf output with GDB.

    Try using the hidden option --disable:dwarf_extensions to avoid generating TI-specific DWARF extension tags.

    As to conformance to the DWARF standard, that's a bit harder to answer.  Many things in the DWARF standard are open to interpretation, so I don't think there is an official schema against which we can validate.  Our intent is to conform to the appropriate version of the DWARF standard, so if you find any other problem areas, we definitely want to know about it.

  • 0 in reply to Archaeologist
    Prodigy 170 points
    Hi Archaeologist,
    thank you for these insights. The hidden option seems to work (I tried it so far with a basic test program and gdb in simulator mode). I will test this extensively soon. Yes, I understand the problem with "standards". Here is an interesting article illustrating the current and past situation with Dwarf standardization:
    www.cs.dartmouth.edu/.../Debugging using DWARF.pdf
    Filip
  • 0 in reply to Archaeologist
    Intellectual 800 points
    Hi Archaeologist,

    thanks a lot. That really seems to work out...
    What speak's against making this a documented compiler option?

    Regards,
    Michael
  • 0 in reply to Michael Sch,
    TI__Guru* 84285 points
    We're pursuing this as a bug in gdb/binutils, so in the long term users will not need that option. Using the option removes useful information from the debugging information that some features in CCS rely upon.