Using gcc arm-none-eabi 4_8 compiler, I'm getting a problem with my binary after linking. No errors but when I bring it up in debugger I never reach main. Tracing it through it appears the linker is not adding the epilog to the .init section for crt. This causes my code to run past .init into .rodata section and hitting hard fault on undefined instruction.
I'm stumped trying to figure out why this piece of code has this issue when very similar code using the same makefile doesn't. I know this is a broad question but what would be some reasons why the linker is not creating a good .init section?
Bad .map:
*(.init)
.init 0x00001cec 0x4 /usr/local/.../gcc/linux/4_8-2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/armv6-m/crti.o
0x00001cec _init
*(.fini)
.fini 0x00001cf0 0x4 /usr/local/.../gcc/linux/4_8-2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/armv6-m/crti.o
0x00001cf0 _fini
Good .map:
*(.init)
.init 0x00015c48 0x4 /usr/local/.../gcc/linux/4_6-2012q4/bin/../lib/gcc/arm-none-eabi/4.6.2/armv6-m/crti.o
0x00015c48 _init
.init 0x00015c4c 0x8 /usr/local/.../gcc/linux/4_6-2012q4/bin/../lib/gcc/arm-none-eabi/4.6.2/armv6-m/crtn.o
*(.fini)
.fini 0x00015c54 0x4 /usr/local/.../gcc/linux/4_6-2012q4/bin/../lib/gcc/arm-none-eabi/4.6.2/armv6-m/crti.o
0x00015c54 _fini
.fini 0x00015c58 0x8 /usr/local/.../gcc/linux/4_6-2012q4/bin/../lib/gcc/arm-none-eabi/4.6.2/armv6-m/crtn.o
Turns out the issue is an out of date linker command file.
Was missing:
KEEP(*(.init))
KEEP(*(.fini))
Related
In an embedded environment i want to convey information about a special part
of memory (start address and length) from the build process to the program
loader. My idea is to let linker create an output section similar to .bss,
i.e. that section should not occupy space in the elf file and should have flags
like the .bss section. I came to this idea since i am already using a customized
linker script.
When processing the elf file, my costumized loader could recognize this section
by a magic name and use the sections size and VMA as the description for the
special part of memory.
When i say it should be similar to .bss, i mean the output of objdump -h
should be similar to this:
Sections:
Idx Name Size VMA LMA File off Algn
...
7 .bss 00000204 10204c9c 10204c9c 00005c40 2**2
ALLOC
...
I guess it is important that here only the flag ALLOC is present, but not LOAD
or CONTENTS.
Can this be achieved with some instructions in the linker script?
If so, what are those instructions?
Browsing through similar questions here at stackoverflow and the ld documentation showed that the solution is quite simple:
.special_start = 0x20000000;
.special_size = 0x10000000;
.special .special_start (NOLOAD) :
{
. = . + .special_size;
}
gives this ouput from objdump -h:
Sections:
Idx Name Size VMA LMA File off Algn
...
6 .sbss 0000005c 10204c40 10204c40 00005c40 2**2
ALLOC, SMALL_DATA
7 .bss 00000204 10204c9c 10204c9c 00005c40 2**2
ALLOC
8 .special 10000000 20000000 20000000 00006000 2**0
ALLOC
...
I'm trying to write an executable where the .text section is located in a specific location. I wrote the following linker script:
base_address = 0x123456789AB;
SECTIONS
{
ENTRY(_start)
. = base_address;
.text : { *(.text); }
}
However when I look at the memory mapping of the resulting executable, I see:
12345600000-12345679000 r-xp 00000000 08:01 1 /path/to/executable
It is obvious why the section would be aligned to 0x1000, that's page size, but where does 0x100000 come from?
Now the interesting part is that this only happens when I disable build ids with -Wl,--build-id=none, or when I enable them and try to stuff the .note.gnu.build-id section right after .text.
Have a look at the generated map file. It's possible that some of your input .text sections also have their own alignment requirements.
Until recently I thought that section names generally have to start with a dot .. However, When studying the sample linker file of my bare-metal-C-IDE, I noticed that there seems to be one exception: The section COMMON.
.text :
{
KEEP(*(.isr_vector))
*(.text*)
KEEP(*(.init))
KEEP(*(.fini))
/* .ctors */
*crtbegin.o(.ctors)
*crtbegin?.o(.ctors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
*(SORT(.ctors.*))
*(.ctors)
/* .dtors */
*crtbegin.o(.dtors)
*crtbegin?.o(.dtors)
*(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
*(SORT(.dtors.*))
*(.dtors)
*(.rodata*)
KEEP(*(.eh_frame*))
} > ROM
.bss (NOLOAD):
{
*(.bss*)
*(COMMON)
} > RAM
This led me to the conclusion that beginning the section names with . seems to merely be a convention rather than a requirement.
So, my questions are:
What is the reason for starting section names with a dot? I suppose there there was a (perhaps historical?) reason for this convention to be established.
Why was an exception made for COMMON?
Why do usually output sections have the same name as input sections? It was rather confusing for me that there is actually a non-.bss sections included in my .bss output section. Same goes with the .text section. There are plenty of non-.text sections included in my .text output section. Why isn't it common just to give them their own output section? Wouldn't that be much more logical?
Are there any real reasons behind this, or is it just the way it is?
I'm wring a toy OS for my raspberry pi and trying to setup the MMU. I want to split the virtual memory between 3G:1G, so I think my code should be linked at 0xC0008000, while loaded to 0x8000 on execution. (The 0x8000 is the address the current bootloaders expect to find the kernel - since they are built for linux).
I think everything is setup fine by poking around with objdump, but it doesn't work. After some debugging with qemu, I think the bootloader doesn't find my code at all.
I believe the problem is with my linkscript, since the kernel starts fine if I move the starting code into its own section that's both linked and loaded at 0x8000.
I've extracted out the script and the minimal code. As following,
$ cat kernel.ld
ENTRY(_start)
SECTIONS
{
/* must == KERNLINK */
. = 0xC0008000;
.text : AT(0x8000) {
*(.text)
}
.bss : {
*(.bss)
}
.data : {
*(.data)
}
.rodata : {
*(.rodata)
}
}
-
$ cat source/entry.S
#include "mem.h"
.globl _start
_start = V2P(entry)
.globl entry
entry:
loop$:
b loop$
(The "b loop$" won't work since it's generated as "b·c0008000" instead of using a relative branch. But never mind that part, the problem is it never reaches entry).
$ cat source/mem.h
#define KERNLOAD 0x8000
#define KERNBASE 0xC0000000
#define KERNLINK (KERNBASE+KERNLOAD)
#define V2P(va) ((va) - KERNBASE)
Those are the only three source files. There should be nothing interesting in the Makefile, but the output from make is,
$ make
arm-none-eabi-gcc -g -Wall -c -o build/entry.o source/entry.S
arm-none-eabi-ld --no-undefined -T kernel.ld build/entry.o -Map kernel.map -o build/output.elf
arm-none-eabi-objcopy build/output.elf -O binary kernel.img
And objdump,
$ arm-none-eabi-objdump -h build/output.elf
build/output.elf: file format elf32-littlearm
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000004 c0008000 00008000 00008000 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .ARM.attributes 00000014 00000000 00000000 00008004 2**0
CONTENTS, READONLY
2 .debug_line 0000003c 00000000 00000000 00008018 2**0
CONTENTS, READONLY, DEBUGGING
3 .debug_info 00000054 00000000 00000000 00008054 2**0
CONTENTS, READONLY, DEBUGGING
4 .debug_abbrev 00000014 00000000 00000000 000080a8 2**0
CONTENTS, READONLY, DEBUGGING
5 .debug_aranges 00000020 00000000 00000000 000080c0 2**3
CONTENTS, READONLY, DEBUGGING
I start to believe I overlooked some obvious yet precious details.
==== update ====
As noted in my own answer below, the confusion is caused by debugging in qemu. The breakpoints are set by virtual addresses. "b entry" doesn't work, because gdb is thinking about virtual address while MMU hasn't been enabled and we're running by physical address.
So before MMU is enabled, we have to use "b *0x8000". This sets a breakpoint that's correctly hit. GDB seems still confused though, since it doesn't show any debugging info (no source code, like 0x00008004 in ?? ()). That's not a big issue since I have the listing produced by "objdump -D".
After MMU is enabled and we branch to main, gdb works perfectly. The crux is to jump to a virtual address, using an absolute branch. b/bl would issue relative jumps. So I use ldr pc =main. bx works too.
Finally solved it...
The code and the linkscript don't have problems. It's just that debugging doesn't seem to work on the qemu I used. It does work when VMA==LMA, but in this case the kernel already runs and qemu doesn't know about it. Or, the breakpoint is lost and never caught by gdb.
Anyway, by starting afresh and adding bits one by one, I have it working on my rpi (real hardware), and then it works on qemu too (gdb still won't catch the breakpoint).
So my question should really be how to debug such a scenario using qemu/gdb.
(My original problem is solved by changing the "domain" permission to "manager", instead of using "client". Yeah I know this is probably temporary and I should set a variable elsewhere).
I am a bit confused by the results I am getting when I use my toolchain's (Yagarto and codesourcery) size utility. it is reporting that I am using 0 bytes in the data section. see below
$ arm-none-eabi-size.exe rest-server-example.crazy-horse.elf
text data bss dec hex filename
79364 0 34288 113652 1bbf4 rest-server-example.crazy-horse.elf
I know my code is using and initializing static RAM variables to values other than 0.
interestingly enough when I pass the size tool directly some of the object files that are getting linked I see .data section being reported
example:
text data bss dec hex filename
1648 0 20 1668 684 obj_crazy-horse/uip-nd6.o
200 12 2652 2864 b30 obj_crazy-horse/uip-packetqueue.o
12 0 0 12 c obj_crazy-horse/uip-split.o
1816 24 48 1888 760 obj_crazy-horse/usb-core.o
284 0 0 284 11c obj_crazy-horse/usb-interrupt.o
2064 20 188 2272 8e0 obj_crazy-horse/xmac.o
Why would the elf file report 0 for the .data section when the object files that make it are reporting non-zero values?
FYI I am working on embedded software for a AT91SAM7x256 Micro
edit:
adding the CFLAGS and LDFLAGS
CFLAGS += -O -DRUN_AS_SYSTEM -DROM_RUN -ffunction-sections
LDFLAGS += -L $(CPU_DIRECTORY) -T $(LINKERSCRIPT) -nostartfiles -Wl,-Map,$(TARGET).map
edit #2:
from the object dump we can clearly see that the .data section has data assigned to it but the size utility is not picking it up for some reason
objdump link
All I am looking for is to get an exact usage of my RAM I am not trying to figure out whether one of my variables was optimized out.
edit 3:
more information showing that the size utility does see something in the .data section
$ arm-none-eabi-size.exe -A -t -x rest-server-example.crazy-horse.elf
rest-server-example.crazy-horse.elf :
section size addr
.vectrom 0x34 0x100000
.text 0x10fc8 0x100038
.rodata 0x149c 0x111000
.ARM.extab 0x30 0x11249c
.ARM.exidx 0xe0 0x1124cc
.data 0x1028 0x200000
.bss 0x7bec 0x201028
.stack 0xa08 0x20f5f8
.ARM.attributes 0x32 0x0
.comment 0x11 0x0
.debug_aranges 0xc68 0x0
.debug_info 0x2b87e 0x0
.debug_abbrev 0x960b 0x0
.debug_line 0x9bcb 0x0
.debug_frame 0x4918 0x0
.debug_str 0x831d 0x0
.debug_loc 0x13fad 0x0
.debug_ranges 0x620 0x0
Total 0x7c4c5
My interpretation would be that the linker script creates a single loadable section, which contains the initial values of the data section and a piece of startup code that copies the data to the uninitialized data section.
This is necessary if you want to have a single image file that can be run from read-only memory, as there is no ELF loader in front then that would perform that copy for you.
Normally, this is only done in the section to segment mapping (i.e. the output sections are arranged in the linker script using the > section placement command) rather than by mapping the input section twice, but that is certainly possible as well.
The usage numbers are quite accurate: the text size is the amount of Flash space needed, the BSS size is the amount of RAM needed. Initialized data is counted twice, once for the initial data in Flash, and once for the modifiable data in RAM.
Your .data section have the CODE attribute set, and this confuses "arm-none-eabi-size". The size of the .data section is incorrectly added to the total text size instead of the data size.
My guess is that you have some code that is stored in flash but is copied to ram at run time such as a fast interrupt handler or flash reprogramming that must run from RAM. This will set the CODE attribute for the data segment, and "size" believes that all of .data is text.