Porting VDSP Linker Steps to GNU ld

The VDSP linker utility is invoked as linker while the GNU linker is invoked as ld.

Here is a comparison of the command line options:

1. The GNU toolchain does not currently support automatic selection of an appropriate jump/call instruction. There are plans to implement support for linker relaxation which would function the same as this flag, but automatically rather than having to code for it.
2. The linker does not know anything about source files, so it knows nothing of dependencies. Use gcc's -M and related options to get automatic make dependency information.
3. The linker does not care what processor it outputs for as the logic is all handled by gcc.
4. The linker does not create any temporary files, thus there is no point in having a -save-temps option.

The main documentation for the GNU linker script format can be found here:
http://sourceware.org/binutils/docs/ld/Scripts.html

1. Multicore systems do not get any special handling. You have to declare the common regions yourself using MEMORY{} and then output objects to the appropriate places using SECTIONS{}.
2. Special support is not provided for reserving space for symbols. These commands can be replaced with a series of simpler commands -- declare the alignment with ALIGN(), set the symbol with the location counter, then update the location counter.
3. The GNU linker does not treat input sections specially. If you want to use the same input to multiple outputs, then specify the input by name multiple times. The wildcard globbing will not pick up things that have already been caught.
4. The linker does not care what processor it outputs for as the logic is all handled by gcc.

http://sourceware.org/binutils/docs/ld/MEMORY.html

The VDSP linker uses the term segment when referring to the ranges defined by the MEMORY{} command. The GNU linker describes them as memory regions as it uses segment for something else (which is used infrequently).

A VDSP LDF file takes the form:

MEMORY
{
	segment_name: TYPE(...) START(...) LENGTH(...) END(...) WIDTH(...)
}

While the GNU LDS file takes the form:

MEMORY
{
	name (attr): ORIGIN = ..., LENGTH = ...
}

http://sourceware.org/binutils/docs/ld/SECTIONS.html

A VDSP LDF file takes the form:

SECTIONS
{
	section [type] [init] {
		section_commands
	} > memory
}

While the GNU LDS file takes the form:

SECTIONS
{
	section [addr] [type] : [AT(addr)] [ALIGN(num)] {
		section_commands
	} [>memory] [AT>memory] [=fill]
}

TBD

TBD

http://sourceware.org/binutils/docs/ld/Overlay-Description.html

ALGORITHM ALL_FIT BEST_FIT FIRST_FIT NUMBER_OF_OVERLAYS OVERLAY_GROUP OVERLAY_ID OVERLAY_INPUT OVERLAY_OUTPUT

The VDSP linker supports elimination on a per-symbol and per-section basis. The GNU toolchain also supports this same functionality in the end, but it takes a completely different tact.

When compiling C code, the compiler flags -ffunction-sections and -fdata-sections instruct GCC to place every function and variable in its own dedicated section. These typically take the form of .text.function and .data.variable where function and variable get replaced with the actual symbol name.

Then when linking, the --gc-sections flag instructs the linker to discard all sections that are not referenced. If you want to prevent specific symbols from being discarded in your linker script, you can use the KEEP() command.

While VDSP supports preprocessing in the linker itself, the GNU toolchain does not. Instead, these steps are kept logically separate by design -- have one tool do one thing and one thing only, and have it do it well. As such, if you want to have a dynamic linker script (i.e. preprocess it), then you can first run it through the preprocessor before passing it to the linker. This is how many projects work such as Das U-Boot and the Linux kernel.

Typically you'll see rules like the following in the Makefile:

....
myscript.lds: myscript.lds.S
	$(CPP) $(CFLAGS) $(CPPFLAGS) $< > $@
....
myapp: myscript.lds
	$(LD) -Wl,-T,myscript.lds ....
....

This allows you to use all the normal CPP magic such as the -DDEFINE=value and -Ipath flags and the #if logic in the source itself. Since you have access to all the same defines as normal C code, you can do processor/silicon specific stuff by checking the normal ADSPBF### and related defines.

If the ported program is a library, you will need to link the library with your uClinux application. You may use Gnu Linker Scripts to direct the Gnu linker.

• Define Sections in Linker scripts:

By default, the Linker uses Linker scripts defined in <bfin-uclinux-toolchain>/bfin-uclinux/lib/ldscripts/. when the ported library defines its sections, you may dump the scripts and define your section in the file:

For example, supposing the library defines “my_data_1” section and you want the linker copy this secions from all the source files to data section:

# Dump default linker script

./bfin-uclinux-ld --verbose > my_ld.x

# Modify my_ld.x, add in the .data{} definition:

SECTIONS
{
   ...
   .data
   {
     *(.data .data.* .gnu.linkonce.d.*)
     *(my_data_1) /* Add my data secton here */
   }
}