I have some memory gaps in my .srec file after building my code in GHS MULTI. I have tried =fill and FILL() commands but there was no change. Can anyone suggest a solution. I need a solution that can be used in linker script.
Also can anyone give some complete working examples of =fill and FILL() Section attributes.
I have tried as following,
SECTIONS
{
.text CLEAR : FILL(0xFF) >.
or
.text FILL(0xFF) : >.
or
FILL(0xFF)
.text : > .
or
.text = 0xFF : > .
or
.text : > . =0xFF
or
.text : =0xFF > .
}
I have tried all the mentioned scenarios but there was no memory filled at required loaction
and when using clear some memory is getting framented at end address( First it was S315 in .srec but when used CLEAR it became S309)
Related
I'm trying to make a simple operating system kernel higher half. When using Grub as a bootloader as I am, there must also be some lower half (32 bit) code. Because I want to keep this 32 bit code as brief as possible, I do not want to write an ELF loader in it just to load the 64 bit code because that would be patently absurd (this is in fact the most common solution, but I would like to avoid it if possible).
I discovered that linker scripts allow load addresses that differ from virtual addresses. This is useful so that I can load the 64 bit sections to fit in a small binary and then use virtual memory to map the proper virtual addresses to the physical addresses they were loaded at. This works except that the low text section is not put in the text segment. The entry point, _start, is in this section.
I can't put the low text section (where _start resides) in the text segment unless I specify the text segment in a PHDRS command. Of course, using this command makes the linker decide to take a pass on generating the normally expected segments. When I do this too, the sections end up overlapping and I am not entirely sure why. I specify the segments in the order data, rodata, text, and the sections are the same, and yet their load memory addresses are assigned with rodata and data swapped and all three overlapping.
Here is my linker script:
ENTRY(_start)
PHDRS {
.low PT_LOAD FILEHDR PHDRS;
.data PT_LOAD;
.rodata PT_LOAD;
.text PT_LOAD;
}
SECTIONS {
. = 1M;
.data_low BLOCK(4K) : ALIGN(4K) {
*(.bss_low)
} : .low
.rodata_low BLOCK(4K) : ALIGN(4K) {
KEEP(*(.multiboot_low))
*(.rodata_low)
} : .low
.text_low BLOCK(4K) : ALIGN(4K) {
*(.text_low)
} : .low
.stack 0xC0000000 : AT(0x200000) ALIGN(4K) {
*(.bootstrap_stack)
} : .data
_LADD_ = LOADADDR(.stack) + SIZEOF(.stack);
.data BLOCK(4K) : AT(_LADD_) ALIGN(4K) {
*(COMMON)
*(.bss)
} : .data
_LADD_ += SIZEOF(.data);
.rodata BLOCK(4K) : AT(_LADD_) ALIGN(4K) {
*(.rodata)
} : .rodata
_LADD_ += SIZEOF(.rodata);
.text BLOCK(4K) : AT(_LADD_) ALIGN(4K) {
*(.text)
} : .text
}
I do not think the code is relevant to this error. When I link my object files using this linker script (additionally with -n --gc-sections), I get this error:
ld: section .data loaded at [0000000000200020,000000000020103f] overlaps section .rodata loaded at [0000000000200010,00000000002000d0]
ld: section .text loaded at [00000000002000d1,00000000002017ce] overlaps section .data loaded at [0000000000200020,000000000020103f]
The load memory addresses are in the order rodata, data, text, even though I expect they should be in the order data, rodata, text since the sections are specified in that order with AT specifiers with monotonically non decreasing positions (assuming the sections do not have negative size).
I should specify that I am using "segment" to mean one of the entries in the ELF program header (PHDRS in the linker script) and "section" to mean one of the entries in the ELF section header (SECTIONS in the linker script). I believe this to be correct terminology but acknowledge that I have an understanding of linker files and the ELF format that is limited at best. For whatever reason, Grub will not load an ELF file if its entry point is not in a segment.
Why indeed are the sections not in the order I expect them to be in, and how can I make them be? Thank you.
I have an embedded application that also has a bootloader, my goal is to be able to get the version of the bootloader and other information within the application, all information is constant, and thus I thought of placing them at the beginning of the bootloader code section, so the application can easily read the data which is allways going to be at the same address.
So far I have defined something like
const char bootloader_info[4] = {0x01,0x02,0x03,0x04};
and defining in the linker script
__bootloader_info = 0xD000 /*Where exactly should this line be placed?*/
However the variable ends placed in the data section...
What I have done now is to define a new section in the linker script and place it before the init code, although it works I think it is not the right way
const char __attribute__((section (".versioninfo"))) bootloader_info[4] = {0x01,0x02,0x03,0x04};
.
versioninfo (rx) : ORIGIN = 0xD000, LENGTH = 0x0000
rom (rx) : ORIGIN = 0xD000, LENGTH = 0x27B0
-------
.text :
{
. = ALIGN(2);
KEEP(*(.versioninfo)) /*info gets added at the beginning of .text*/
KEEP(*(.init .init.*))
KEEP...
What should be the right way of achieving this using a gcc toolchain, and why did the first method didn't work?
EDIT
I was not defining a section, I actually don't know what was that. To define a section it goes like this:
.versioninfo :
{
KEEP(*(.versioninfo))
} > versioninfo
Now it complains if the data is bigger than the section, so I guess it is better than before, I still would like to hear another aproaches or why the first method didn't work, thanks
You must define your section as follow:
_versioninfo_start_address = 0x0000D000;
.versioninfo _versioninfo_start_address :
{
KEEP(*(.versioninfo)) ;
} > // place here the region where to this section has to be stored
Then you can define your variable:
const char __attribute__((section (".versioninfo"))) bootloader_info[4] = {0x01,0x02,0x03,0x04}
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 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.