TMS320C6748: .far section is auto filled on linked in libraries

Hello,

cobsonchael said:

when i build a project every 3rd party library linked in gets the .far section filled with 0.

By default, the linker doesn't fill .far section with 0. Did you mean only the .far sections from 3rd party libraries get filled with 0? How about the .far sections you created in your code?

Regards,

Jianzhong

My compiled code are not auto filled, but the 3rd party libraries are. What causes this? 

You should check how the 3rd party libraries are built.

and what do i ask them to look for?

You can report to them as you reported in your initial post here.

yes but is there a setting or a compiler that i can point them to? for example if they are using the C6000 7.3.x compiler will it have this effect? is there a linker setting in another compiler that is common that you know might do this? i already have reported this to them and they are sure it's something we can fix in our linker (of which i could not find any setting that i could change that would make a difference)

Can you verify the 3rd party library's .far sections get filled with 0 by:

1. before you load the code (.out) through CCS, fill the memory designated for your 3rd party library's .far sections with some non-zero values.

2. load the code (.out) through CCS and check the .far sections from 3rd party libraries and see if memory is filled with zeros

i don't need to know HOW to tell if they are filled, i can look at the map file to do that

what i want to know is WHAT SETTINGS they are using that could cause the .far section to be filled, and to have that filled section translate via AIS to the output binary to a static field of all 0's that isn't needed.

Are your 3rd party using TI compiler? If so, which compiler is used?

from our 3rd party vendor:

We are linking with '-r -h -x'.  I also tried --zero_init=off.  The tools are 7.4.16. 

Thank you for the information. Let me loop in our compiler team for comments.

We'll need some more information to make a determination regarding the exact nature of the issue you are seeing and whether it is due to the link.

What would initially assist is:

1. The linker command file you are using.
2. The linker command you are using.
3. The output map file from --map_file.
4. Identifying a problem section in the map file. (Specifically, for the 3rd party filling.)

Also to confirm: using --fill_value during the link changes the fill value?

Thanks,
Zachary Morgan

You say that you are getting a "library" from a third party, but I think you're actually getting a relocatable object file produced by a partial link.  Technically, a library is an archive of relocatable object files, usually object files that come directly from the compiler; a partially-linked relocatable object file is produced by the linker by using the --relocatable ("-r") option.  The important thing is that the third party is doing a partial link.

If the third-party .far sections are being filled, and your own .far sections are not being filled, there is no option or configuration you can use during the final link to avoid the third party .far sections from being filled.  I suspect the third-party .far sections are being filled during the partial link, so this is an issue that can only be resolved by the third party altering the partial link step.  It would be helpful to get the linker map file from the third party's partial link step.  It would also be useful to see the output of ofd6x on the third-party relocatable object file; of particular interest is whether the .far section in that object file is initialized.

Also, are you using EABI or TI-COFF?

my linker command:

-mv6740 --abi=eabi -O3 --define=c6748 --define=STD_ --define=_INCLUDE_NIMU_CODE --define=NDEBUG --symdebug:none --c99 --printf_support=nofloat --diag_warning=225 --diag_wrap=off --display_error_number --interrupt_threshold=1000 --check_misra="3" -z -m"Model840i.map" -i"C:/ti/ccs1120/ccs/tools/compiler/ti-cgt-c6000_8.3.12/lib" -i"C:/Git/Model8x0iVoIP/Working/Lib" -i"C:/ti/ccs1120/ccs/tools/compiler/ti-cgt-c6000_8.3.12/include" --priority --reread_libs --diag_wrap=off --display_error_number --warn_sections --xml_link_info="Model8x0iVoIP Working_linkInfo.xml" --rom_model

our custom linker command file just ID's libraries that we want to link in. in this specific instance: 

SIP_Library : {-lvclsiplib.obj} > DDR

the map file portion that is an example and the main problem

SIP_Library
* 0 c2621d00 00508d60
c2621d00 003fcbcc vclsiplib.obj (.far:.common) [fill = 0]

i went to where that address is loaded in our binary and observed the ocean of 0's there

the vendor tried 8.2.2 and while their "library" got smaller it did not provide any relief for our output binary

we are all ELF/EABI

The ".far:.common" section is quite a bit different than the rest of the ".far" section.  The ".far:.common" section is what is known as a "common" section.  Such a section is not supposed to have any raw data in the input object file because is intended to be allocated by the linker.  Please run "ofd6x vclsiplib.obj" and look at the section list.  Does the section ".far:.common" show up in the section list?  If so, please post that line here.

3292 .far:.common              0x00000000 0x00000000 0x3fcbcc     8   Y  

3209 .far:.common    0x00000000 defined   .far:.common    local   section 

i should note that before they changed their "library" to try and help the situation the map file used to show up as this:

c312c020    003cc390     vclsiplib.obj (.far:data.obj) [fill = 0]

let me know what else you need i saved the output to a file

did i miss something you needed? any work on this? 

