DWARF 3 vs. DWARF 4 For 3rd Party Tools

The article Dwarf 4 in TI Compilers is very on point to this situation.

Thanks and regards,

-George

Thanks for the reply and link. I've read it twice now but can't see how this might explain the issue I'm seeing.

It seems that in the DWARF4 output, structure symbols in header files are not emitted. Is this intentional? This can be seen in the attached demo binaries.

driverlib_lp_f28003x_foo.zip

Structure members member1 and member2 shown above in the v3 file do not appear in the v4 .out file.

I asked the DWEX author to comment on the files. He said:

"In the readelf output for the DWARFv4 binary, there is no compilation unit for lab_main.h. There are 198 CUs in the v3 file and 197 CUs in the v4 one.

I think we can safely conclude that dwex is not to blame here"

The evidence so far suggests that the DWARF4 output from CCS is unusable by other tools which kind of defeats the point of a standard for debug info.

Please can you check with the developers and explain why lab_main.h compilation unit should be missing from the DWARF4 file in this case?

Thank you.

Use the utility ofd2000 to inspect the .out files.  It is documented in the C28x assembly tools manual.  I used these commands ...

% ofd2000 -g "driverlib_lp_f28003x_foo(DWARF3).out" > d3.txt
% ofd2000 -g "driverlib_lp_f28003x_foo(DWARF4).out" > d4.txt

In Dwarf3, the information about the structure that contains member1 and member2, as well as the typedef foo_st, are all contained in a single DW_TAG_compile_unit.

    00001c90   2 DW_TAG_compile_unit
    00001c91        DW_AT_name       ..\lab_main.h
    00001c95        DW_AT_stmt_list  .debug_line(21) + 0x465
    00001c99        DW_AT_language   DW_LANG_C
    00001c9a        DW_AT_comp_dir   W:\Examples\driverlib_lp_f2800
                                     3x\CPU1_FLASH
    00001c9e        DW_AT_producer   TI TMS320C2000 G3 C/C++ Codege
                                     n PC v22.6.0.LTS Copyright (c)
                                      1996-2018 Texas Instruments I
                                     ncorporated
    00001ca2        DW_AT_TI_version 1
    00001ca3   3    DW_TAG_structure_type
    00001ca4           DW_AT_sibling     .debug_info(20) + 0x1cd5
    00001ca8           DW_AT_byte_size   2
    00001ca9           DW_AT_decl_column 16
    00001caa           DW_AT_decl_file   1
    00001cab           DW_AT_decl_line   12
    00001cac   1       DW_TAG_member
    00001cad              DW_AT_name                 member1
    00001cb1              DW_AT_accessibility        1
    00001cb2              DW_AT_data_member_location DW_OP_plus_uconst 0
    00001cb5              DW_AT_decl_column          14
    00001cb6              DW_AT_decl_file            1
    00001cb7              DW_AT_decl_line            13
    00001cb8              DW_AT_type                 .debug_info(20) + 0x2286
    00001cbc              DW_AT_TI_symbol_name       member1
    00001cc0   1       DW_TAG_member
    00001cc1              DW_AT_name                 member2
    00001cc5              DW_AT_accessibility        1
    00001cc6              DW_AT_data_member_location DW_OP_plus_uconst 1
    00001cc9              DW_AT_decl_column          14
    00001cca              DW_AT_decl_file            1
    00001ccb              DW_AT_decl_line            14
    00001ccc              DW_AT_type                 .debug_info(20) + 0x2286
    00001cd0              DW_AT_TI_symbol_name       member2
    00001cd5   4    DW_TAG_typedef
    00001cd6           DW_AT_name        foo_st
    00001cda           DW_AT_language    DW_LANG_C
    00001cdb           DW_AT_decl_column 3
    00001cdc           DW_AT_decl_file   1
    00001cdd           DW_AT_decl_line   15
    00001cde           DW_AT_type        .debug_info(20) + 0x1ca3

