Relocate specific object files of a library - gcc

I have a GCC project for ARM Cortex-M3. The linker script defines where each source section has to be located. So I have sections like this
.text :
{
*(.text)
} > FLASH
_sidata = .;
.data : AT (_sidata)
{
_sdata = .;
*(.data)
_edata = .;
}
The project consumes the library lib.a that contains the object file object.o and other.o. Now I want that the .text section of object.o shall be placed between _sdata and _edata. The objectiv is that these section would be copied by the startup code from the FLASH to RAM and it will be executed there. The other.o shall not be placed in that section since it's too large.
I tried it like in this SO question
.data : AT (_sidata)
{
_sdata = .;
*(.data)
object.o(.text)
_edata = .;
}
But this fails since the object.o is taken from a library and is not direct available.

I found it by myself. The library must be specififed.
.data : AT (_sidata)
{
_sdata = .;
*(.data)
lib.a:object.o(.text)
_edata = .;
}

Related

How do i set up data memory address when using "riscv32/64-unknown-elf-gcc"?

I designed RISCV32IM processor, and i used "riscv32/64-unknown-elf-gcc" to generate code for test.
Instruction memory setting has been solved with the options below(-Ttext option), but data memory setting has not been solved yet.
riscv64-unknown-elf-gcc -v -march=rv32im -mabi=ilp32 -nostartfiles -x c -Ttext 40000000 -o main.o main.c
Can I know if I can set the data memory address I want?
looks like you need to link linker script, something like:
OUTPUT_ARCH( "riscv" )
ENTRY(_start)
SECTIONS
{
. = 0x40000000;
.text.init : { *(.text.init) }
. = ALIGN(0x1000);
.text : { *(.text) }
. = ALIGN(0x1000);
.data : { *(.data) }
.bss : { *(.bss) }
_end = .;
}
_start is a start symbol and 0x40000000 is a memory start address,
followed by the section names aligned by 0x1000.
text this is the program itself
data is a statically initialized variables
bss
is a statically allocated variables

Linker Scripts: Can I specify (*COMMON) in more than one section?

If I have two sections in my linker script, .bss and .newsect, can I include (*COMMON) in both like I have done below? Why or why not?
.bss :
{
/* This is used by the startup in order to initialize the .bss section */
_sbss = .; /* define a global symbol at bss start */
__bss_start__ = _sbss;
*(.bss)
*(.bss*)
*(COMMON)
. = ALIGN(4);
_ebss = .; /* define a global symbol at bss end */
__bss_end__ = _ebss;
} >RAM_D1
.newsect :
{
/* This is used by the startup in order to initialize the .bss section */
_snewsect = .; /* define a global symbol at bss start */
__newsect_start__ = _snewsect;
*(.newsect)
*(.newsect*)
*(COMMON)
. = ALIGN(4);
_enewsect = .; /* define a global symbol at bss end */
__newsect_end__ = _enewsect;
} >RAM_D1
This will not do any harm, but all the matching input sections will have already been allocated to output sections by the first time you specify them so the second time will not match anything and will do nothing.

detection of memory section overflow in ld

I have a microcontroller project using the GCC tool chain.
gcc version 4.7.4 20130913 (release) [ARM/embedded-4_7-branch revision 202601]
The controller has 512k flash memory. The first 64k are occupied by the bootloader and 448k remain for the project. I defined a linker script with the sizes for FLASH and RAM. I also added the sections. Here is an excerpt:
MEMORY
{
FLASH (rx) : ORIGIN = 0x00010000, LENGTH = 448K
RAM (xrw) : ORIGIN = 0x10000000, LENGTH = 64K
}
SECTIONS
{
.text :
{
. = ALIGN(4);
*(.text) /* .text sections (code) */
} > FLASH
.fini_array :
{
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(.fini_array*))
PROVIDE_HIDDEN (__fini_array_end = .);
_eflash = .;
} >FLASH
/* used by the startup to initialize data */
_sidata = .;
.data : AT ( _sidata )
{
*(.data) /* .data sections */
*(.data*) /* .data* sections */
_edata = .; /* define a global symbol at data end */
} >RAM
}
The linker works fine placing all section at their places. The problem is that the linker does not check if there is enough space for the .data and .data* sections in the FLASH at the location _sidata. The resulting output exceeds the memory size without any warning.
How can I adapt the linker script so that ld will use the initialization data (.data) in the size calculation?
Edit: Is there any command line option to enforce a sensible data placement?
This linker malfunction can be revealed with an ASSERT:
/* used by the startup to initialize data */
_sidata = .;
.data : AT ( _sidata )
{
_sdata = .;
*(.data) /* .data sections */
*(.data*) /* .data* sections */
_edata = .; /* define a global symbol at data end */
} >RAM
/* verify that the initialization data fits in FLASH */
ASSERT(
(_sidata + (_edata - _sdata)) <= (ORIGIN(FLASH) + LENGTH(FLASH)),
"Initialization Data blow up")
}

