I was inspecting ELF binary for the code mentioned below.
I compiled it on gcc 7.4.0 on Ubuntu x86_64 system in Virtual Box as :
gcc -g scratch1.c -o scratch1.out
#include <stdio.h>
void do_stuff(int my_arg){
int my_local = my_arg + 2;
int i;
for (i = 0; i < my_local; ++i) printf("i = %d\n", i);
}
int main(){
do_stuff(2);
return 0;
}
However when I tried to refer to .debug_loc section, it was empty.
objdump --dwarf=loc scratch1.out
scratch1.out: file format elf64-x86-64
Although, I do see some other debug_ sections
[26] .debug_aranges PROGBITS 0000000000000000 0000103b
0000000000000030 0000000000000000 0 0 1
[27] .debug_info PROGBITS 0000000000000000 0000106b
000000000000035f 0000000000000000 0 0 1
[28] .debug_abbrev PROGBITS 0000000000000000 000013ca
0000000000000125 0000000000000000 0 0 1
[29] .debug_line PROGBITS 0000000000000000 000014ef
00000000000000e6 0000000000000000 0 0 1
[30] .debug_str PROGBITS 0000000000000000 000015d5
00000000000002b5 0000000000000001 MS 0 0 1
Need your help why this section is missing.
Need your help why this section is missing.
The .debug_loc section contains DW_AT_location lists, usually emitted only for optimized code.
Since you compiled without optimization, the compiler didn't emit this section. Try building with:
gcc -g -O3 scratch1.c -o scratch1.out
Here is what I see with gcc 8.3.0:
$ gcc -g scratch.c && readelf -WS a.out | grep debug_loc
# no output
$ gcc -g scratch.c -O3 && readelf -WS a.out | grep debug_loc
[32] .debug_loc PROGBITS 0000000000000000 0039db 000230 00 0 0 1
Related
I've been looking at loading a elf file into the memory, but in the process, I've found out that there is huge chunk of unused space in the file.
This is the elf file i got https://cyao.page/kernel.elf (~2.1Mib) and this is my linker script:
ENTRY(start)
OUTPUT_FORMAT(elf64-x86-64)
SECTIONS {
. = 0xC00000;
phys = .;
.text ALIGN(0x1000): {
code = .;
*(.text)
. = ALIGN(0x1000);
}
.rodata ALIGN(0x1000): {
*(.rodata*)
. = ALIGN(0x1000);
}
.data ALIGN(0x1000): {
data = .;
*(.data)
. = ALIGN(0x1000);
}
.bss ALIGN(0x1000): {
bss = .;
*(.bss)
. = ALIGN(0x1000);
}
end = .; _end = .; __end = .;
/DISCARD/ : {
*(.comment)
*(.note.gnu.build-id)
}
}
When I you look at the p_offset in the program header (in adress 0x40), you will see that the offset is 0x200000, and in all the section tables, all their's offset are bigger then 0x200000
The same goes with x86_64-elf-objdump
cdcontents/!kernel.bin: file format elf64-x86-64
cdcontents/!kernel.bin
architecture: i386:x86-64, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x000000000c000000
Program Header:
LOAD off 0x0000000000200000 vaddr 0x000000000c000000 paddr 0x000000000c000000 align 2**12
filesz 0x0000000000009384 memsz 0x000000000000b000 flags rwx
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00006000 000000000c000000 000000000c000000 00200000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .text.startup 00000094 000000000c006000 000000000c006000 00206000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .data 00001000 000000000c007000 000000000c007000 00207000 2**5
CONTENTS, ALLOC, LOAD, DATA
3 .rodata 00001000 000000000c008000 000000000c008000 00208000 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .eh_frame 00000384 000000000c009000 000000000c009000 00209000 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .bss 00001000 000000000c00a000 000000000c00a000 00209384 2**5
ALLOC
6 .debug_info 000035be 0000000000000000 0000000000000000 00209384 2**0
CONTENTS, READONLY, DEBUGGING, OCTETS
7 .debug_abbrev 00000db5 0000000000000000 0000000000000000 0020c942 2**0
CONTENTS, READONLY, DEBUGGING, OCTETS
8 .debug_loclists 00006865 0000000000000000 0000000000000000 0020d6f7 2**0
CONTENTS, READONLY, DEBUGGING, OCTETS
9 .debug_aranges 000001b0 0000000000000000 0000000000000000 00213f5c 2**0
CONTENTS, READONLY, DEBUGGING, OCTETS
10 .debug_rnglists 0000059a 0000000000000000 0000000000000000 0021410c 2**0
CONTENTS, READONLY, DEBUGGING, OCTETS
11 .debug_line 00002046 0000000000000000 0000000000000000 002146a6 2**0
CONTENTS, READONLY, DEBUGGING, OCTETS
12 .debug_str 000005f3 0000000000000000 0000000000000000 002166ec 2**0
CONTENTS, READONLY, DEBUGGING, OCTETS
13 .debug_line_str 0000015c 0000000000000000 0000000000000000 00216cdf 2**0
CONTENTS, READONLY, DEBUGGING, OCTETS
It shouldn't be the alignment since its aligned to 0x1000, not 0x200000.
Now the problem is: What is the space 0x78 (end of the headders) to 0x200000 used for? thats a whole 2 Mib wasted! (yea it's a lot compared to that i only reserved 512 Mib of memory for my kernel)
Here is a reduced version of my makefile:
C_SOURCES = $(wildcard lib/*.c) $(wildcard libc/*.c)
HEADERS = $(wildcard include/*.h) $(wildcard include/kernel/*.h)
OBJ = ${C_SOURCES:.c=.o} lib/idtr.o asmlib/memmove.o asmlib/memcpy.o asmlib/unalignedisfaster.o asmlib/instrset.o \
asmlib/cputype.o asmlib/cachesize64.o
CFLAGS = -O2 -std=gnu11 -g -static -Wall -Wextra -Werror -Wno-unused-function \
-Wno-unused-parameter -nostartfiles -Wno-unused-but-set-variable \
-Wstrict-prototypes -Wpointer-arith -Wcast-align -Wwrite-strings -Wshadow \
-fno-stack-protector -Wundef -nostdlib -fno-builtin -nodefaultlibs \
-fms-extensions -ffreestanding -mcmodel=large -fverbose-asm -nostartfiles \
-mno-red-zone -mno-mmx -mno-sse -mno-sse2 -Iinclude -Wfloat-equal
all: kernel.bin
kernel.bin: lib/kernel_start.o ${OBJ}
x86_64-elf-gcc -o $# $^ -T link.ld -ffreestanding -O2 -nostdlib -lgcc
%.o: %.c
x86_64-elf-gcc ${CFLAGS} -c $< -o $#
%.o: %.asm
nasm $< -f elf64 -o $#
for the full makefile you can look here https://github.com/cheyao/AchieveOS/blob/master/Makefile
Thanks to Michal Petch in their comment, the solution is to add -z max-page-size=0x1000 to the compiler flags
I have an ELF file which we then convert to a binary format:
arm-none-eabi-objcopy -O binary MyElfFile.elf MyBinFile.bin
The ELF file is just under 300KB, but the binary output file is 446-times larger: 134000KB, or 130MB! How is this possible when the whole point of a binary is to remove symbols and section tables and debug info?
Looking at Reddit and SO it looks like the binary image should be smaller than the ELF, not larger.
so.s
b .
.section .data
.word 0x12345678
arm-none-eabi-as so.s -o so.o
arm-none-eabi-objdump -D so.o
so.o: file format elf32-littlearm
Disassembly of section .text:
00000000 <.text>:
0: eafffffe b 0 <.text>
Disassembly of section .data:
00000000 <.data>:
0: 12345678 eorsne r5, r4, #120, 12 ; 0x78
arm-none-eabi-readelf -a so.o
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 000004 00 AX 0 0 4
[ 2] .data PROGBITS 00000000 000038 000004 00 WA 0 0 1
[ 3] .bss NOBITS 00000000 00003c 000000 00 WA 0 0 1
[ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 00003c 000012 00 0 0 1
[ 5] .symtab SYMTAB 00000000 000050 000060 10 6 6 4
[ 6] .strtab STRTAB 00000000 0000b0 000004 00 0 0 1
[ 7] .shstrtab STRTAB 00000000 0000b4 00003c 00 0 0 1
so my "binary" has 8 bytes total. In two sections.
-rw-rw-r-- 1 oldtimer oldtimer 560 Oct 12 16:32 so.o
8 bytes relative to 560 for the object.
Link it.
MEMORY
{
one : ORIGIN = 0x00001000, LENGTH = 0x1000
two : ORIGIN = 0x00002000, LENGTH = 0x1000
}
SECTIONS
{
.text : { (.text) } > one
.data : { (.data) } > two
}
arm-none-eabi-ld -T so.ld so.o -o so.elf
arm-none-eabi-objdump -D so.elf
so.elf: file format elf32-littlearm
Disassembly of section .text:
00001000 <.text>:
1000: eafffffe b 1000 <.text>
Disassembly of section .data:
00002000 <.data>:
2000: 12345678 eorsne r5, r4, #120, 12 ; 0x7800000
arm-none-eabi-readelf -a so.elf
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00001000 001000 000004 00 AX 0 0 4
[ 2] .data PROGBITS 00002000 002000 000004 00 WA 0 0 1
[ 3] .ARM.attributes ARM_ATTRIBUTES 00000000 002004 000012 00 0 0 1
[ 4] .symtab SYMTAB 00000000 002018 000070 10 5 7 4
[ 5] .strtab STRTAB 00000000 002088 00000c 00 0 0 1
[ 6] .shstrtab STRTAB 00000000 002094 000037 00 0 0 1
Now...we need 4 bytes at 0x1000 and 4 bytes at 0x2000, if we want to use the -O binary objcopy that means it is going to take the entire memory space and start the file with the lowest address thing and end with the highest address thing. With this link the lowest thing is 0x1000 and highest is 0x2003, a total span of 0x1004 bytes:
arm-none-eabi-objcopy -O binary so.elf so.bin
ls -al so.bin
-rwxrwxr-x 1 oldtimer oldtimer 4100 Oct 12 16:40 so.bin
4100 = 0x1004 bytes
hexdump -C so.bin
00000000 fe ff ff ea 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001000 78 56 34 12 |xV4.|
00001004
The assumption here is the user knows that the base address is 0x1000 as there is no address info in the file format. And that this is a continuous memory image so that the four bytes also land at 0x2000. So -O binary pads the file to fill everything in.
If I change to this
MEMORY
{
one : ORIGIN = 0x00000000, LENGTH = 0x1000
two : ORIGIN = 0x10000000, LENGTH = 0x1000
}
SECTIONS
{
.text : { *(.text*) } > one
.data : { *(.data*) } > two
}
You can easily see where this is headed.
ls -al so.bin
-rwxrwxr-x 1 oldtimer oldtimer 268435460 Oct 12 16:43 so.bin
So my elf does not change size, but the -O binary format is 0x10000004 bytes in size, there are only 8 bytes I care about but the nature of objcopy -O binary has to pad the middle.
Since the sizes and spaces of things vary specific to your project and your linker script, no generic statements can be made relative to the size of the elf file and the size of an -O binary file.
ls -al so.elf
-rwxrwxr-x 1 oldtimer oldtimer 131556 Oct 12 16:49 so.elf
arm-none-eabi-strip so.elf
ls -al so.elf
-rwxrwxr-x 1 oldtimer oldtimer 131336 Oct 12 16:50 so.elf
arm-none-eabi-as -g so.s -o so.o
ls -al so.o
-rw-rw-r-- 1 oldtimer oldtimer 1300 Oct 12 16:51 so.o
arm-none-eabi-ld -T so.ld so.o -o so.elf
ls -al so.elf
-rwxrwxr-x 1 oldtimer oldtimer 132088 Oct 12 16:51 so.elf
arm-none-eabi-strip so.elf
ls -al so.elf
-rwxrwxr-x 1 oldtimer oldtimer 131336 Oct 12 16:52 so.elf
The elf binary file format does not have absolute rules on content, the consumer of the file can have rule as to what you have to put where, if any specific names of items have to be there, etc. It is a somewhat open file format, it is a container like a cardboard box, and you can fill it to some extent how you like. You cannot fit a cruise ship in it, but you can put books or toys and you can choose how you put the books or toys in it sometimes.
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 010000 000004 00 AX 0 0 4
[ 2] .data PROGBITS 10000000 020000 000004 00 WA 0 0 1
[ 3] .ARM.attributes ARM_ATTRIBUTES 00000000 020004 000012 00 0 0 1
[ 4] .shstrtab STRTAB 00000000 020016 000027 00 0 0 1
Even after stripping there is still extra stuff there, if you study the file format you have a header, relatively small with number of program headers and number of section headers and then that many program headers and that many section headers. Depending on the consumer(s) of the file you may for example only need the main header stuff and two program headers in this case and that is it, a much smaller file (as you can see with the object version of the file).
arm-none-eabi-as so.s -o so.o
ls -al so.o
-rw-rw-r-- 1 oldtimer oldtimer 560 Oct 12 16:57 so.o
arm-none-eabi-strip so.o
ls -al so.o
-rw-rw-r-- 1 oldtimer oldtimer 364 Oct 12 16:57 so.o
readelf that
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 6
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 000004 00 AX 0 0 4
[ 2] .data PROGBITS 00000000 000038 000004 00 WA 0 0 1
[ 3] .bss NOBITS 00000000 00003c 000000 00 WA 0 0 1
[ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 00003c 000012 00 0 0 1
[ 5] .shstrtab STRTAB 00000000 00004e 00002c 00 0 0 1
Extra section headers we don't need which maybe can be removed in the linker script. But I assume for some consumers all you would need is the two program headers
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 2
Plus the 8 bytes and any padding for this file format.
Also note
arm-none-eabi-objcopy --only-section=.text -O binary so.elf text.bin
arm-none-eabi-objcopy --only-section=.data -O binary so.elf data.bin
ls -al text.bin
-rwxrwxr-x 1 oldtimer oldtimer 4 Oct 12 17:03 text.bin
ls -al data.bin
-rwxrwxr-x 1 oldtimer oldtimer 4 Oct 12 17:03 data.bin
hexdump -C text.bin
00000000 fe ff ff ea |....|
00000004
hexdump -C data.bin
00000000 78 56 34 12 |xV4.|
00000004
When we covert a .elf file generated from arm-gcc toolchain to .bin file, its size increases from 40kB to 1.1Gb.
For conversion we are using :
./arm-none-eabi-objcopy -O binary test.elf test.bin
It might be because of non-contiguous memory map and the gaps between the memory regions are just being filled with zeros.
What options can be used in objcopy? Or is there any other method to convert?
Following is the elf information:
Tag_CPU_name: "Cortex-M7" Tag_CPU_arch: v7E-M
Tag_CPU_arch_profile: Microcontroller Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: FPv5/FP-D16 for ARMv8 Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: small Tag_ABI_VFP_args: VFP registers
Tag_ABI_optimization_goals: Aggressive Debug
Tag_CPU_unaligned_access: v6
The listing of sections contained in the ELF file is - there are 25 section headers, starting at offset 0x3e982c:
Section Headers:
[Nr] Name
Type Addr Off Size ES Lk Inf Al
Flags
[ 0]
NULL 00000000 000000 000000 00 0 0 0
[00000000]:
[ 1] .flash_config
PROGBITS 60000000 020000 000200 00 0 0 4
[00000002]: ALLOC
[ 2] .ivt
PROGBITS 60001000 021000 000030 00 0 0 4
[00000002]: ALLOC
[ 3] .interrupts
PROGBITS 60002000 022000 000400 00 0 0 4
[00000002]: ALLOC
[ 4] .text
PROGBITS 60002400 022400 312008 00 0 0 16
[00000006]: ALLOC, EXEC
[ 5] .ARM
ARM_EXIDX 60314408 334408 000008 00 4 0 4
[00000082]: ALLOC, LINK ORDER
[ 6] .init_array
INIT_ARRAY 60314410 334410 000004 04 0 0 4
[00000003]: WRITE, ALLOC
[ 7] .fini_array
FINI_ARRAY 60314414 334414 000004 04 0 0 4
[00000003]: WRITE, ALLOC
[ 8] .interrupts_ram
PROGBITS 20200000 380000 000000 00 0 0 1
[00000001]: WRITE
[ 9] .data
PROGBITS 20200000 340000 014bd0 00 0 0 8
[00000007]: WRITE, ALLOC, EXEC
[10] .ncache.init
PROGBITS 20214bd0 354bd0 011520 00 0 0 4
[00000003]: WRITE, ALLOC
[11] .ncache
NOBITS 20226100 366100 0021d8 00 0 0 64
[00000003]: WRITE, ALLOC
[12] .bss
NOBITS 20229000 369000 077ce8 00 0 0 4096
[00000003]: WRITE, ALLOC
[13] .NVM_TABLE
PROGBITS 20000000 010000 00000c 00 0 0 4
[00000003]: WRITE, ALLOC
[14] .heap
NOBITS 2000000c 01000c 000404 00 0 0 1
[00000003]: WRITE, ALLOC
[15] .stack
NOBITS 20000410 01000c 000400 00 0 0 1
[00000003]: WRITE, ALLOC
[16] .NVM
PROGBITS 60570000 370000 010000 00 0 0 1
[00000003]: WRITE, ALLOC
[17] .ARM.attributes
ARM_ATTRIBUTES 00000000 380000 00002e 00 0 0 1
[00000000]:
[18] .comment
PROGBITS 00000000 38002e 00004c 01 0 0 1
[00000030]: MERGE, STRINGS
[19] .debug_frame
PROGBITS 00000000 38007c 001174 00 0 0 4
[00000000]:
[20] .stab
PROGBITS 00000000 3811f0 0000cc 0c 21 0 4
[00000000]:
[21] .stabstr
STRTAB 00000000 3812bc 0001b9 00 0 0 1
[00000000]:
[22] .symtab
SYMTAB 00000000 381478 046620 10 23 13540 4
[00000000]:
[23] .strtab
STRTAB 00000000 3c7a98 021cb2 00 0 0 1
[00000000]:
[24] .shstrtab
STRTAB 00000000 3e974a 0000df 00 0 0 1
[00000000]:
so.s
.thumb
nop
.data
.word 0x11223344
so.ld
MEMORY
{
one : ORIGIN = 0x00000000, LENGTH = 0x1000
two : ORIGIN = 0x20000000, LENGTH = 0x1000
}
SECTIONS
{
.text : { *(.text*) } > one
.data : { *(.data*) } > two
}
build
arm-none-eabi-as so.s -o so.o
arm-none-eabi-ld -T so.ld so.o -o so.elf
arm-none-eabi-objdump -D so.elf
arm-none-eabi-objcopy -O binary so.elf so.bin
536870916 Apr 28 15:23 so.bin
131556 Apr 28 15:23 so.elf
from readelf
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x010000 0x00000000 0x00000000 0x00002 0x00002 R E 0x10000
LOAD 0x020000 0x20000000 0x20000000 0x00004 0x00004 RW 0x10000
now so.ld
MEMORY
{
one : ORIGIN = 0x00000000, LENGTH = 0x1000
two : ORIGIN = 0x20000000, LENGTH = 0x1000
}
SECTIONS
{
.text : { *(.text*) } > one
.bss : { *(.bss*) } > two AT > one
.data : { *(.data*) } > two AT > one
}
it is actually .bss that is doing the magic here, that is some other research project, I could have started with a .C file but tried asm...
6 Apr 28 15:30 so.bin
131556 Apr 28 15:29 so.elf
and now it is the possibly desired 6 bytes without padding, but of course you have to add labels in the linker script and use them in the bootstrap code to move .data to ram and zero .bss and such.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x010000 0x00000000 0x00000000 0x00002 0x00002 R E 0x10000
LOAD 0x020000 0x20000000 0x00000002 0x00004 0x00004 RW 0x10000
Notice how now the physical is in the 0x00000000 range, it was tacked at the end of the space used by .text. but the virtual (where it wants to live, needs to live, do not think mmu here or anything like that just think the two address spaces (on flash and where it is used)).
In case this is not clear:
MEMORY
{
one : ORIGIN = 0xE0000000, LENGTH = 0x1000
two : ORIGIN = 0xE0000100, LENGTH = 0x1000
}
SECTIONS
{
.text : { *(.text*) } > one
.data : { *(.data*) } > two
}
260 Apr 28 15:46 so.bin
66276 Apr 28 15:46 so.elf
objcopy starts the binary file at the lowest defined (loadable) address and not zero...The file size is the difference, inclusive, of the lowest addressed byte and the highest.
I have same problem with you, and I finally find it's not objcopy's problem, I just change my compile command and it work. At first, I just use gcc only, and I face the problem like you, then I try use gcc -c and ld(just separate this two steps), and the file is smaller in magically. so maybe the problem is in gcc, not objcopy. you can try like me, and my compile command now is:
gcc-4.8 -g -e boot_start -fno-builtin -Ttext 0x7C00 -nostdlib -m32 -c bootloader.S -o bootasm.o
gcc-4.8 -Os -fno-builtin -nostdlib -m32 -c bootloader.c -o bootc.o
ld -m elf_i386 -e boot_start -nostdlib -N bootasm.o bootc.o -o bootloader.o
objcopy -S -O binary bootloader.o bootloader.bin
hope it can help you...
Here is the output of readelf -a test.elf
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 0000000040000000 010000 00007c 00 AX 0 0 8
[ 2] .rodata PROGBITS 0000000040000080 010080 000016 00 A 0 0 8
[ 3] .debug_info PROGBITS 0000000000000000 010096 0000af 00 0 0 1
[ 4] .debug_abbrev PROGBITS 0000000000000000 010145 000086 00 0 0 1
[ 5] .debug_aranges PROGBITS 0000000000000000 0101cb 000030 00 0 0 1
The .text section starts at 0x40000000. With debugger, I could see the PC value is starting from 0x40000000, and the code there is the startup.s which is meant to be there. But I'm not sure why the value 'Off' for that section is 0x10000. What does this 'Off' value mean? Isn't Address and Size enough for a section?
The Offset field denotes the location of that segment in the file. Here the .text segment starts at location 0x10000 and is 0x7c bytes long, then next segment .rodata starts at 0x10080 etc.
I am using the nestedvm package, which includes a patched Gnu gcc compiler. For this package, callable user methods/functions have to annotated with __attribute__((section(".text"))), as shown in the C example below.
void echo(const char *string, int count) __attribute__((section(".text")));
void echo(const char *string, int count) {
int i;
for(i=0;i<count;i++)
printf("%d: %s\n",i,string);
}
I don't know about the inner workings of the patched compiler, but without this annotation, the user function is not visible to outside callers.
If using gfortran, how can I accomplish this annotation for Fortran subroutines and functions? Could this be done with a linker script file? I could write a C wrapper to the Fortran functions, but would like to avoid this if possible.
** UPDATE 1 **
Using nm to investigate the .o file sheds some light on the issue...a C method without the attribute looks like the suckram function (which is not callable in nestedvm), while the echo function has the attribute and is callable in nestedvm:
Name Value Class Type Size Line Section
suckram |00000000| T | FUNC|00000078| |.text.suckram
echo |00000200| T | FUNC|00000074| |.text
The test1 subroutine in my Fortran object looks like the suckram method without the attribute:
test1_ |00000000| T | FUNC|00000080| |.text.test1_
According to some nestedvm documentation I found, in order for a user function to be callable in nestedvm, it has to end up in the .text section.
** UPDATE 2 **
A link command line is below. It is too long to put in a comment. I removed some of the many .o files (…)
mips-unknown-elf-gfortran -O3 -mmemcpy -ffunction-sections -fdata-sections -falign-functions=512 -fno-rename-registers -fno-schedule-insns -fno-delayed-branch -march=mips1 -specs=/home/jhuber/Documents/source/nestedvm/upstream/install/mips-unknown-elf/lib/crt0-override.spec -I. -Wall -Wno-unused -o build/refprop/Refprop.mips build/refprop/NVM.o (...) build/refprop/TRNS_VIS.o build/refprop/MAIN.o -march=mips1 -specs=/home/jhuber/Documents/source/nestedvm/upstream/install/mips-unknown-elf/lib/crt0-override.spec --static -Wl,--gc-sections -Wl,-Map=output1.map -Wl,--cref -lc -Wl,-Map=output.map -Wl,--cref
Also, even though I am calling the code as a library, nestedvm requires the library to have a MAIN routine for initialization. If I make some dummy calls to the library functions in the MAIN routine, those functions that are called in MAIN are moved the .text section, and become callable.
** UPDATE 3 **
Verbose output from make. I removed some of the many .o files (…)
mips-unknown-elf-gfortran -O3 -mmemcpy -ffunction-sections -fdata-sections -falign-functions=512 -fno-rename-registers -fno-schedule-insns -fno-delayed-branch -march=mips1 -specs=/home/jhuber/Documents/source/nestedvm/upstream/install/mips-unknown-elf/lib/crt0-override.spec -I. -Wall -Wno-unused -o build/refprop/Refprop.mips build/refprop/NVM.o (…) build/refprop/TRNS_VIS.o build/refprop/MAIN.o -march=mips1 -specs=/home/jhuber/Documents/source/nestedvm/upstream/install/mips-unknown-elf/lib/crt0-override.spec --static -Wl,--gc-sections -Wl,-Map=output1.map -Wl,--cref -lc -Wl,-Map=output.map -Wl,--cref -v
Driving: mips-unknown-elf-gfortran -O3 -mmemcpy -ffunction-sections -fdata-sections -falign-functions=512 -fno-rename-registers -fno-schedule-insns -fno-delayed-branch -march=mips1 -specs=/home/jhuber/Documents/source/nestedvm/upstream/install/mips-unknown-elf/lib/crt0-override.spec -I. -Wall -Wno-unused -o build/refprop/Refprop.mips build/refprop/NVM.o (…) build/refprop/TRNS_VIS.o build/refprop/MAIN.o -march=mips1 -specs=/home/jhuber/Documents/source/nestedvm/upstream/install/mips-unknown-elf/lib/crt0-override.spec --static -Wl,--gc-sections -Wl,-Map=output1.map -Wl,--cref -lc -Wl,-Map=output.map -Wl,--cref -v -l gfortran -l m
Using built-in specs.
Reading specs from /home/jhuber/Documents/source/nestedvm/upstream/install/mips-unknown-elf/lib/crt0-override.spec
Reading specs from /home/jhuber/Documents/source/nestedvm/upstream/install/mips-unknown-elf/lib/crt0-override.spec
COLLECT_GCC=mips-unknown-elf-gfortran
COLLECT_LTO_WRAPPER=/home/jhuber/Documents/source/nestedvm/upstream/install/libexec/gcc/mips-unknown-elf/4.8.5/lto-wrapper
Target: mips-unknown-elf
Configured with: ../gcc-4.8.5/configure --prefix=/home/jhuber/Documents/source/nestedvm/upstream/install --target=mips-unknown-elf --disable-threads --disable-libssp --with-gnu-ld --with-gnu-as --with-newlib=yes --enable-sjlj-exceptions --enable-languages=c : (reconfigured) ../gcc-4.8.5/configure --prefix=/home/jhuber/Documents/source/nestedvm/upstream/install --target=mips-unknown-elf --disable-threads --disable-libssp --with-gnu-ld --with-gnu-as --with-newlib=yes --enable-sjlj-exceptions --enable-languages=c --enable-languages=c,c++,fortran
Thread model: single
gcc version 4.8.5 (GCC)
Reading specs from /home/jhuber/Documents/source/nestedvm/upstream/install/lib/gcc/mips-unknown-elf/4.8.5/../../../../mips-unknown-elf/lib/libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-O3' '-mmemcpy' '-ffunction-sections' '-fdata-sections' '-falign-functions=512' '-fno-rename-registers' '-fno-schedule-insns' '-fno-delayed-branch' '-march=mips1' '-specs=/home/jhuber/Documents/source/nestedvm/upstream/install/mips-unknown-elf/lib/crt0-override.spec' '-I' '.' '-Wall' '-Wno-unused' '-o' 'build/refprop/Refprop.mips' '-march=mips1' '-specs=/home/jhuber/Documents/source/nestedvm/upstream/install/mips-unknown-elf/lib/crt0-override.spec' '-static' '-v'
COMPILER_PATH=/home/jhuber/Documents/source/nestedvm/upstream/install/libexec/gcc/mips-unknown-elf/4.8.5/:/home/jhuber/Documents/source/nestedvm/upstream/install/libexec/gcc/mips-unknown-elf/4.8.5/:/home/jhuber/Documents/source/nestedvm/upstream/install/libexec/gcc/mips-unknown-elf/:/home/jhuber/Documents/source/nestedvm/upstream/install/lib/gcc/mips-unknown-elf/4.8.5/:/home/jhuber/Documents/source/nestedvm/upstream/install/lib/gcc/mips-unknown-elf/:/home/jhuber/Documents/source/nestedvm/upstream/install/lib/gcc/mips-unknown-elf/4.8.5/../../../../mips-unknown-elf/bin/
LIBRARY_PATH=/home/jhuber/Documents/source/nestedvm/upstream/install/lib/gcc/mips-unknown-elf/4.8.5/:/home/jhuber/Documents/source/nestedvm/upstream/install/lib/gcc/mips-unknown-elf/4.8.5/../../../../mips-unknown-elf/lib/
COLLECT_GCC_OPTIONS='-O3' '-mmemcpy' '-ffunction-sections' '-fdata-sections' '-falign-functions=512' '-fno-rename-registers' '-fno-schedule-insns' '-fno-delayed-branch' '-march=mips1' '-specs=/home/jhuber/Documents/source/nestedvm/upstream/install/mips-unknown-elf/lib/crt0-override.spec' '-I' '.' '-Wall' '-Wno-unused' '-o' 'build/refprop/Refprop.mips' '-march=mips1' '-specs=/home/jhuber/Documents/source/nestedvm/upstream/install/mips-unknown-elf/lib/crt0-override.spec' '-static' '-v'
/home/jhuber/Documents/source/nestedvm/upstream/install/libexec/gcc/mips-unknown-elf/4.8.5/collect2 -EB -o build/refprop/Refprop.mips /home/jhuber/Documents/source/nestedvm/upstream/install/lib/gcc/mips-unknown-elf/4.8.5/crti.o /home/jhuber/Documents/source/nestedvm/upstream/install/lib/gcc/mips-unknown-elf/4.8.5/crtbegin.o /home/jhuber/Documents/source/nestedvm/upstream/install/lib/gcc/mips-unknown-elf/4.8.5/../../../../mips-unknown-elf/lib/crt0.o -L/home/jhuber/Documents/source/nestedvm/upstream/install/lib/gcc/mips-unknown-elf/4.8.5 -L/home/jhuber/Documents/source/nestedvm/upstream/install/lib/gcc/mips-unknown-elf/4.8.5/../../../../mips-unknown-elf/lib build/refprop/NVM.o (…) build/refprop/TRNS_VIS.o build/refprop/MAIN.o --gc-sections -Map=output1.map --cref -lc -Map=output.map --cref -lgfortran -lm -lgcc -lm -lgcc -lgcc /home/jhuber/Documents/source/nestedvm/upstream/install/lib/gcc/mips-unknown-elf/4.8.5/crtend.o /home/jhuber/Documents/source/nestedvm/upstream/install/lib/gcc/mips-unknown-elf/4.8.5/crtn.o
I did some local tests, and -ffunction-sections puts each fortran function its own section, as expected. Compare:
$ gfortran -c -O3 -o hello.o hello.f90
$ objdump -h hello.o
hello.o: file format elf64-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 000000aa 0000000000000000 0000000000000000 00000040 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 0000000000000000 0000000000000000 000000ea 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 0000000000000000 0000000000000000 000000ea 2**0
ALLOC
3 .rodata.str1.1 0000000a 0000000000000000 0000000000000000 000000ea 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .text.startup 00000026 0000000000000000 0000000000000000 00000100 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
5 .rodata 0000001c 0000000000000000 0000000000000000 00000130 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .comment 00000026 0000000000000000 0000000000000000 0000014c 2**0
CONTENTS, READONLY
7 .note.GNU-stack 00000000 0000000000000000 0000000000000000 00000172 2**0
CONTENTS, READONLY
8 .eh_frame 00000068 0000000000000000 0000000000000000 00000178 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
to:
$ gfortran -ffunction-sections -c -O3 -o hello.o hello.f90
$ objdump -h hello.o
hello.o: file format elf64-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000000 0000000000000000 0000000000000000 00000040 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000000 0000000000000000 0000000000000000 00000040 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 0000000000000000 0000000000000000 00000040 2**0
ALLOC
3 .rodata.str1.1 0000000a 0000000000000000 0000000000000000 00000040 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .text.MAIN__ 00000097 0000000000000000 0000000000000000 00000050 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
5 .text.foo_ 0000000a 0000000000000000 0000000000000000 000000f0 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
6 .text.startup.main 00000026 0000000000000000 0000000000000000 00000100 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
7 .rodata 0000001c 0000000000000000 0000000000000000 00000130 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .comment 00000026 0000000000000000 0000000000000000 0000014c 2**0
CONTENTS, READONLY
9 .note.GNU-stack 00000000 0000000000000000 0000000000000000 00000172 2**0
CONTENTS, READONLY
10 .eh_frame 00000068 0000000000000000 0000000000000000 00000178 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
The builtin linker script on my local machine rolls all of these into .text by default. It appears whatever you're linking with doesn't. You should be able to modify that script to do what you're trying. It's a bit more difficult than the attribute extensions, since you'll have to maintain the list in a separate file, but you should be able to locate things however you like. I can work up an example here if you give some more context about that in your question.