• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 483 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/66AK2G12: Linker Behavior Changes from 8.1 to 8.2?

Chuck Peplinski
Genius 5770 points
Part Number: 66AK2G12

Tool/software: TI C/C++ Compiler

I have a fairly large application based on the PA audio example.  It runs on K2G with both the ARM and DSP running TI-RTOS.  I recently received an update to a third party library which causes my DSP application link to fail.  I'm looking for help to understand how to avoid this.

The failure:
Just adding the new library to the link line results in several "error #10099-D: program will not fit into available memory" errors.  I have a fairly complicated memory layout in config.bld.  The failure message is telling me the linker can't place the regions that are shared with the ARM.  I have looked in vain for what could cause this.  The new library does not (as far as I can tell) define anything that would go in this section.  I've asked the vendor to provide a library built with v8.1, but that can't be the only issue.

Note that my config.bld has three sections.  The first section describes the shared regions.  Then there are descriptions for the ARM and the DSP, each of which refer to the shared regions.  This all works when this library is excluded.

Versions:
I've been using version 8.1 of the compiler.  This new library is noted to be built with v8.2.  I suspect there is some compatibility issue there.  I've tried building my application with v8.2 and it does not solve the critical problem.  The link still fails.  Further I get dozens of warning #10278-D.  The readme with the 8.2 compiler refers to it as a "new compiler" suggesting some changes, but I don't yet find anything specifically causing this.

Other Differences I've noticed:
When I use nm6x to dump the library contents I notice a difference that might suggest something to an expert:
The working (older) library has a lot of these sort of lines:
      0x00000000 a {C816A2B1-EAF8-4575-8BD6-1079DA21DDEF}
while the new one has these instead:
      0x00000000 a TI2oI3mLqrt
That suggests that something about the build is different, but other than all of the debug stuff I find no smoking gun. 

While the Linux utility "readelf" will dump the info about the v2.2.2 version, the same tool reports 

readelf: Error: mst.lib: did not find a valid archive header

Meanwhile, the Linux utility objdump handles both files.  Each is reported as "file format elf32-little".
All of the other libraries in my system cannot be read by "readelf".

The file "ti-cgt-c6000_8.2.2/Closed_defects.html" notes "CODEGEN-3597    ELF header field e_phoff should be 0 when no program header is present".  But this doesn't explain my actual link error.

  • 0
    TI__Guru**** 249860 points

    Because of ...

    Chuck Peplinski said:
    Just adding the new library to the link line results in several "error #10099-D: program will not fit into available memory" errors.

    ... it seems likely the updated library uses more memory than before.  Please use the utility sectti from the cg_xml package to estimate the amount of memory used by the library.  I say "estimate" because this method measures the amount of memory used by all functions in the library.  It is more accurate to measure only the functions actually called by the main application.  But this measurement is easier, and is often close enough for a comparison like this.  Measure the memory used by the old and new variants of the library.  If it goes up, then this is the likely cause of your problem.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 5770 points
    Thanks for your response. That sectti tool is interesting, but the problem isn't that simple. In fact the new library has less code and less uninitialized data. It has slightly more initialized data. But there is plenty of room for this in the map. The sections on which the linker is failing are the shared memory sections. The library places no code in these.
  • 0 in reply to Chuck Peplinski
    Genius 5770 points
    Some more information: The library provider recompiled using an earlier (matching) tool chain version and the problem is gone. Specifically, he says:
    * I see a readelf difference between 8.1.8 and 8.1.3, even with exactly the same compiler settings.
    * I've also build this release on windows, where we normally use linux.
    * I've added the --gcc option, which considered as deprecated and should now be the relaxed_ansi option
    * I've added --abi=eabi which is also default and deprecated as of 8.1

    This confirms there is some obscure incompatibility between 8.1.3 and 8.2, but we can't say exactly what.
  • 0
    TI__Guru**** 249860 points

    I apologize.  There is a key detail I overlooked in your first post ...

    Chuck Peplinski said:
    I've been using version 8.1 of the compiler.  This new library is noted to be built with v8.2. 

    The version of the linker must be same version, or more recent, than the versions of the compiler used to build all of the object files and libraries combined in the link.  You linker is version 8.1.x, but this library uses version 8.2.x.  This is not supported.  It possible (and likely, in this case) the 8.2.x library contains something the 8.1.x linker does not recognize.  

    There are two solutions.  Upgrade the linker to version 8.2.x or higher. Or, downgrade the compiler used to build the library to version 8.1.x.  You have tried the second solution, and it seems to be working.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 5770 points
    Thank you. Did I miss where this is stated in the documentation?