Where _bss_start is define Linux kernel source

I am going through Linux kernel source and found _bss_start C varianle in one of assembly files but could not find where it is actully defined and intialized.
It looks like _bss_start is the starting address of the bss segment but where and how it is intialized with values in kernel source ,I am looking into linux source 2.6.25.
I looked into file asm-generic/section.h where it is defined like below
extern char _bss_start[]
but how _bss_start is defined ,is it DS register is being used to intialized it
__bss_start is defined and initialized by the linker. It references the .bss section of the image, which contains statically allocated variables.
Here is a stripped down example of the linker script defining these symbols:
.bss : {
__bss_start = .; /*< __bss_start references this position in the file */
*(.bss) /*< The actual contents of the section */
*(COMMON) /*< The actual contents of the section */
_ebss = . ; /*< _ebss references this position in the file */
}

Advice on linker script creation and verification

Long story short. I wish to learn how to create a good linker script so that should I change platforms/architectures/vendors, I'm not stuck at ground zero again with not knowing what to do. I'm not concerned with the difficulty of the task, so much as understanding it.
I've started a sort of project, as it were, to create a base or skeleton for programing and developing on STM's 32-bit Cortex-M3 chips. With the help of jsiei97 Beginning with the STM32F103RB (I also have a TI Stellaris LM3S828, but that's another issue), without the need of a licensed IDE. Since I am a student, and most students can't afford such things.
I understand that there's the ODev, and Eclipse Plugins and what not, and have read various blogs, wikis, docs/man pages and most projects provide you with a linker script with little to know explanation as to why and where things have been defined.
I've compiled an arm-none-eabi toolchain for the STM32 but where I get hung up is in the linker script. CodeSourcery also requires one as well. I have a basic concept of how to create them and their syntax after reading the gnu man pages, but I simply haven't a clue where to start with putting in the various extra sections apart from the obvious .text, .bss and .data.
I created a rudimentary version but I get linking errors asking for section definitions and that's where I get stuck. I know how to define them, but knowing if what I'm doing is even close to right is the problem.
I have a simple linker script I reuse regularly across platforms, just change some addresses as needed.
http://github.com/dwelch67/
There are a number of samples many with gcc samples and most of those have linker scripts.
MEMORY
{
rom : ORIGIN = 0x00000000, LENGTH = 0x40000
ram : ORIGIN = 0x10000000, LENGTH = 30K
}
SECTIONS
{
.text : { *(.text*) } > rom
.bss : { *(.bss*) } > ram
}
Here is a working linker script for an STM32F105RB (there are also versions for R8 and RC):
https://github.com/anrope/stm-arp/blob/github/arp.rb.ld (text below)
My top-of-the-head guess is that you wont have to change anything. Maybe the origin of the regions defined in the MEMORY{} statement. Hopefully the comments will be helpful to you.
I used this with a GNU/GCC cross-compiler I rolled myself. After compiling, it's helpful to run nm on your code to make sure sections are being placed at the correct addresses.
Edit:
I pieced this linker script together by using the GNU ld documentation:
http://sourceware.org/binutils/docs/ld/
and by examining the output of a GCC cross-compile with the standard linker script, using nm. I basically identified all the sections that were being output and figured out which ones were actually useful, and where in memory they should go for the STM32F105.
I made notes in the linker script of the purpose of each section.
/*
arp.{r8,rb,rc}.ld :
These linker scripts (one for each memory density of the stm32f105) are used by
the linker to arrange program symbols and sections in memory. This is especially
important for sections like the interrupt vector, which must be placed where the
processor is hard-coded to look for it.
*/
/*stm32f105 dev board linker script*/
/*
OUTPUT_FORMAT() defines the BFD (binary file descriptor) format
OUTPUT_FORMAT(default, big, little)
*/
OUTPUT_FORMAT ("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")
/* ENTRY() defines the symbol at which to begin executing code */
ENTRY(_start)
/* tell ld where to look for archive libraries */
/*SEARCH_DIR("/home/arp/stm/ctc/arm-eabi/lib")*/
/*SEARCH_DIR("/home/arp/stm/ccbuild/method2/install/arm-eabi/lib")*/
SEARCH_DIR("/home/arp/stm32dev-root/usrlol/arm-eabi/lib")
/*
MEMORY{} defines the memory regions of the target device,
and gives them an alias for use later in the linker script.
*/
/* stm32f105rb */
MEMORY
{
ram (rwx) : ORIGIN = 0x20000000, LENGTH = 32k
flash (rx) : ORIGIN = 0x08000000, LENGTH = 128k
option_bytes_rom (rx) : ORIGIN = 0x1FFFF800, LENGTH = 16
}
_sheap = _ebss + 4;
_sstack = _ebss + 4;
/*placed __stack_base__ trying to figure out
global variable overwrite issue
__stack_base__ = _ebss + 4;*/
_eheap = ORIGIN(ram) + LENGTH(ram) - 1;
_estack = ORIGIN(ram) + LENGTH(ram) - 1;
/* SECTIONS{} defines all the ELF sections we want to create */
SECTIONS
{
/*
set . to an initial value (0 here).
. (dot) is the location counter. New sections are placed at the
location pointed to by the location counter, and the location counter
is automatically moved ahead the length of the new section. It is important
to maintain alignment (not handled automatically by the location counter).
*/
. = SEGMENT_START("text-segment", 0);
/*isr_vector contains the interrupt vector.
isr_vector is read only (could be write too?).
isr_vector must appear at start of flash (USR),
address 0x0800 0000*/
.isr_vector :
{
. = ALIGN(4);
_sisr_vector = .;
*(.isr_vector)
_eisr_vector = .;
} >flash
/*text contains executable code.
text is read and execute.*/
.text :
{
. = ALIGN(4);
*(.text)
. = ALIGN(4);
*(.text.*)
} >flash
/*init contains constructor functions
called before entering main. used by crt (?).*/
.init :
{
. = ALIGN(4);
KEEP(*(.init))
} >flash
/*fini contains destructor functions
called after leaving main. used by crt (?).*/
.fini :
{
. = ALIGN(4);
KEEP(*(.fini))
} >flash
/* rodata contains read only data.*/
.rodata :
{
. = ALIGN(4);
*(.rodata)
/* sidata contains the initial values
for variables in the data section.
sidata is read only.*/
. = ALIGN(4);
_sidata = .;
} >flash
/*data contains all initalized variables.
data is read and write.
.data (NOLOAD) : AT(_sidata)*/
.data : AT(_sidata)
{
. = ALIGN(4);
_sdata = .;
*(.data)
_edata = .;
} >ram
/*bss contains unintialized variables.
bss is read and write.
.bss (NOLOAD) :*/
.bss :
{
. = ALIGN(4);
_sbss = .;
__bss_start__ = .;
*(.bss)
. = ALIGN(4);
/*COMMON is a special section containing
uninitialized data.
Example: (declared globally)
int temp; //this will appear in COMMON */
*(COMMON)
_ebss = .;
__bss_end__ = .;
} >ram AT>flash
. = ALIGN(4);
end = .;
/* remove the debugging information from the standard libraries */
DISCARD :
{
libc.a ( * )
libm.a ( * )
libgcc.a ( * )
}
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
}

Resources