• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 676 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.

Linker Error - application error: die_ref (00737fa4) does not match section position (00737fa5)

Dan Montz
Prodigy 50 points

I am getting the following linker error and have not been able to find any information on it:

<Linking>
>> application error: die_ref (00737fa4) does not match section position
(00737fa5)

00737fa4 DW_TAG_subprogram
DW_AT_name .T$0000
DW_AT_low_pc 0x8f3900
DW_AT_high_pc 0x8f3920
DW_AT_TI_symbol_name .T$0000
DW_AT_trampoline true
>> fatal error: cannot continue; aborting

I started getting this linker error while trying to build an "all-debug" build (no optimizations and all symbols included).  I am essentially adding the -g and removing "symdebug:none" from the compiler options.  I am also turning off all optimizations.

We have our code spread across 15 different libraries.  I have been working to turn on debug symbols for each library independently.  Once I got to the 13th library (it didn't matter which one it was), I started seeing this linker error.  The only difference between the compilations is the -g option.  I have done a clean of the environment and a recompile/relink and still have the same issue.

Here's my environment:
Code Composer Studio v3.3.42.1
Integrated Development: 5.98.0.230
BIOS: 5.31.02
Code Gen Tools v6.0.8 (I have also tried v 6.0.25 and have the same problem)
DSP = C6455

  • 0
    TI__Guru* 84285 points

    There's not much I can say about it without a test case other than the obvious: it can only occur with some level of -g, and it appears to be an assembler or linker bug.  The way the linker handles "die_ref" information was completely redone in version 6.1.0, so I can't tell if the problem has been fixed.  I recommend trying the linker from the latest version of 6.1.x (the very latest is currently 6.1.14) to see if the bug is still there.  Either way, to get the bug fixed in 6.0.x a test case will probably be necessary.

  • 0 in reply to Archaeologist
    Prodigy 50 points

    Thanks for the information.  I'll try the latest 6.1 code gen tools and post my status here.

  • 0
    TI__Guru**** 253270 points

    I suggest another workaround here.  I want to stress that this is a workaround only for this specific situation, and I do not recommend this technique for general use.

    The problem appears to be in the Dwarf debug information for trampolines.  So, a possible workaround is to compile with the hidden switch  --mem_model:code=far .  This causes the compiler to issue a "far" call sequence for every function call.  This will cost you in both code size and cycles.  However, no trampolines will be generated. Thus, this problem may be avoided.  Hopefully, this will be a practical short term solution while you help us figure out the real problem.

    BTW, background information on trampolines and far calls may be found in http://www.ti.com/lit/pdf/spraa46 .

    Thanks and regards,

    -George

     

  • 0 in reply to George Mock
    Prodigy 50 points

    I have upgraded to the v6.1.15 compiler and rebuilt all of the code.  Now the linker successfully links!  Problem solved.  Now comes the hard part of upgrading and qualifying our products to the new 6.1.x compiler.  Thanks for all your help!