TDA2xx A15 & gnu tools

Hi Guy,

Since these are GCC and ARM specific questions, I will need spend some time to go through the documentation. I will get back to you by Friday on my findings.

Thanks and Regards,
Piyali

Hi Guy,

Apologies for the delay in reply. We are trying to get the compiler team's help on your questions.

Thanks and regards,

Piyali

I can shed some light.  But I cannot answer all of your questions.

Guy Mardiks said:

When compiling the A15 there are several symbols which the tool-chain have some assumptions about and seems that they need to be set properly.

for example the end symbol is expected to indicate the start of the HEAP and it is assumed that the stack section immediately follows it (follows the heap).

You should see all of these in your linker script.  I presume you use the Linaro ARM GCC compiler that comes with Code Composer Studio.  The base address of the compiler is a location similar to ...

C:\ti\ccsv7\tools\compiler\gcc-arm-none-eabi-4_9-2015q3

There are some basic examples in the location share\gcc-arm-none-eabi\samples .  Go into one of them and see the build commands for it by running "gmake -n".  The -L option shows where the linker scripts are located, and the -T option names the linker script.  The file extension is usually .ld.  Inspect that file.  You will see a comment like this ...

/* Linker script to place sections and symbol values. Should be used together
 * with other linker script that defines memory regions FLASH and RAM.
 * It references following symbols, which must be defined in code:
 *   Reset_Handler : Entry of reset handler
 * 
 * It defines following symbols, which code can use without definition:
 *   __exidx_start
 *   __exidx_end
 *   __copy_table_start__
 *   __copy_table_end__
 *   __zero_table_start__
 *   __zero_table_end__
 *   __etext
 *   __data_start__
 *   __preinit_array_start
 *   __preinit_array_end
 *   __init_array_start
 *   __init_array_end
 *   __fini_array_start
 *   __fini_array_end
 *   __data_end__
 *   __bss_start__
 *   __bss_end__
 *   __end__
 *   end
 *   __HeapLimit
 *   __StackLimit
 *   __StackTop
 *   __stack
 */

Search that file for symbol named end to see how it is defined.  These are the very last lines of the linker script I inspected ...

	.heap (COPY):
	{
		__end__ = .;
		PROVIDE(end = .);
		*(.heap*)
		__HeapLimit = .;
	} > RAM

	/* .stack_dummy section doesn't contains any symbols. It is only
	 * used for linker to calculate size of stack sections, and assign
	 * values to stack symbols later */
	.stack_dummy (COPY):
	{
		*(.stack*)
	} > RAM

	/* Set stack top to end of RAM, and stack limit move down by
	 * size of stack_dummy section */
	__StackTop = ORIGIN(RAM) + LENGTH(RAM);
	__StackLimit = __StackTop - SIZEOF(.stack_dummy);
	PROVIDE(__stack = __StackTop);
	
	/* Check if data + heap + stack exceeds RAM limit */
	ASSERT(__StackLimit >= __HeapLimit, "region RAM overflowed with stack")
}

Just like you said, the symbol end marks the start of the heap, and the stack comes after the heap.

Guy Mardiks said:

I noticed on the map file that there is a section called .ARM.exidx , can someone please a simple explanation as to what this is

Tables for C++ exception handling.  The linker script I inspected puts it in the FLASH memory region.  

As to your other questions ... I have some guesses, but I don't know.  I will post a question with the Linaro organization.  They are the ones who release this compiler.  I have never posted a question before.  This means I'm likely to do it wrong the first time.  Please be patient.  Also, the place you file such questions is not a public forum like this one.  So I have no way to let you see that conversation.

Thanks and regards,

-George

Thanks,
I appreciate you are trying to find answers.
Inn the meanwhile, with what you have wrote, does this mean i have to look at that linker sample file and make sure i have all of the above symbols, appropriately located, on my command file (i cannot use the file as is since the symbols wont be allocated correctly). i assume most of theses symbols only matter for very specific usage, which i probably don't need - i.e. when you said that .ARM.exidx is indicator for Tables for C++ exception handling - since i am not using C++ i guess this is a "don't care" for me - am i right? what about the rest of these symbols - is that part of the answers you'll be looking for on the private form?
I looked at the sample linker script but i am still not sure when and where will i actually need these - there are comments but i don't have a context or what kind of memory mapping does it assumes...

Thanks
Guy

Please keep in mind that the linker script code I show in my first post is only an example.  You need to work out exactly which linker script your build uses, and inspect it.

Guy Mardiks said:

does this mean i have to look at that linker sample file and make sure i have all of the above symbols, appropriately located

No.  In the linker script I show, the only required symbol is Reset_Handler.  And that symbol is defined in the startup code, not user code.  The remaining symbols are defined in the linker script.  User code can, if needed, refer to these symbols, but it is not required.

Guy Mardiks said:

when you said that .ARM.exidx is indicator for Tables for C++ exception handling - since i am not using C++ i guess this is a "don't care" for me - am i right?

Yes.  In your case, this section is empty.

Guy Mardiks said:

I looked at the sample linker script but i am still not sure when and where will i actually need these

The linker documentation, which includes a description of the syntax in a linker script, can be found in a PDF file with a location similar to ...

C:\ti\ccsv7\tools\compiler\gcc-arm-none-eabi-4_9-2015q3\share\doc\gcc-arm-none-eabi\pdf\ld.pdf

Thanks and regards,

-George

With regard to ...

Guy Mardiks said:

also on my map file i see 

.ARM.exidx 0x40324028 0x8
.ARM.exidx 0x40324028 0x8 C:/..../gcc-arm-none-eabi-4_9-2015q3/lib/gcc/arm-none-eabi/4.9.3/fpu\libgcc.a(_divdi3.o)
.ARM.exidx 0x40324030 0x0 C:/..../gcc-arm-none-eabi-4_9-2015q3/lib/gcc/arm-none-eabi/4.9.3/fpu/libgcc.a(_udivdi3.o)
0x8 (size before relaxing)

can you explain what does it mean when it says size before relaxing? does it actually take memory space or not?

Here is the response from the Linaro expert ...

"The .ARM.exidx sections are the exceptions index table sections, the briefest explanation I can give of what these are is a mapping table of function addresses to unwind information. This table is sorted in ascending function address, and has been designed such that consecutive entries that have identical entries can be merged. For example the special entry EXIDX_CANTUNWIND for functions without unwind information are very common, so this can save quite a bit of space.

At link time, sections that have had their size changed are often described as having been "relaxed". So in this case the relaxed size is just the size after the table has had duplicates removed.

More documentation on exception handling can be found in the EHABI http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038b/IHI0038B_ehabi.pdf although this only mentions that duplicate .ARM.exidx table entries can be removed."

Thanks and regards,

-George

Hi,
Thank you very much for your efforts in getting answers.
Will it be possible by you to give a brief simple example of these "exceptions index table sections" to illustrate the usage and behavior and to try make it more clear?

Thanks

The exception handling tables are specially-encoded information about the functions and objects in those functions that need to be considered when propagating C++ exceptions. They are read by special functions in the RTS and are not meant for the user to read directly. For documentation, see infocenter.arm.com/.../IHI0038B_ehabi.pdf