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

Compiler/CCSTUDIO-C2000: "failed to locate DWARF abbreviation code 73 in the abbreviation table"

Filofel
Prodigy 100 points
Part Number: CCSTUDIO-C2000
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI C/C++ Compiler

Hi All,

Compiling a legacy project with C2000 Code Generation tools 6.2.11, I get a set of link-time warnings I have never seen before:

warning #99922: C:\Users\pauphell\AppData\Local\Temp\056762: failed to locate
   DWARF abbreviation code 73 in the abbreviation table at offset 0x0000a7eb;
   skipping remainder of compile unit at offset 0x005e6deb
warning #99922: C:\Users\pauphell\AppData\Local\Temp\056762: failed to locate
   DWARF abbreviation code 73 in the abbreviation table at offset 0x0000a910;
   skipping remainder of compile unit at offset 0x005e7520
warning #99922: C:\Users\pauphell\AppData\Local\Temp\056762: failed to locate
   DWARF abbreviation code 73 in the abbreviation table at offset 0x0000ab58;
   skipping remainder of compile unit at offset 0x005e83b4
warning #99922: C:\Users\pauphell\AppData\Local\Temp\056762: failed to locate
   DWARF abbreviation code 73 in the abbreviation table at offset 0x0000add7;
   skipping remainder of compile unit at offset 0x005e9f83
warning #99922: C:\Users\pauphell\AppData\Local\Temp\056762: failed to locate
   DWARF abbreviation code 73 in the abbreviation table at offset 0x0000af4c;
remark #10205-D: automatic RTS selection:  linking in "rts2800_fpu32.lib" in
   skipping remainder of compile unit at offset 0x005eab40
   place of index library "libc.a"
(...)
warning #99922: C:\Users\pauphell\AppData\Local\Temp\056762: failed to locate
   DWARF abbreviation code 73 in the abbreviation table at offset 0x0000b21a;
   skipping remainder of compile unit at offset 0x005ec948
warning #99922: C:\Users\pauphell\AppData\Local\Temp\056762: failed to locate
   DWARF abbreviation code 73 in the abbreviation table at offset 0x0000b3d4;
   skipping remainder of compile unit at offset 0x005ed572
warning #99922: C:\Users\pauphell\AppData\Local\Temp\056762: failed to locate
   DWARF abbreviation code 73 in the abbreviation table at offset 0x0000b60c;
   skipping remainder of compile unit at offset 0x005ee05c
warning #99922: C:\Users\pauphell\AppData\Local\Temp\056762: failed to locate
   DWARF abbreviation code 73 in the abbreviation table at offset 0x0000b962;
   skipping remainder of compile unit at offset 0x005f38f2
warning #99922: C:\Users\pauphell\AppData\Local\Temp\056762: failed to locate
   DWARF abbreviation code 73 in the abbreviation table at offset 0x0000ba9a;
   skipping remainder of compile unit at offset 0x005f3e35

  • I have no idea what triggered that.
  • Googling this around gave me no clue so far.
  • The error message refers to a linker temp/work file that does exist, but does not indicated which module(s) in there is/are involved.
  • I have reviewed the compilation and link options for the projects involved and found nothing suspicious so far.
  • I have tweaked some parameters, cleaned all projects a few times and rebuilt everything to no avail - the problem sticks!
  • I have checked from the verbose global-build.log that everything was compiled using 6.2.11 (including the old XDC and custom ti.sysbios library file involved).
  • And since Strict Compatibility Checking is on, I would assume that the linker would have diagnosed a codegen tools inconsistency anyway if there was one.
  • Just in case, I have also checked in the .map file that the linker invoked was a 6.2.11 too.

I'm starting to get out of new, creative ideas to figure out this one...

Would any of you All have a clue of why those darn "DWARF abbreviation code 73" can't be found, and how to get rid of the problem?


TIA!

PhA.

  • 0
    TI__Guru**** 251230 points

    Please package up your project as described in the article Project Sharing, then attach that to your next post.  I plan to use that to reproduce the problem.  Then I'll file a defect report.  A linker expert will use that to figure out the problem.

    Thanks and regards,

    -George

  • 0
    TI__Guru* 84285 points
    That message is telling you that the DWARF debugging information is corrupted in some way. I haven't seen this specific message before. I would guess that this is the temporary file created for the executable object file before it is moved to its final location. I recommend upgrading to the most recent version of the compiler. If you still get the warning, we can start diagnosing it. Now these are just DWARF warnings, so it's likely your program will work just fine, it's just that the DWARF debug will be corrupted.
  • 0 in reply to George Mock
    Prodigy 100 points
    George,
    Thanks for your prompt answer. With the time offset, it arrived after I had left work for the week-end. In the interim, some subconscious background week-end thinking got me some fresh ideas, and I found this morning the cause of my problem. Trying to make the story brief:
    Using an hex dump on the temp file that the diagnostic message referenced, I figured out it looked very suspiciously like an .out file.
    Then using odf2000 with some full listing options on the temp file, I got a nice 166 MiB. Browsing there, I finally found the culprit: A small library that was still erroneously calling the 16.9.3.LTS codegen tools instead of the 6.2.11 ones.. Furthermore, the debug options in that lib were set to DWARF 4 - that didn't (at least officially) exist in 6.2.11. And that certainly didn't help the 6.2.11 linker! :)
    The only thing that I don't quite get is that the --strict_compatibility option was set in the link and I saw no error mentioning those debug modules compiled with the wrong codegen tools.

    What happened was that I had changed the compiler version option on the wrong build configuration for that specific lib - that is, not the one that the master build uses when it triggers a library rebuild. But then, how come I didn't spot the 16.9.3 compiler version in the global-build.log file? Well, because *that* specific build config didn't have the verbose console option set either, so it didn't display anything at all about its version... <sigh>. But fortunately, that info did exist in the temp file records.

    Sorry for unneeded alert, and thanks again for the quick offer for help. I do appreciate that! /Ph.
  • 0 in reply to Archaeologist
    Prodigy 100 points
    Archeologist,

    > I recommend upgrading to the most recent version of the compiler.

    That's precisely what we are working on, and that how we got into that mess to start with! :)
    The only problem is that it's not piece of cake:
    The project consists in several hundred code files, mostly C but a good number of asm files too, and it fills most of the target (both RAM and Flash).
    Just moving to 16.9.3 generates significantly bigger code, and the project doesn't link / fit anymore into the target.
    Optimizing for size (to the max) and reshuffling the memory maps in the link file gets us back in, but then, some critical part of the application appears to be broken.
    It's while downgrading the new project config to the old codegen tools (to check the effect on the app) that we fell into the trap that was the object of this thread...
    Anyway, for that latter matter at least, we're back on track.

    Thanks for your help! /Ph.