• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 53 subscribers
  • Views 1161 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.

Upgrading from CGT 6.0.8 to 7.0.3 stalls linker

Gilad Barzilay
Prodigy 120 points

Hi there, first time poster.

I'm working on the TCI6486, and got a working and running project compiled and linked with CGT 6.0.8.

I need to upgrade to at least 6.1.12 in order to use the latest EDMA driver (version 01.11.01.04 - the first to support 6486), and I tried with 6.1.12, 6.1.14, 7.0.1 and 7.03 and all come up with the same issue:

I get alot of new warnings I never got before, and the linker seems to be stuck.
After a long while (~12 hours) the linker finishes the job but I get a warning that the out file is unusable (and it really is...). the warning reads:

warning: output file ... cannot be loaded and run on a target system.

The new warnings are kind of strange too. here is an example of the warning prior to getting stuck:

"src/stack/res/timer.c", line 161 (approximate): warning: relocation from
   function "TimerListRemove" to symbol "_ptFirst" overflowed; the 2-bit
   relocated address 0xe is too large to encode in the 15-bit unsigned field
   (type = 'R_C60BASE' (80), file = "..\Obj\stack.lib<timer.o64P>", offset =
   0x000001a4, section = ".text")

And here are some warnings that appear 12 hours later:

warning: C:\DOCUME~1\giladb\LOCALS~1\Temp\041802: DW_CFA_def_cfa_offset_sf is
   DWARF 3 specific; this DWARF information should only contain version 2
   instructions
warning: C:\DOCUME~1\giladb\LOCALS~1\Temp\041802: unrecognized call frame
   instruction 0x1a; cannot read remainder of this section (.debug_frame +
   0x45e6) 

I'm not sure why 0xe is too large to encode in 15 bits really, and most of all, why a project that was working perfectly fine is suddenly dead in the water. Are there any new flags I am missing that I was supposed to set?

Thanks in advance.

  • 0
    TI__Guru**** 173310 points

    For the long link times, please take a look at this page: http://processors.wiki.ti.com/index.php/Linker_Runs_Too_Long
    Using the -b option might help with that.

    For the Dwarf related warnings, do you see those with v7.0.x only or also with 6.1.x? Can you compare the command line options being used for the build across the different versions? Since the warning mentions Dwarf 3 and Dwarf 2, I wonder if you are building for EABI rather than the legacy COFF ABI. More information on EABI for C6000 can be found here: http://processors.wiki.ti.com/index.php/EABI_Support_in_C6000_Compiler
    For this warning, I would first check that the compiler/linker build options match up between all the different compiler versions.

    There is some general information on "relocation overflowed" errors here: http://processors.wiki.ti.com/index.php/Relocation_Overflow_Error but I'm not sure about why the 2-bit address cannot be encoded in the 15-bit field field either. Maybe someone else will comment on that.

  • 0 in reply to AartiG
    Prodigy 120 points

    Thanks alot for your reply.

    Indeed the DWARF warnings are now gone once I force legacy ABI in the compilation (--abi=coffabi flag. I thought that should be the default though?). Apparently that was not the issue that stopped my code from linking properly.

    In addition the -b does indeed eliminate the linker wait time, though something must have changed from 6.0.X version.
    in 6.0.8 my out file size is about 9.5 MB (with compilation and linking time of about 20 minutes), in 7.0.3 it was ~8 MB (with linking time of 12 hours), and in 7.0.3 with -b flag its 25 MB (with around 15 minutes for comp & link). Any idea if I can set legacy type merging in the linker? I couldn't find a flag for that in the wiki.

    But at least that allows me to work now and try different things, so the tip was very much appreciated!

    So that leaves me with lots of relocation overflow warnings, where X bits are to large to encode in 15 bit field, where X < 15.

    By default I am running with --mem_model:data=far, where a few choice modules are using the near model, but these are not the ones in the warning as far as I can see.

    What really troubles me is the last warning:

    warning: output file "X" cannot be loaded and run on a target system

    that really gives me no information as to what might be wrong. (I haven't mentioned it, but of course the compilation and linking are error free).

  • 0 in reply to Gilad Barzilay
    TI__Prodigy 210 points

    To look at this in greater detail, we would need a testcase. Can you provide us one ? This could be a simple cutdown of your testcase which exhibits the problem. Please send us source file(s) and the command line you are using (compile/link options, special lnk.cmd file if using one).

    Thanks,

    Indira

  • 0 in reply to Indira K
    Prodigy 120 points

    Hi Indira,

    I am trying to build a slim version of our project without sharing any proprietary code as a testcase, but once I slim it down that much, the warnings now look better (can't fit 30 bit into 15 bit field).

    I don't think we should have those at all, since our memory model in the remaining code is far, but possibly some of the .lib files we are using (bios, ndk, edma3 driver etc.) are built with a near model.

    it still won't run though, with the conspicuous warning of "cannot be loaded and run on a target system", and I want to send it over, but I have a silly problem: I can't seem to find you email in your profile...

    Since this is possibly a linker bug, I was thinking of sending you our entire compiled project, but without the source or any symbols so our IP will remain protected.

    Could you please recommend which compilation flags I should use to ensure the complete removal of symbols? is --symdebug:none enough?

    Thanks in advance.

  • 0 in reply to Gilad Barzilay
    TI__Guru**** 253590 points

    Gilad Barzilay said:
    I am trying to build a slim version of our project without sharing any proprietary code as a testcase, but once I slim it down that much, the warnings now look better (can't fit 30 bit into 15 bit field).

    Based on that warning message, I'm pretty sure you are experiencing one of the problems detailed here http://processors.wiki.ti.com/index.php/C6000_Memory_models .

    Thanks and regards,

    -George

     

  • 0 in reply to George Mock
    TI__Prodigy 210 points

    Gilad,

         Thanks for your testcase. This is now a bug report SDSCM00037878, and you can check status by typing the bug number here : SDOWP 

    Regards,

    Indira.

  • 0 in reply to Indira K
    Prodigy 120 points

    Hi Indira,

    I can see the defect is still in "accepted" status. Is there any way I can help your internal proccess?

    My email is gilad.barzilay at_sign audiocodes.com if I can assist in any way by providing additional files.

    Is there a rough time estimate for a solution / workaround?

    Thanks and regards,

    Gilad