Announcements

Ever wondered how you could shape the future in collaboration with others? Join us at OktoberTech Asia Pacific and get inspired. Click here to sign up FREE of charge.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

AURIX™ Forum Discussions

amit
Level 1
First reply posted First question asked First like given
Level 1

Hello,

In my project I wish to control the exact location in memory of every section. I have managed to do so in most cases by altering the linker script to use the run_addr attribute on a group that contains the desired section, for example:

group (contiguous, ordered, run_addr=0x80008000)
{
section ".text.nice_function.bla.o" (fill=0, attributes=rx)
{
select ".text.nice_function.bla.o";
}
}

However, I've encountered a case in which some object files which I don't have their source code (such as "bad_alloc.o" from "ctc/lib/tc16x/libcpsx_fpu.a") have multiple sections with the exact same name (like ".text.libcpsx_fpu" in "bad_alloc.o"), so when trying to use the same trick, I cannot distinguish between the different sections with that name (since the identification of sections is done by name).

I did think of trying to rename each section to have a unique name, but elfpatch tool also identifies sections by name...

So my questions are:

  1. Is there a way to control the location of each of those sections separately, despite they have the same name?
  2. In case there is no way to handle each of these sections separately, is there any deterministic order they would be mapped in memory? if so, what is it?

Thanks in advance,
Amit

0 Likes
1 Solution
User13836
Level 4
10 solutions authored 50 replies posted 25 sign-ins
Level 4

Hello Amit,

the commercial version of the TASKING TriCore tools does include the source code for the libraries included in the installation too. In addition  makefiles to rebuild the various versions of the libs.

Please have a look at the details listed below which show the section names and their number using the default naming scheme when compiling the bad_alloc source module and using --section-name-with-symbol when the source module is compiled, which adds the symbol name to the compiler generated section.

Default version bad_alloc.o:

.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.rodata.libcpsx_fpu
.rodata.libcpsx_fpu
.rodata.libcpsx_fpu
.rodata.libcpsx_fpu
.rodata.libcpsx_fpu
.rodata.libcpsx_fpu
.data.libcpsx_fpu
.data.libcpsx_fpu
.data.libcpsx_fpu
.rodata.libcpsx_fpu
.data.libcpsx_fpu
.data.libcpsx_fpu

 

bad_alloc.o file generated after --section-name-with-symbol has been added to the compiler options:

.text._ZNSt9bad_allocC1Ev.libcpsx_fpu
.text..cocofun_4.libcpsx_fpu
.text..cocofun_3.libcpsx_fpu
.text..cocofun_2.libcpsx_fpu
.text._ZNSt9bad_allocC2Ev.libcpsx_fpu
.text._ZNSt9bad_allocC1ERKS_.libcpsx_fpu
.text._ZNSt9bad_allocC2ERKS_.libcpsx_fpu
.text._ZNSt9bad_allocaSERKS_.libcpsx_fpu
.text._ZNSt9bad_allocD1Ev.libcpsx_fpu
.text..cocofun_5.libcpsx_fpu
.text._ZNSt9bad_allocD0Ev.libcpsx_fpu
.text._ZNSt9bad_allocD2Ev.libcpsx_fpu
.text._ZNKSt9bad_alloc4whatEv.libcpsx_fpu
.text._ZNSt20bad_array_new_lengthC1Ev.libcpsx_fpu
.text._ZNSt20bad_array_new_lengthC2Ev.libcpsx_fpu
.text._ZNSt20bad_array_new_lengthD1Ev.libcpsx_fpu
.text._ZNSt20bad_array_new_lengthD0Ev.libcpsx_fpu
.text._ZNSt20bad_array_new_lengthD2Ev.libcpsx_fpu
.text._ZSt17__throw_bad_allocv.libcpsx_fpu
.rodata._ZTVSt9bad_alloc.libcpsx_fpu
.rodata._ZTVSt20bad_array_new_length.libcpsx_fpu
.rodata._ZTISt9bad_alloc.libcpsx_fpu
.rodata._ZTISt20bad_array_new_length.libcpsx_fpu
.rodata._ZTSSt9bad_alloc.libcpsx_fpu
.rodata._ZTSSt20bad_array_new_length.libcpsx_fpu
.data._999001___T1.libcpsx_fpu
.data._999002___T5.libcpsx_fpu
.data._999003___T11.libcpsx_fpu
.rodata..1.str.libcpsx_fpu
.data._999004___T17.libcpsx_fpu
.data._999005___T21.libcpsx_fpu

 

Best regards,
Ulrich

TASKING tools support

 

View solution in original post

3 Replies
User13836
Level 4
10 solutions authored 50 replies posted 25 sign-ins
Level 4

Hello Amit,

