This is related to GNU linker.If I have a section which is other than .text , .data or .bss how do I tell linker not to include that section in any of those segments.
Ex:
SECTIONS {
.text {}
.data {}
.bss {}
.sec_var {}
}
Actually in my case sec_var has some global variable I dont want it to be part of data segment but by default linker has this concept of orphan section so it tries to put that section in .data. Due to this the final binary size is grown the same .
I read in the GCC linker :
You can use :NONE to tell the linker to not put the section in any segment at all.
Anybody has used it or has any other method so that , sec_var is not placed under .data section ?
something like this,
MEMORY
{
bob : ORIGIN = 0x8000, LENGTH = 0x1000
ted : ORIGIN = 0xA000, LENGTH = 0x1000
}
SECTIONS
{
.text : { *(.text*) } > bob
.rodata : { *(.rodata*) } > bob
.bss : { *(.bss*) } > ted
}
I assume you dont really mean that you want .rodata in .text actually but perhaps you want .text and .rodata to be in the same chunk of memory space together...
Related
I am using GCC on a Cortex M0 from NXP.
I have a non-initialized buffer which needs to be placed at 512 byte boundary due to DMA access restrictions:
DMA_CH_DESCRIPTOR_T __attribute__ ((aligned (512))) Chip_DMA_Table[MAX_DMA_CHANNEL];
This will end up in .bss section, but of course, due to alignment, there will be some lost space before. I know that .bss starts (in my MCU) at 0x10000000 which is already 512 aligned.
So the big question is how can I force my buffer to be the first symbol in .bss ?
I already tried like this but it doesn't work
.bss : ALIGN(4)
{
_bss = .;
PROVIDE(__start_bss_RAM = .) ;
PROVIDE(__start_bss_SRAM = .) ;
drv_dma.o (.bss)
*(.bss*)
*(COMMON)
. = ALIGN(4) ;
_ebss = .;
PROVIDE(__end_bss_RAM = .) ;
PROVIDE(__end_bss_SRAM = .) ;
PROVIDE(end = .);
} > SRAM AT> SRAM
Note: I can see several potential resolves:
defining my own .bss_top for example, and modify my startup script to consider it as a separate .bss and initialize it.
defining a separate section BEFORE actual .bss and initialize my buffer from code somewhere
memset(...)
But I said it's worth to ask, maybe there is a simple linker catch on this one.
Thank you,
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
this is the problem:
When I link my scripts in C, using ld, when I generate elf32-i386 files as output format in ld, putting it as OUTPUT_FORMAT() in the ld script, I dont have any error, but if I try to put in this last OUTPUT_FORMAT() "binary" or try to output a file with .bin extension, I get a mixture of errors like:
kernel.o: In function `k_main':
kernel.c:(.text+0xe): undefined reference to `_GLOBAL_OFFSET_TABLE_'
kernelutils.o: In function `k_clear_screen':
kernelutils.c:(.text+0xc): undefined reference to `_GLOBAL_OFFSET_TABLE_'
kernelutils.o: In function `k_clear_screen_front':
kernelutils.c:(.text+0x56): undefined reference to `_GLOBAL_OFFSET_TABLE_'
kernelutils.o: In function `k_printf':
kernelutils.c:(.text+0xa0): undefined reference to `_GLOBAL_OFFSET_TABLE_'
kernelutils.o: In function `k_sleep_3sec':
kernelutils.c:(.text+0x152): undefined reference to `_GLOBAL_OFFSET_TABLE_'
kernelmalloc.o:kernelmalloc.c:(.text+0xc): more undefined references to `_GLOBAL_OFFSET_TABLE_' follow
This not only happens when compiling specific scripts, all scripts that try to use ld to link, or gcc since this calls ld, die in the attempt of get a binary with .bin extension.
When showing the symbols of one of the executables (kernel.o in the output of above) I see that the symbol _GLOBAL_OFFSET_TABLE_ isnt defined, and the most scary part, all the functions that returned error in the error output of above have their symbols removed, this is the nm output:
cristian#mymethodman:~/Desktop/kernel/0.0.3/Archivos$ nm kernel.o
U _GLOBAL_OFFSET_TABLE_
U k_clear_screen
U k_clear_screen_front
00000000 T k_main
U k_malloc
U k_printf
U k_sleep_3sec
00000000 T __x86.get_pc_thunk.bx
How I can solve this? I will leave the linker script below to ensure it isn a problem of the .ld file, with both "to get elf" and "to get binary" versions. Thanks in advance!
Ld scripts:
To get binary:
ENTRY(loader)
OUTPUT_FORMAT(binary)
SECTIONS {
/* The kernel will live at 3GB + 1MB in the virtual
address space, which will be mapped to 1MB in the
physical address space. */
. = 0xC0100000;
.text : AT(ADDR(.text) - 0xC0000000) {
*(.text)
*(.rodata*)
}
.data ALIGN (0x1000) : AT(ADDR(.data) - 0xC0000000) {
*(.data)
}
.bss : AT(ADDR(.bss) - 0xC0000000) {
_sbss = .;
*(COMMON)
*(.bss)
_ebss = .;
}
}
To get ELF:
ENTRY(loader)
OUTPUT_FORMAT(elf32-i386)
SECTIONS {
/* The kernel will live at 3GB + 1MB in the virtual
address space, which will be mapped to 1MB in the
physical address space. */
. = 0xC0100000;
.text : AT(ADDR(.text) - 0xC0000000) {
*(.text)
*(.rodata*)
}
.data ALIGN (0x1000) : AT(ADDR(.data) - 0xC0000000) {
*(.data)
}
.bss : AT(ADDR(.bss) - 0xC0000000) {
_sbss = .;
*(COMMON)
*(.bss)
_ebss = .;
}
}
As yo ucan see between both only changes the OUTPUT_FORMAT() line.
Your toolchain probably defaults to generating position-independent executables (PIE). Try compiling with gcc -fno-pie.
If you want to keep PIE for security reasons, you'll need a more complicated linker script and something that performs the initial relocation (such as a dynamic linker, but simpler constructions are possible as well).
I'm trying to switch to the GNU GCC compiler for our embedded system, but I'm having trouble linking the project as the memory layout of our chip is split:
RAM section 1: 0x10000-0x12FFF
RAM section 2: 0x18000-0x1BFFF
The data from our project can fit in section 1, but the data linked from the gcc libs doesn't. Map file extract:
.data 0x00012974 0x3c4 c:/tools/gnucr16_v1.1.3-elf/cr16-elf/bin/../lib/gcc/cr16-elf/4.5.1-GNUCR16_v1.1.3/../../../../cr16-elf/lib\libc.a(lib_a-impure.o)
0x00012974 _impure_ptr
.data 0x00012d7c 0x410 c:/tools/gnucr16_v1.1.3-elf/cr16-elf/bin/../lib/gcc/cr16-elf/4.5.1-GNUCR16_v1.1.3/../../../../cr16-elf/lib\libc.a(lib_a-mallocr.o)
0x00012d7c __malloc_av_
0x00013184 __malloc_trim_threshold
0x00013188 __malloc_sbrk_base
Is it possible to put the .data section from the libs in the 2nd section? I've tried different thing without success... Linker script extract:
MEMORY
{
SHARED1 : org = 0x10000, len = 0x3000
SHARED2 : org = 0x18000, len = 0x4000
}
SECTIONS
{
.data 0x12004 : { *(.data); } >SHARED1
.data2 0x19000 : { libc*(.data); } >SHARED2
}
SECTIONS
{
.section_name:
{
*lib_a-impure.o (.data); //That is the syntax to access sections of object files
} >SHARED1
}
More info here: http://www.embedded.com/design/mcus-processors-and-socs/4026080/Building-Bare-Metal-ARM-Systems-with-GNU-Part-3
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) }
}