as i mentioned before changing the fill value does change the value of the fill.  quote from original post:

"an observation: when i set the autofill for hole value to something else, the .far section gets filled with that new value. so the .far section seems to be treated like a hole"

I apologize for the delay.  Among other things, everyone I want to speak with about this thread is out.  In the mean time, here are some thoughts and questions.  I worry they may not be helpful.  But maybe they will.

cobsonchael said:

from our 3rd party vendor:

We are linking with '-r -h -x'.  I also tried --zero_init=off.  The tools are 7.4.16. 

A 3rd party vendor usually supplies a library of object files.  Similar in form to the RTS library that comes with the compiler.  A library is created with the archiver, not the linker.  Why does this vendor link?  What advantage is gained?  

This code from your linker command file ...

cobsonchael said:

SIP_Library : {-lvclsiplib.obj} > DDR

... says to create an output section SIP_Library.  Despite that name, it is an output section, and not a library.  It is made up of all the input sections from the object file vclsiplib.obj.  Despite that name, it is an object file, and not a library.  The -l tells the linker this object file is not located in the current directory, but in one of the directories named with the -i or --search_path options.  It is allocated to the DDR memory range.  It is unusual to put all of the input sections from one object file into the same output section.  Are you sure this is intended?

Thanks and regards,

-George

unfortunately i cannot speak for the vendor. here is what they sent me, though:

I reviewed what I have here, and I think I am getting different results than you:

One area that is large, and was filled with zeros in the v5 toolchain with out any special flags was .fardata:sip_provider_outgoing :

.fardata:sip_provider_outgoing:provider.obj
*          0    00000000    0001ce00     
                  00000000    0001ce00     provider.obj (.fardata:sip_provider_outgoing)

linking the object library with the v5 tools and no extra flags:

lnk6x -r -h -x  -ovclsiplib.obj -mvclsiplib.map voipmain/voipapi.ctl arch\mst_link.rsp

and then the final executable like this:

lnk6x -ic:\ti\ccsv8\tools\compiler\ti-cgt-c6000_8.2.2\lib    -cr -x --zero_init=off --rom_model  -otimdm.out -mtimdm.map  vclsiplib.obj libcrypto.a libssl.a ../link/custom/voipapi_main.obj ../link/vsock/vsock.obj

we got something like this:

.fardata   0    006119d0    0002f84c     
                  006119d0    0001ce00     vclsiplib.obj (.fardata:sip_provider_outgoing:provider.obj)


linking the object library with V8 tools, and with the flags --zero_init=off --rom_model like this:

lnk6x -r -h -x --zero_init=off --rom_model  -ovclsiplib.obj -mvclsiplib.map voipmain/voipapi.ctl arch\mst_link.rsp

Once we link the final executable with the new tools (also with the --zero_init=off --rom_model flags):

lnk6x -ic:\ti\ccsv8\tools\compiler\ti-cgt-c6000_8.2.2\lib    -cr -x --zero_init=off --rom_model  -otimdm.out -mtimdm.map  vclsiplib.obj libcrypto.a libssl.a ../link/custom/voipapi_main.obj ../link/vsock/vsock.obj

we get this:

.fardata   0    0060d4f8    0002f84c     UNINITIALIZED
                  0060d4f8    0001ce00     vclsiplib.obj (.fardata:sip_provider_outgoing:provider.obj)

as far as our section is concerned:

yes, we know it's an output section, an output section for the code that comes in the "library" we use wrapped up into one single area of memory. this is intended. we get a lot of "libraries" that do not end in .lib so they are not automatically linked into the project without explicit commands. the reason we do it this way? it's a legacy thing that has been carried over from our very first project using code composer all the way to (and likely before ) CCS3. before my time. in the old days it helped them to be able to move the code around between different defined memory locations so they could fit everything into the hardware.  we never really had an issue with linking in "libraries" this way so we kept doing it. are you saying this method is harming us in some way? i do know about adding files specifically in CCS, we just don't do it that way for this project.

I'm not sure what is meant by "v5 tools" or "v8 tools".  I see compiler version 8.2.2 gets used.  At the start of this thread, version 8.3.12 is given.  Please be more precise about the version of the compiler (not CCS) that is used.  Ideally, version 8.3.12 (the latest) is used everywhere.  But I understand that may not be practical.

On our end, discussion continues.  We think there may be a linker bug in how the .far section is formed when the -r option (partial linking) is used.

Thanks and regards,

-George

that was a note from our vendor

WE (the customer) use 8.3.12, our vendor was using v7 (i think the v5 was a typo) compiler tools and have since tried to use 8.2.2 for the "library" they deliver. i am not being inconsistent there are 2 different tools used. they build something with one compiler tool, hand it to use, we add it to our project and use another compiler tool. they do not seem immediately willing to use the same compiler tool as us. is that more clear? i await your findings

This thread will continue in private messages.  Once it concludes, I will post a summary. For now, I will close this thread, even though it is not actually closed.

Thanks and regards,

-George