the symbol name is not included in C++ library object files because the C++ compiler is a front end which generates C code which is processed by the C compiler afterwards. The section name is defined by the C compiler. 

It makes no sense to have section names with mangled symbol names. Mangled section names are not very readable in map files and are not very helpful for lsl section selection. Section names should have the library name as suffix only.

For the C library it's different. Here no name mangling is required and the symbol name is included in the section name of the C library functions.

Regarding your questions:

  1. Is there a way to control the location of each of those sections separately, despite they have the same name?

    AW: No. Because the linker utilizes section names only.

  2. In case there is no way to handle each of these sections separately, is there any deterministic order they would be mapped in memory? if so, what is it?

    AW: As far as I remember the section order if there are multiple sections with the same name are selected in a LSL group is defined by the section size. So the smaller sections are placed first, followed by the larger sections.

The commercial version of the TASKING TriCore tools does include the source code for the C/C++ libs and the run time and FP libs. Including makefiles to rebuild the libs.

Best regards,
Ulrich Kloidt

TASKING tools support

 

amit
Level 1
First reply posted First question asked First like given
Level 1

Hello Ulrich,

Thanks a lot for the very detailed reply.

I have one more question regarding this part of your reply:


@User13836 wrote:

It makes no sense to have section names with mangled symbol names. Mangled section names are not very readable in map files and are not very helpful for lsl section selection. Section names should have the library name as suffix only.

How can I disable this behavior so the mangled symbol names would become a part of the section name (if that's possible)?

Thanks,
Amit

0 Likes
User13836
Level 4
10 solutions authored 50 replies posted 25 sign-ins
Level 4

Hello Amit,

the commercial version of the TASKING TriCore tools does include the source code for the libraries included in the installation too. In addition  makefiles to rebuild the various versions of the libs.

Please have a look at the details listed below which show the section names and their number using the default naming scheme when compiling the bad_alloc source module and using --section-name-with-symbol when the source module is compiled, which adds the symbol name to the compiler generated section.

Default version bad_alloc.o:

.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.text.libcpsx_fpu
.rodata.libcpsx_fpu
.rodata.libcpsx_fpu
.rodata.libcpsx_fpu
.rodata.libcpsx_fpu
.rodata.libcpsx_fpu
.rodata.libcpsx_fpu
.data.libcpsx_fpu
.data.libcpsx_fpu
.data.libcpsx_fpu
.rodata.libcpsx_fpu
.data.libcpsx_fpu
.data.libcpsx_fpu

 

bad_alloc.o file generated after --section-name-with-symbol has been added to the compiler options:

.text._ZNSt9bad_allocC1Ev.libcpsx_fpu
.text..cocofun_4.libcpsx_fpu
.text..cocofun_3.libcpsx_fpu
.text..cocofun_2.libcpsx_fpu
.text._ZNSt9bad_allocC2Ev.libcpsx_fpu
.text._ZNSt9bad_allocC1ERKS_.libcpsx_fpu
.text._ZNSt9bad_allocC2ERKS_.libcpsx_fpu
.text._ZNSt9bad_allocaSERKS_.libcpsx_fpu
.text._ZNSt9bad_allocD1Ev.libcpsx_fpu
.text..cocofun_5.libcpsx_fpu
.text._ZNSt9bad_allocD0Ev.libcpsx_fpu
.text._ZNSt9bad_allocD2Ev.libcpsx_fpu
.text._ZNKSt9bad_alloc4whatEv.libcpsx_fpu
.text._ZNSt20bad_array_new_lengthC1Ev.libcpsx_fpu
.text._ZNSt20bad_array_new_lengthC2Ev.libcpsx_fpu
.text._ZNSt20bad_array_new_lengthD1Ev.libcpsx_fpu
.text._ZNSt20bad_array_new_lengthD0Ev.libcpsx_fpu
.text._ZNSt20bad_array_new_lengthD2Ev.libcpsx_fpu
.text._ZSt17__throw_bad_allocv.libcpsx_fpu
.rodata._ZTVSt9bad_alloc.libcpsx_fpu
.rodata._ZTVSt20bad_array_new_length.libcpsx_fpu
.rodata._ZTISt9bad_alloc.libcpsx_fpu
.rodata._ZTISt20bad_array_new_length.libcpsx_fpu
.rodata._ZTSSt9bad_alloc.libcpsx_fpu
.rodata._ZTSSt20bad_array_new_length.libcpsx_fpu
.data._999001___T1.libcpsx_fpu
.data._999002___T5.libcpsx_fpu
.data._999003___T11.libcpsx_fpu
.rodata..1.str.libcpsx_fpu
.data._999004___T17.libcpsx_fpu
.data._999005___T21.libcpsx_fpu

 

Best regards,
Ulrich

TASKING tools support