In Dwarf4, this same information is split into two different DW_TAG_type_unit entries.  

    000000ab  48 DW_TAG_type_unit
    000000ac        DW_AT_stmt_list .debug_line(22) + 0x2498
    000000b0        DW_AT_producer  TI TMS320C2000 Linker PC v22.6
                                    .0 Copyright (c) 1996-2018 Tex
                                    as Instruments Incorporated
    000000b4  15    DW_TAG_structure_type
    000000b5           DW_AT_sibling     (null)
    000000b9           DW_AT_byte_size   2
    000000ba           DW_AT_decl_column 16
    000000bb           DW_AT_decl_file   7
    000000bc           DW_AT_decl_line   12
    000000bd   8       DW_TAG_member
    000000be              DW_AT_name          member1
    000000c6              DW_AT_accessibility 1
    000000c7              DW_AT_decl_column   14
    000000c8              DW_AT_decl_file     7
    000000c9              DW_AT_decl_line     13
    000000ca              DW_AT_type          0x8d8a42f3ebac3771
    000000d2   7       DW_TAG_member
    000000d3              DW_AT_name                 member2
    000000db              DW_AT_accessibility        1
    000000dc              DW_AT_data_member_location DW_OP_plus_uconst 1
    000000df              DW_AT_decl_column          14
    000000e0              DW_AT_decl_file            7
    000000e1              DW_AT_decl_line            14
    000000e2              DW_AT_type                 0x8d8a42f3ebac3771

<skip some lines>

    00000103  48 DW_TAG_type_unit
    00000104        DW_AT_stmt_list .debug_line(22) + 0x2498
    00000108        DW_AT_producer  TI TMS320C2000 Linker PC v22.6
                                    .0 Copyright (c) 1996-2018 Tex
                                    as Instruments Incorporated
    0000010c  19    DW_TAG_typedef
    0000010d           DW_AT_name        foo_st
    00000114           DW_AT_decl_column 3
    00000115           DW_AT_decl_file   7
    00000116           DW_AT_decl_line   15
    00000117           DW_AT_type        0x4f83ce88e05797f8

Perhaps these other Dwarf utilities don't handle DW_TAG_type_unit entries.

Kier said:

explain why lab_main.h compilation unit should be missing from the DWARF4 file

I agree the string lab_main.h should appear in the Dwarf4 information somewhere.  I don't know why it isn't there.  I am unable to reproduce this behavior in a small scale way.  Is your build organized as a CCS project?  If so, please zip it up as described in the article Sharing projects, and attach the zip to your next post.

Thanks and regards,

-George

Thanks for the analysis George. I'll make a note of that utility.

Please find attached the whole CCS project from which I produced the sample .out files.

driverlib_lp_f28003x.zip

This is starting to make sense now. Monitoring the myFoo structure in CCS debugger does not appear to rely on the existence of an enclosing compile unit. Other tools (e.g. DWEX) rely on displaying the symbols in the context of CUs. No CU, no symbol.

I think if we can get the lab_main.h compile unit to appear in the .out file then the issues with all the tools may be resolved hopefully.

Thank you for submitting the project.

Kier said:

I think if we can get the lab_main.h compile unit to appear in the .out file

It doesn't work like that.  Recall that lab_main.h does not appear in the Dwarf information.  Even so, CCS knows about that file and reads from it as needed.  While in CCS, hover the mouse over foo_st in lab_main.c and see ...

I added those two comments on those lines to prove that this is not somehow being mechanically reproduced.  CCS must copy the lines from lab_main.h to create this display.  

This is not a one-time unusual thing.  A few lines before this, the type name uint64_t appears.  Hover the mouse over it and see ...

That line is copied from C:/ti/ccs1200/ccs/tools/compiler/ti-cgt-c2000_22.6.0.LTS/include/sys/_stdint.h.  But the string _stdint is not present anywhere in the Dwarf information.  

How does all this work behind the scenes?  I don't know.  CCS is based on the Eclipse open source project.  I am concerned that the code which maps the Dwarf information to these lines of source is deep in that open source.  Which means it could be difficult to work out the details.

Thanks and regards,

-George

George Mock said:

How does all this work behind the scenes?

My understanding is the "pop-up" which displays such information when you hover-over symbols in the the CCS editor comes from the Eclipse indexer which parses the source code, rather than extracting any DWARF debugging information.

I apologize for some mistakes I've made in this thread.

One is that I mistakenly thought the Dwarf debug information is used to to create the displays CCS shows when you hover over a type name.  Instead, the indexer is used.  If you disable the indexer, that feature stops working.  

I also suspect this is incorrect ...

George Mock said:

I agree the string lab_main.h should appear in the Dwarf4 information somewhere.

Internal discussion is still ongoing, so I am uncertain.  I'll get back to you on that.

Kier said:

The evidence so far suggests that the DWARF4 output from CCS is unusable by other tools which kind of defeats the point of a standard for debug info.

The Dwarf standards do not require that any particular Dwarf tag or attribute be used.  But when they are used, the meanings associated with them are as defined in the standards.  Thus, it is allowed to specify type information inside a DW_TAG_compile_unit, or a DW_TAG_type_unit.  Unfortunately, it is not practical for our development and testing of the compiler, including the Dwarf information, to take into account the effect on third party tools of which we are not aware.

Thanks and regards,

-George 

Thanks for raising the enhancement..