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.

C6678: incomplete DWARF section when compiling/linking using version 7.4.0 tools



Hello,

I have the following problem when using the C/C++ Compiler & Linker version 7.4.0.

I am compiling using the following 2 options: --symdebug:dwarf and --symdebug:dwarf_version=3. The object files generated by the C/C++ Compiler using the options above contains complete DWARF .debug_pubnames sections. However, the executable generated by the Linker contains an incomplete .debug_pubnames DWARF section: some global symbols are missing.

When using C/C++ Compiler & Linker version 7.3.4, all is well. The executable generated by the Linker contains a complete .debug_pubnames DWARF section: all global symbols are there.

Is there a way to solve this problem?

Thanks,

Sergiu

  • Hi Sergiu,

    I moved your thread to Compiler Forum to get appropriate response.

    Thanks.

  • I presume this problem means you can see differences in the output of this command ...

    % ofd6x -g executable_file.out

    Please see if you can find a single object file which displays a difference.  If so, please preprocess the corresponding source file as described here, the post it, along with the exact build options.  That should allow us to reproduce the problem.

    Thanks and regards,

    -George

  • Thank you for sending a detailed test case through private channels.  I can reproduce the problem.  I filed SDSCM00049229 in the SDOWP system to have this looked at.  Feel free to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • Hi,

    I took a look at the files you submitted. There are two directories:

    d734 and d740. What is the differences between these two directories? Are they the same?

    The reason I asked this questions is based on the following observation:

    I use C6000 7.3.4 tools under both directories:

    under d734/

    %cl6x -@top_level.txt

    %ofd6x -g --obj_display=none,header --dwarf_display=none,dpubnames MpcMp66.out > 7_3_4.txt

    %grep g_apRTPInput 7_3_4.txt
    g_apRTPInput 000000e8

    under d740/

    %cl6x -@top_level.txt

    %ofd6x -g --obj_display=none,header --dwarf_display=none,dpubnames MpcMp66.out > 7_4_0.txt

    %grep g_apRTPInput 7_4_0.txt

    This makes me believe that even for the same tool, 7.3.4, we will get different results under the two directories. It seems that the two directories input files are not the same. 

    Is this what you are complaining? Can you tell me which object files under these two directories are causing this problem?

    Thanks,

    Wei

  • Hi Wei,

    I sent George the information to reproduce the incident. He organized the information attached to ticket SDSCM00049229. I can only guess that:

    1. d734 contains (i) the object files compiled with TI compiler version 7.3.4, (ii) the makefile, (iii) the libraries to perform linking and (iv) the executable MpcMp66.out produced by TI Linker version 7.3.4.
    2. d740 contains (i) the object files compiled with TI compiler version 7.4.0, (ii) the makefile, (iii) the libraries to perform linking and (iv) the executable MpcMp66.out produced by TI Linker version 7.4.0.

    A few more details:

    1. The origin of the 2 folders above is the same, very large set of source files.
    2. The problem is this: the executable produced by TI Linker version 7.4.0 does not have all symbols in DWARF section .debug_pubnames: as you've already seen, symbol g_apRTPInput is one of the missing symbols.
    3. The executable produced by TI Linker version 7.3.4  is just fine: it has all symbols in DWARF section .debug_pubnames
    4. As an example, symbol g_apRTPInput is defined in file MpcMpMin.cpp. Utility ofd6x shows that symbol g_apRTPInput is present in the DWARF section .debug_pubnames of the MpcMpMin.obj file regardless of the TI Compiler version used to compile this source file. 

    I hope this helps.

    Cheers,

    Sergiu

  • Sergiu,

    Thanks for the info. I have all the files you sent to George. It is logged into our bug tracking system.

    I found it is not the linker problem. The problem is with the MpcMpMin.obj file. When I swapped the 7.4.0's MpcMpMin.obj back to the d734 directory, the problem happens, and vice versa.

    Since 7.3.0, we did not change anything about pubnames and pubtypes in our tools. I wonder if MpcMpMin.obj is built with the same compiler options. Can you double check that? Also if possible, can you send me the compiler options you used to build under 7.4.0.

    Thanks,

    Wei

     

  • Sergiu,

    Another request, can you also send me the MpcMpMin.asm file under 7.3.4 and 7.4.0, respectively?

    It seems that the output from the compiler for some globals is wrong. You need to use -k option.

    Also use --v option you can get all the subcommands to compile this. If possible, send them to me.

    Thanks,

    Wei 

  • Wei,

    I compiled file MpcMpMin.cpp with options –k and --verbose in both environments (7.3.4 and 7.4.0). For each environment I created an archive of results. Both zipped archives are attached.

    Each archive contains the following files:

    1. compile_trace.txt: trace of compile execution which shows all compiler options
    2. compiler.opt: file of compiler options generated by the XDC tool. Introduced with option --cmd_file.
    3. MpcMpMin.asm: generated assembly language file

    Cheers,

    Sergiu

    6204.MpcMpMin_7.3.4.tar.gz

    2555.MpcMpMin_7.4.0.tar.gz

     

  • Hi Wei,

    The project I am working on is getting to a stage where we must use version 7.4.0 of the TI Compiler/Linker.

    While waiting for a fix for this issue (SDSCM00049229), is there a workaround?

    Do you have an estimate for the SDSCM00049229 fix? 

    Thanks in advance,

    Sergiu

  • Sergiu,

    Sorry there is no work around for this problem. This problem basically is some global variables or functions can not be looked up in the debugger. I can not see any work around to make it visible. Our tools does not have any options that can change the output of the debug info section which directly relates to this problem.

    It is on our list. Our next 7.4.7 release which is scheduled earlier February will not have this fix. So my estimate is that it will be in sometime in March.

    Wei

  • Hi Wei,

    Do you know if this problem is present in version 7.3.14?

    If version 7.3.14 does not have this problem, we'll try building our project using version 7.3.14 instead of 7.4.0.

    Thanks,

    Sergiu

  • Sergiu Stambolian said:
    Do you know if this problem is present in version 7.3.14?

    I don't know the low level details which would allow me to be sure.  But I can tell you that, if the bug is not present in 7.3.4, then it is very unlikely to be present in 7.3.14.  As you can see here, the only difference between 7.3.x releases is bug fixes.  If it is relatively easy to try the build with 7.3.14, I'd say go for it.

    Thanks and regards,

    -George

  • George,

    I was reading the Release Notes and Defect History for 7.3.x (x is 1 to 14) and 7.4.0:

    1. Version 7.3.2 has a DWARF fix for bit fields bug.
    2. Version 7.3.14 has a known DWARF bug (SDSCM00044670) which seems to be different than the bug we are talking about.

    I'll try version 7.3.14.

    Thanks,

    Sergiu

  • George,

    Yesterday, I tried version 7.3.14: it produces the same result (missing symbols in DWARF pubnames) as version 7.4.0.

    So, the problem is introduced somewhere between versions 7.3.5 and 7.3.14.

    Cheers,

    Sergiu

  • Sergiu,

    So we will have a conference call on Monday. We will discuss how to get this one fixed.

    Wei

  • The fix for ticket SDSCM00049229 solves this problem: all symbols are present in DWARF section debug_pubnames.

    The fix is available in C6000 Code Generation Tools v7.4.7

    Regards,

    Sergiu