linking error: undefined __binit__ symbol in rts67plus_elf.lib

The symbol __binit__ is supposed to be created by the linker automatically if it is missing.  Are you using linker version 7.2.9?  Are you using any "table" operators in your linker command file?

Hi,

I think I am using the linker 7.2.9 as the CGT set in the project CCS buid settings is 7.2.9 and the options shown in the linker settings command windows are including this:

-i"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/C6000 Code Generation Tools 7.2.9/lib"

-i"C:/Program Files/Texas Instruments/ccsv4/tools/compiler/C6000 Code Generation Tools 7.2.9/include"

can I be mistaken?!

I am also using a CommonPlugIn_LinkerCmd.cmd file which is common to all our projects. I don't have control on this file as it is provided by the company who deals with the host where our plugins run on, within the SDK (see attachment).

/******************************************************************
	CommonPlugIn_LinkerCmd.cmd

	Copyright (C) 2010 by Avid Technology, Inc.
	All Rights Reserved.

	Common linker settings for TI Plug-In's building
	as relocatable ELF DLL's
******************************************************************/

--relocatable
--dynamic=lib
/*-x*/

-lrts67plus_elf.lib
--export=_auto_init_elf	/* This function properly initialize the .bss section from the .cinit segment */

-stack 0x0 /* Shell owns the stack; none defined for the plug-ins */

-heap  0x0100 /* don't need heap */ 



/****************************************************************************/
/*  Memory Specification                                                    */
/****************************************************************************/

MEMORY
{
  INTERNAL_MEM			: origin = 0x00000000 	length = 0x80100000 
  EXTERNAL_MEM    		: origin = 0x80100000 	length = 0x7FEFFFFF
}

/****************************************************************************/
/*  Specify the Output Sections                                             */
/****************************************************************************/

SECTIONS
{
	/* Read-only (RO) Sections */
	.text:			load = INTERNAL_MEM align 32 		/* Code */
	.switch:		load = INTERNAL_MEM					/* Switch tables */
	.const:			load = INTERNAL_MEM 				/* Far const data */
	.cinit:			load = INTERNAL_MEM 				/* Boot-time init tables */
	
	/* DP-relative Read-Write (RW) Sections - TODO: Not using DP-relative data for Plug-Ins*/
    GROUP (NEARDP_DATA)	/* from http://focus.ti.com/lit/an/sprab90/sprab90.pdf */
    {
	    .neardata						/* Near RW data (initialized) */
	    .rodata							/* Near const data */
	    .bss							/* Near RW data (uninitialized) */
    }	load = INTERNAL_MEM
    
    /* Absolute Read-Write (RW) Sections */
	.far:			load = INTERNAL_MEM						/* Far RW data (initialized) */
	.fardata:		load = INTERNAL_MEM						/* Far RW data (uninitialized) */
	.stack:			load = INTERNAL_MEM, fill = 0xdeadbeef	/* Program stack */
	.sysmem:		load = INTERNAL_MEM						/* Dynamic data (heap) */
	
	/* Other c6x EABI sections */
	.init_array:	load = INTERNAL_MEM	/* Pre-main constructors */
	.fini_array:	load = INTERNAL_MEM	/* Pre-main constructors */
    .c6xabi.exidx:	load = INTERNAL_MEM	/* Index table for exception handling */
    .c6xabi.extab:	load = INTERNAL_MEM	/* Unwinding instructions for exception handling */
    .binit:			load = INTERNAL_MEM	/* Boot-time copy tables */
	.cio:			load = INTERNAL_MEM	/* Handshaking buffer for host-based stdio */
	.args:			load = INTERNAL_MEM	/* Command arguments for host-based loader */
	.ppinfo:		load = INTERNAL_MEM	/* Correlation tables for compiler-based profiling */

	.vectors:		load = INTERNAL_MEM
	.plt:			load = INTERNAL_MEM 		
	
	/* User-defined sections */
	.intmem:		load = INTERNAL_MEM
	.extmem:		load = EXTERNAL_MEM align 32
	.extmemdata:	load = EXTERNAL_MEM
}

Let me know what I can do...

Thanks 

First of all, I note that you are creating a dynamic shared object library (also known as a DLL).

This error is triggered by the following option in your linker command file: "--export=_auto_init_elf"

I do not know why this is so.  We'll need someone with expertise on dynamic shared objects to comment on this thread.

Indeed I am building a DLL.

Unfortunately if I try to remove  "--export=_auto_init_elf" from the linker command file the resulting DLL stops from loading properly, as some symbols are missing.

I also have a CommonPlugIn_CompilerCmd.cmd shared by all the projects, which I report below as it might give you some more clues:

-mv67p
--abi=eabi
--mem_model:data=far
--gcc
--long_precision_bits=32
--keep_asm
--src_interlist
--asm_listing
--diag_warning=225
--debug_software_pipeline

To summarise:

If I use CGT v7.0.5 the project builds and works fine but I cannot use the c67mathlib with it (see the post linked above)

If I use CGT v7.2.9 the project does not build showing the __binit__ linker error.

If I omit the "--export=_auto_init_elf" flag the project builds but stops working, as the DLL is missing symbols

Let me know what I can do to help you guys to fix this issue.

Best

Hello Marcello,

I would have expected that a dynamic executable would perform auto-initialization as opposed to a dynamic library. I am confused about why you are linking in the RTS library, exporting the _auto_init_elf function pointer, and creating a stack and heap in the build of a dynamic library.

Can you provide a broader description of what you are trying to do? If I can get a better idea of what your situation is, I may be able to point you to some useful examples that could give further insight into how to build what you want.

Regards,

Todd Snider

C6000 Code Generation Tools

Texas Instruments Incorporated

Hi Todd,

All I can give you is a few snippets from the manual reported below...

I will have to ask more low level info to the company which provided the SDK and its environment settings.

As They are quite busy I am not sure how long it will take or if they actually will to, but bear with me until I come back with something useful.

Cheers.

1 Overview of TI algorithms in AAX Avid’s hardware-accelerated audio systems allow AAX plug-ins to offload their real-time processing tasks to a dedicated processor, guaranteeing reliable performance at ultra-low latency. Avid’s TI-based products utilize Texas Instruments DSP chips to host plug-ins in a managed shell environment. The AAX host handles all system-level communications and resources on the DSP and provides a consistent API to manage communication between the plug-in’s real-time algorithm and its other components. This design allows AAX plug-ins to use the same communication methods whether they are running natively, on a TI-based accelerated system, or in some other distributed environment. Each AAX plug-in contains a real-time algorithm callback. For TI DSP-based platforms, this callback is compiled into a relocatable ELF DLL. This library is loaded onto the appropriate DSP by the host, and may share the DSP with other plug-ins if the host determines that the required system resources are available.

3.1 Plug-in description To support AAX TI DSP platforms, a plug-in must add a TI ProcessProc (real-time processing entry- point) for each of its algorithms. This is done via a call to AAX_IComponentDescriptor::AddProcessProc_TI(), which is parametrized with the names of both the algorithm’s TI DLL and of its exported entrypoint.

Hi Todd,

here is a bit more to it:

"The "--export=_auto_init_elf" flag, as far as I understand, makes sure that the auto_init_elf() function is exported from the DLL so that it can be called when the PI is first loaded on the DSP. This function initializes data blocks, and is located in rts67plus.lib - it's not anything custom that we did. I think that the symptom of a problem with this would either be a DLL that doesn't load properly, or a burst of noise from uninitialized data at the start of processing by the DSP PI."