What is the format of special section in ELF - elf

I try to write a program to generate ELF(based on Arm and execute through qemu-arm). Most format in ELF has been well illustrated
on wiki. But I can't find any spec describe the format of special section(e.g. .text .data(especially what I want to know)).
I tried to put some initialized global variable in .data section. What format should I write in ELF(.data section) if I have global statement like: int a = 10;

There is not special format for .text and .data.
When the static linker links several .o file,
it simply concatenates the .text and .data segments (while resolving relocations)
and places them in the final .so or executable file according to the linker script (see gcc -Wl,-verbose /dev/null).
The .data segment simply contains the initial values of the instanciated global variables.
The .text segment simply contains the machine code of the routines/functions.
Let's take this simple C file:
char x[5] = {0xba, 0xbb, 0xbc, 0xbd, 0xbe};
char f(int i) {
return x[i];
}
Let's compile it:
$ gcc -c -o test.o test.c
Let's dump the .data section, using elfcat:
$ elfcat test.o --section-name .data | xxd
00000000: babb bcbd be .....
We can clearly explain the content of .data section.
Let's dump the .text section:
$ elfcat test.o --section-name .text | xxd
00000000: 5548 89e5 897d fc8b 45fc 4898 488d 1500 UH...}..E.H.H...
00000010: 0000 000f b604 105d c3
Let's decompile this:
$ elfcat test.o --section-name .text > test.text
$ r2 -a x86 -b 64 -qc pd test.text
0x00000000 55 push rbp
0x00000001 4889e5 mov rbp, rsp
0x00000004 897dfc mov dword [rbp - 4], edi
0x00000007 8b45fc mov eax, dword [rbp - 4]
0x0000000a 4898 cdqe
0x0000000c 488d15000000. lea rdx, qword [0x00000013] ; 19
0x00000013 0fb60410 movzx eax, byte [rax + rdx]
0x00000017 5d pop rbp
0x00000018 c3 ret
Again, there is nothing special in the text segment: it only contains the machine code of the routines/functions of my program.
Notice however the relocation and symbol informations in other segments:
$ readelf -a test.o
[ ... ]
Relocation section '.rela.text' at offset 0x1b8 contains 1 entry:
Offset Info Type Sym. Value Sym. Name + Addend
00000000000f 000800000002 R_X86_64_PC32 0000000000000000 x - 4
Relocation section '.rela.eh_frame' at offset 0x1d0 contains 1 entry:
Offset Info Type Sym. Value Sym. Name + Addend
000000000020 000200000002 R_X86_64_PC32 0000000000000000 .text + 0
[...]
Symbol table '.symtab' contains 10 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS test.c
2: 0000000000000000 0 SECTION LOCAL DEFAULT 1
3: 0000000000000000 0 SECTION LOCAL DEFAULT 3
4: 0000000000000000 0 SECTION LOCAL DEFAULT 4
5: 0000000000000000 0 SECTION LOCAL DEFAULT 6
6: 0000000000000000 0 SECTION LOCAL DEFAULT 7
7: 0000000000000000 0 SECTION LOCAL DEFAULT 5
8: 0000000000000000 5 OBJECT GLOBAL DEFAULT 3 x
9: 0000000000000000 25 FUNC GLOBAL DEFAULT 1 f

Related

Understanding ELF TBSS and TDATA section loading

My elf file's sections are as follows
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .text PROGBITS fffffffff7e020b0 000000b0
0000000000074f50 0000000000000000 AX 0 0 16
[ 2] .rodata PROGBITS fffffffff7e77000 00075000
0000000000014000 0000000000000000 AM 0 0 16
[ 3] .eh_frame_hdr PROGBITS fffffffff7e8b000 00089000
000000000000000c 0000000000000000 A 0 0 4
[ 4] .data PROGBITS fffffffff7e8b010 00089010
0000000000001ff0 0000000000000000 WA 0 0 16
[ 5] .bss NOBITS fffffffff7e8d000 0008b000
0000000000014000 0000000000000000 WA 0 0 4096
[ 6] .got PROGBITS fffffffff7ea1000 0009f000
0000000000001000 0000000000000000 WA 0 0 8
[ 7] .tdata PROGBITS fffffffff7ea2000 000a0000
000000000000b000 0000000000000000 WAT 0 0 8
[ 8] .tbss NOBITS fffffffff7ead000 000ab000
000000000000012a 0000000000000000 WAT 0 0 8
[ 9] .debug_abbrev PROGBITS 0000000000000000 000ab000
000000000001a8d4 0000000000000000 0 0 1
[10] .debug_info PROGBITS 0000000000000000 000c58d4
000000000016c624 0000000000000000 0 0 1
[11] .debug_aranges PROGBITS 0000000000000000 00231ef8
0000000000024130 0000000000000000 0 0 1
[12] .debug_ranges PROGBITS 0000000000000000 00256028
000000000004bfa0 0000000000000000 0 0 1
[13] .debug_str PROGBITS 0000000000000000 002a1fc8
0000000000123ecd 0000000000000001 MS 0 0 1
[14] .debug_pubnames PROGBITS 0000000000000000 003c5e95
000000000005da3c 0000000000000000 0 0 1
[15] .debug_pubtypes PROGBITS 0000000000000000 004238d1
00000000000a1e07 0000000000000000 0 0 1
[16] .debug_frame PROGBITS 0000000000000000 004c56d8
0000000000056c10 0000000000000000 0 0 8
[17] .debug_line PROGBITS 0000000000000000 0051c2e8
00000000000b5c55 0000000000000000 0 0 1
[18] .debug_loc PROGBITS 0000000000000000 005d1f3d
000000000000628c 0000000000000000 0 0 1
[19] .symtab SYMTAB 0000000000000000 005d81d0
0000000000015a20 0000000000000018 21 2565 8
[20] .shstrtab STRTAB 0000000000000000 005edbf0
00000000000000da 0000000000000000 0 0 1
[21] .strtab STRTAB 0000000000000000 005edcca
000000000004783e 0000000000000000 0 0 1
and the program headers are
Elf file type is EXEC (Executable file)
Entry point 0xfffffffff7e39be0
There are 2 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0xfffffffff7e02000 0x0000000000000000
0x00000000000ab000 0x00000000000ab12a RWE 0x1000
TLS 0x00000000000a0000 0xfffffffff7ea2000 0x00000000000a0000
0x000000000000b000 0x000000000000b12a RW 0x8
Section to Segment mapping:
Segment Sections...
00 .text .rodata .eh_frame_hdr .data .bss .got .tdata
01 .tdata .tbss
The TLS section's total size is as expected being the size of tdata + tbss sections.
From the TLS handling document, i expect that tdata and tbss sections will be right before the fs register's pointed value and thus the total size would be 0xb12a.
But one of the variables which use thread_local have an offset of fs - 0xb130 which is outside of the expected TLS size.
I am trying to understand why the variable is not offset to at-most 0xb12a but more than that?
Although the size of TLS here is 0xb12a. The alignment of 0x8 will make the TLS pointer move to 0xb130 which is the address of variable observed here.

why does not readelf report right sizes?

I have a Linux executable file (which is an ELF file) called a.out.
I use
readelf -hl a.out
and get output
ELF Header:
Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - GNU
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x4008e0
Start of program headers: 64 (bytes into file)
Start of section headers: 910680 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 6
Size of section headers: 64 (bytes)
Number of section headers: 33
Section header string table index: 30
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x00000000000c9be6 0x00000000000c9be6 R E 200000
LOAD 0x00000000000c9eb8 0x00000000006c9eb8 0x00000000006c9eb8
0x0000000000001c98 0x0000000000003550 RW 200000
NOTE 0x0000000000000190 0x0000000000400190 0x0000000000400190
0x0000000000000044 0x0000000000000044 R 4
TLS 0x00000000000c9eb8 0x00000000006c9eb8 0x00000000006c9eb8
0x0000000000000020 0x0000000000000050 R 8
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 10
GNU_RELRO 0x00000000000c9eb8 0x00000000006c9eb8 0x00000000006c9eb8
0x0000000000000148 0x0000000000000148 R 1
Section to Segment mapping:
Segment Sections...
00 .note.ABI-tag .note.gnu.build-id .rela.plt .init .plt .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata __libc_subfreeres __libc_atexit .stapsdt.base __libc_thread_subfreeres .eh_frame .gcc_except_table
01 .tdata .init_array .fini_array .jcr .data.rel.ro .got .got.plt .data .bss __libc_freeres_ptrs
02 .note.ABI-tag .note.gnu.build-id
03 .tdata .tbss
04
05 .tdata .init_array .fini_array .jcr .data.rel.ro .got
According to the above output, this ELF file should have size
ELF header size : 64
+
Section headers : 64*33 = 2112
+
Program headers : 56*6 = 336
+
Segments : 834090 = 0x00000000000c9be6 + 0x0000000000001c98 + 0x0000000000000044 + 0x0000000000000020 + 0x0000000000000148
= 64 + 2112 + 336 + 834090 = 836602
However, /bin/ls reports file size 912792.
where are the 912792 - 836602 = 76190 bytes?
which parts did I forget to count?
UPDATE
according to #Jonathon Reinhart, I re count the size using section sizes instead of segment size by
echo "print 0x020 + 0x024 + 0x0f0 + 0x01a + 0x0a0 + 0x09eda4 + 0x02529 + 0x0de + 0x09 + 0x01d320 + 0x050 + 0x08 + 0x01 + 0x08 + 0x0b04c + 0x0b2 + 0x020 + 0x010 + 0x010 + 0x08 + 0x0e4 + 0x010 + 0x068 + 0x01ad0 + 0x023 + 0x0f18 + 0x0169 + 0x0b100 + 0x0685a" | /usr/bin/python
The section size values used above are extracted from the output of readelf -S a.out and the size of section type of "NOBITS" were not counted.
The above code output 909459 which is bigger than segment size 834090,
however, the total size is still not equal to the file size.
64 + 2112 + 336 + 909459 = 911971 != 912792
still missing 912792 - 911971 = 821 bytes.
update2 [solved]
according to the comment, I have test the offset. The result tells me that the adding pad does exist.

ELF program segments offset in file

I have a question,about elf program segments offsize in file. For example , a program readelf -f xx -W like this:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000040 0x0000000000400040 0x0000000000400040 0x0001f8 0x0001f8 R E 0x8
INTERP 0x000238 0x0000000000400238 0x0000000000400238 0x00001c 0x00001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x4ca8e6 0x4ca8e6 R E 0x200000
LOAD 0x4cb000 0x0000000000acb000 0x0000000000acb000 0x035db8 0x04ed80 RW 0x200000
DYNAMIC 0x4ed4c8 0x0000000000aed4c8 0x0000000000aed4c8 0x000230 0x000230 RW 0x8
NOTE 0x000254 0x0000000000400254 0x0000000000400254 0x000044 0x000044 R 0x4
TLS 0x4cb000 0x0000000000acb000 0x0000000000acb000 0x000010 0x000018 R 0x10
GNU_EH_FRAME 0x3dcf04 0x00000000007dcf04 0x00000000007dcf04 0x024c64 0x024c64 R 0x4
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame .gcc_except_table
03 .tdata .init_array .fini_array .jcr .data.rel.ro .dynamic .got .got.plt .data .bss
04 .dynamic
05 .note.ABI-tag .note.gnu.build-id
06 .tdata .tbss
07 .eh_frame_hdr
08
The first load begin at offset 0x000000 and the size is 0x4ca8e6. why the second offset not (0x000000 + 0x4ca8e6), I see the (0x4cb000 - 0x4ca8e6) content, all 0. I can't get it. What the rule about the offset in file?
The first load begin at offset 0x000000 and the size is 0x4ca8e6. why the second offset not (0x000000 + 0x4ca8e6)
Because the loader mmaps LOAD segments directly into memory, for each LOAD segment the following must be true: (p_vaddr - p_offset) % page_size == 0.
On x86_64 the maximum page size is 2MiB (0x200000). This places severe restriction on the second (and subsequent) LOAD segment location.

clang/LLVM project level optimization

So periodically I try LLVM as I have this theory it should outperform GNU. And then it sadly doesn't.
Part of the theory has to do with its ability to link modules/objects together and THEN optimize, where normally optimization happens on a per file/object basis.
Instead of using a generic one, I see how to build for a specific default target
rm -rf llvm-project
git clone https://github.com/llvm/llvm-project.git
cd llvm-project
git checkout llvmorg-10.0.0
mkdir build
cd build
cmake -DLLVM_ENABLE_PROJECTS='clang;lld' -DCMAKE_CROSSCOMPILING=True -DCMAKE_INSTALL_PREFIX=/opt/llvm/llvm10armv6m -DLLVM_DEFAULT_TARGET_TRIPLE=armv6m-none-eabi -DLLVM_TARGET_ARCH=ARM -DLLVM_TARGETS_TO_BUILD=ARM -G "Unix Makefiles" ../llvm
make -j 8
make -j 4
make
sudo make install
And the test files
test.c
unsigned int one ( void )
{
return(1);
}
unsigned int two ( void );
unsigned int testone ( void )
{
return(one());
}
unsigned int testtwo ( void )
{
return(two());
}
two.c
unsigned int two ( void )
{
return(2);
}
basic run
clang -O2 -fomit-frame-pointer -c test.c -o test.o
llvm-objdump -D test.o
00000000 one:
0: 01 20 movs r0, #1
2: 70 47 bx lr
00000004 testone:
4: 01 20 movs r0, #1
6: 70 47 bx lr
00000008 testtwo:
8: 80 b5 push {r7, lr}
a: ff f7 fe ff bl #-4
e: 80 bd pop {r7, pc}
as one would expect, one() has been inlined into testone().
The desire is to get testwo() inlined as well.
clang -fomit-frame-pointer -c -emit-llvm test.c -o test.bc
clang -fomit-frame-pointer -c -emit-llvm two.c -o two.bc
llvm-link test.bc two.bc -o both.bc
llc both.bc -o both.s
cat both.s
opt -O2 both.bc -o both.opt.bc
llc both.opt.bc -o both.opt.s
cat both.opt.s
gives
testone:
.fnstart
# %bb.0: # %entry
.save {r7, lr}
push {r7, lr}
bl one
pop {r7, pc}
testtwo:
.fnstart
# %bb.0: # %entry
.save {r7, lr}
push {r7, lr}
bl two
pop {r7, pc}
and
testone:
.fnstart
# %bb.0: # %entry
.save {r7, lr}
push {r7, lr}
bl one
pop {r7, pc}
testtwo:
.fnstart
# %bb.0: # %entry
.save {r7, lr}
push {r7, lr}
bl two
pop {r7, pc}
that is worse.
opt -std-link-opts both.bc -o both.opt.bc
same, no better
Now this works
clang -O2 -fomit-frame-pointer -c -emit-llvm test.c -o test.bc
clang -O2 -fomit-frame-pointer -c -emit-llvm two.c -o two.bc
llvm-link test.bc two.bc -o both.bc
opt -O2 both.bc -o both.opt.bc
llc both.opt.bc -o both.opt.s
cat both.opt.s
testone:
.fnstart
# %bb.0: # %entry
movs r0, #1
bx lr
testtwo:
.fnstart
# %bb.0: # %entry
movs r0, #2
bx lr
One would think that not optimizing the parts would give more meat for the optimization of the whole to chew on. Yes? Although this indicates otherwise.
clang -fomit-frame-pointer -c -emit-llvm test.c -o test.bc
clang -fomit-frame-pointer -c -emit-llvm two.c -o two.bc
llvm-link test.bc two.bc -o both.bc
opt -O3 both.bc -o both.opt.bc
llc both.opt.bc -o both.opt.s
cat both.opt.s
testone:
.fnstart
# %bb.0: # %entry
.save {r7, lr}
push {r7, lr}
bl one
movs r0, #1
pop {r7, pc}
testtwo:
.fnstart
# %bb.0: # %entry
.save {r7, lr}
push {r7, lr}
bl two
movs r0, #2
pop {r7, pc}
-O3 doesn't help either, and this output is as pretty bad it calls the function AND inlines it. What is going on there?!
llvm-dis both.opt.bc
cat both.opt.ll
; ModuleID = 'both.opt.bc'
source_filename = "llvm-link"
target datalayout = "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv6m-none-unknown-eabi"
; Function Attrs: noinline nounwind optnone
define dso_local i32 #one() local_unnamed_addr #0 {
entry:
ret i32 1
}
; Function Attrs: noinline nounwind optnone
define dso_local i32 #testone() local_unnamed_addr #0 {
entry:
%call = call i32 #one()
ret i32 1
}
; Function Attrs: noinline nounwind optnone
define dso_local i32 #testtwo() local_unnamed_addr #0 {
entry:
%call = call i32 #two()
ret i32 2
}
; Function Attrs: noinline nounwind optnone
define dso_local i32 #two() local_unnamed_addr #0 {
entry:
ret i32 2
}
How does one undo that?
clang -O2 -fomit-frame-pointer -c -emit-llvm test.c -o test.bc
clang -O2 -fomit-frame-pointer -c -emit-llvm two.c -o two.bc
llvm-link test.bc two.bc -o both.bc
llvm-dis both.bc
cat both.ll
opt -O3 both.bc -o both.opt.bc
llvm-dis both.opt.bc
cat both.opt.ll
gives
; Function Attrs: norecurse nounwind readnone
define dso_local i32 #one() local_unnamed_addr #0 {
entry:
ret i32 1
}
; Function Attrs: norecurse nounwind readnone
define dso_local i32 #testone() local_unnamed_addr #0 {
entry:
ret i32 1
}
; Function Attrs: nounwind
define dso_local i32 #testtwo() local_unnamed_addr #1 {
entry:
%call = tail call i32 #two() #2
ret i32 %call
}
; Function Attrs: norecurse nounwind readnone
define dso_local i32 #two() local_unnamed_addr #0 {
entry:
ret i32 2
}
and
; Function Attrs: norecurse nounwind readnone
define dso_local i32 #one() local_unnamed_addr #0 {
entry:
ret i32 1
}
; Function Attrs: norecurse nounwind readnone
define dso_local i32 #testone() local_unnamed_addr #0 {
entry:
ret i32 1
}
; Function Attrs: norecurse nounwind readnone
define dso_local i32 #testtwo() local_unnamed_addr #0 {
entry:
ret i32 2
}
; Function Attrs: norecurse nounwind readnone
define dso_local i32 #two() local_unnamed_addr #0 {
entry:
ret i32 2
}
So is it correct that you have to apply the optimizations everywhere, at the file/object level in order to get the project level to optimize?
And then there is the question of tail call or leaf, etc optimization, if nothing else testtwo: even in the first case
clang -O2 -fomit-frame-pointer -c test.c -o test.o
could simply branch to two() and not setup a stack frame not do any of that. Or is this a thumb thing? b cant reach?
one:
0: b8 01 00 00 00 movl $1, %eax
5: c3 retq
testone:
10: b8 01 00 00 00 movl $1, %eax
15: c3 retq
testtwo:
20: e9 00 00 00 00 jmp 0 <testtwo+5>
In gnu the linker patches up any branch reaching or mode issues with trampolines
arm-none-eabi-gcc -c -O2 -mcpu=cortex-m0 test.c -o test.o
arm-none-eabi-objdump -D test.o
00000000 <one>:
0: 2001 movs r0, #1
2: 4770 bx lr
00000004 <testone>:
4: 2001 movs r0, #1
6: 4770 bx lr
00000008 <testtwo>:
8: b510 push {r4, lr}
a: f7ff fffe bl 0 <two>
e: bd10 pop {r4, pc}
Okay I stand corrected...
clang --version
clang version 10.0.0 (https://github.com/llvm/llvm-project.git d32170dbd5b0d54436537b6b75beaf44324e0c28)
Target: armv6m-none-unknown-eabi
Thread model: posix
InstalledDir: /opt/llvm/llvm10armv6m/bin
arm-none-eabi-gcc --version
arm-none-eabi-gcc (GCC) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I guess the question is if one wants to do a project level optimization using llvm-link and opt, is optimization of each of the individual items required or is there a command line option I am missing. Not interested in compiler specific attributes that go into the source code itself, want the code infected with neither gcc nor llvm specifics.
After gcc 5.x.x the code got more bloated was hoping that llvm would have a chance but whenever I try this (on projects not just 10 lines of code) gcc ends up with fewer executed instructions, and/or fewer memory accesses, etc, etc. For simple demonstration functions like the ones above, with some exceptions they produce the same/equivalent output.
Is there something, another one of the tools, or command line options, that I am missing in order to get more out of clang/llvm?
Is it that this is too trivial of an example for the tool to shine?
EDIT based on answer
clang -c start.s -o start.o
clang -O2 -flto=thin -fomit-frame-pointer -c test.c
clang -O2 -flto=thin -fomit-frame-pointer -c two.c
ld.lld start.o test.o two.o -o test.elf
llvm-objdump -D test.elf
000110fc testtwo:
110fc: 02 20 movs r0, #2
110fe: 70 47 bx lr
00011100 two:
11100: 02 20 movs r0, #2
11102: 70 47 bx lr
so getting rid of the -emit-llvm and using lto basically gives the desired result.
Looking at the bc disassembly
clang -O2 -flto=thin -fomit-frame-pointer -c test.c
llvm-dis test.o
cat test.o.ll
; Function Attrs: norecurse nounwind readnone
define dso_local i32 #one() local_unnamed_addr #0 {
entry:
ret i32 1
}
; Function Attrs: norecurse nounwind readnone
define dso_local i32 #testone() local_unnamed_addr #0 {
entry:
ret i32 1
}
; Function Attrs: nounwind
define dso_local i32 #testtwo() local_unnamed_addr #1 {
entry:
%call = tail call i32 #two() #3
ret i32 %call
}
enables/adds the tail call. I really dislike using the compiler/shell as a linker (for embedded projects that have their own bootstrap and linker script), llvm-ldd usage wasn't easy to figure out or basically couldn't figure out, but ld.lld also supports the tlo stuff, so that worked out.
The answer is pretty easy actually: one should never want to use llc / opt / llvm-link for performing "end-user" project level kind of optimizations. These are developer-side tools with different defaults, thresholds, etc. Basically, they are just simple command-line frontends to various pieces of LLVM toolbox.
In order to perform the proper link-time-optimization you'd need to use the pipelines that were intended for such task. Basically, compiling everything using "clang -flto" and then linking everything again via "clang -flto" would work. Using LTO-aware linker like lld is a prerequisite as well.
Some further information about ThinLTO could also be found here: https://clang.llvm.org/docs/ThinLTO.html and http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html

Which parts of ELF format does objcopy parameter --strip-all remove?

I did compile and link my program and i get a format in ELF32 little endian which is build like this:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x11029000
Start of program headers: 52 (bytes into file)
Start of section headers: 6804 (bytes into file)
Flags: 0x5000002, has entry point, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 16
Section header string table index: 13
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 11029000 001000 000414 00 AX 0 0 4
[ 2] .ARM.attributes ARM_ATTRIBUTES 00000000 001414 000030 00 0 0 1
[ 3] .comment PROGBITS 00000000 001444 00002a 01 MS 0 0 1
[ 4] .debug_abbrev PROGBITS 00000000 00146e 0000d8 00 0 0 1
[ 5] .debug_info PROGBITS 00000000 001546 00013c 00 0 0 1
[ 6] .debug_line PROGBITS 00000000 001682 00012f 00 0 0 1
[ 7] .debug_loc PROGBITS 00000000 0017b1 00005f 00 0 0 1
[ 8] .debug_pubnames PROGBITS 00000000 001810 000034 00 0 0 1
[ 9] .debug_aranges PROGBITS 00000000 001844 000020 00 0 0 1
[10] .debug_ranges PROGBITS 00000000 001864 000078 00 0 0 1
[11] .debug_str PROGBITS 00000000 0018dc 0000bf 01 MS 0 0 1
[12] .debug_frame PROGBITS 00000000 00199c 000048 00 0 0 4
[13] .shstrtab STRTAB 00000000 0019e4 0000b0 00 0 0 1
[14] .symtab SYMTAB 00000000 001d14 000450 10 15 55 4
[15] .strtab STRTAB 00000000 002164 000244 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x11028000 0x11028000 0x01414 0x01414 R E 0x8000
Section to Segment mapping:
Segment Sections...
00 .text
There is no dynamic section in this file.
There are no relocations in this file.
There are no unwind sections in this file.
Symbol table '.symtab' contains 69 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 11029000 0 SECTION LOCAL DEFAULT 1
2: 00000000 0 SECTION LOCAL DEFAULT 2
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 SECTION LOCAL DEFAULT 4
5: 00000000 0 SECTION LOCAL DEFAULT 5
6: 00000000 0 SECTION LOCAL DEFAULT 6
7: 00000000 0 SECTION LOCAL DEFAULT 7
8: 00000000 0 SECTION LOCAL DEFAULT 8
9: 00000000 0 SECTION LOCAL DEFAULT 9
10: 00000000 0 SECTION LOCAL DEFAULT 10
11: 00000000 0 SECTION LOCAL DEFAULT 11
12: 00000000 0 SECTION LOCAL DEFAULT 12
13: 00000010 0 NOTYPE LOCAL DEFAULT ABS MODE_USR
14: 00000011 0 NOTYPE LOCAL DEFAULT ABS MODE_FIQ
15: 00000012 0 NOTYPE LOCAL DEFAULT ABS MODE_IRQ
16: 00000013 0 NOTYPE LOCAL DEFAULT ABS MODE_SVC
17: 000000d3 0 NOTYPE LOCAL DEFAULT ABS MODE_SVC_NI
18: 00000017 0 NOTYPE LOCAL DEFAULT ABS MODE_ABORT
19: 0000001b 0 NOTYPE LOCAL DEFAULT ABS MODE_UNDEF
20: 0000001f 0 NOTYPE LOCAL DEFAULT ABS MODE_SYSTEM
21: 0000001f 0 NOTYPE LOCAL DEFAULT ABS MODE_BITS
22: 00000080 0 NOTYPE LOCAL DEFAULT ABS I_MASK
23: 00000040 0 NOTYPE LOCAL DEFAULT ABS F_MASK
24: 000000c0 0 NOTYPE LOCAL DEFAULT ABS IF_MASK
25: 1201c000 0 NOTYPE LOCAL DEFAULT ABS BROM_MMU_BASE_ADDR
26: ffffeffa 0 NOTYPE LOCAL DEFAULT ABS MMU_DISABLE_MASK
27: 00001005 0 NOTYPE LOCAL DEFAULT ABS MMU_ENABLE_MASK
28: 00000080 0 NOTYPE LOCAL DEFAULT ABS FIQ_STACK_SIZE
29: 00000100 0 NOTYPE LOCAL DEFAULT ABS IRQ_STACK_SIZE
30: 00000020 0 NOTYPE LOCAL DEFAULT ABS ABORT_STACK_SIZE
31: 00000020 0 NOTYPE LOCAL DEFAULT ABS UNDEF_STACK_SIZE
32: 00000040 0 NOTYPE LOCAL DEFAULT ABS SYSTEM_STACK_SIZE
33: 11029000 0 NOTYPE LOCAL DEFAULT 1 $a
34: 11029080 0 NOTYPE LOCAL DEFAULT 1 arm926ejs_reset_handler
35: 11029004 0 NOTYPE LOCAL DEFAULT 1 $d
36: 1102901c 0 NOTYPE LOCAL DEFAULT 1 image_type
37: 11029020 0 NOTYPE LOCAL DEFAULT 1 sizeOfPermanentCode
38: 1102902c 0 NOTYPE LOCAL DEFAULT 1 bootparameter
39: 11029080 0 NOTYPE LOCAL DEFAULT 1 $a
40: 110290e8 0 NOTYPE LOCAL DEFAULT 1 inVirtMem
41: 1102915c 0 NOTYPE LOCAL DEFAULT 1 clearzi
42: 11029170 0 NOTYPE LOCAL DEFAULT 1 clearzi_exit
43: 11029170 0 NOTYPE LOCAL DEFAULT 1 load_entry
44: 1102918c 0 NOTYPE LOCAL DEFAULT 1 inval
45: 11029180 0 NOTYPE LOCAL DEFAULT 1 flushonly
46: 11029198 0 NOTYPE LOCAL DEFAULT 1 $d
47: 00000000 0 FILE LOCAL DEFAULT ABS cgu_fractional_divider.c
48: 110291b4 0 NOTYPE LOCAL DEFAULT 1 $a
49: 11029300 0 NOTYPE LOCAL DEFAULT 1 $d
50: 1102930c 0 NOTYPE LOCAL DEFAULT 1 $a
51: 110293d4 0 NOTYPE LOCAL DEFAULT 1 $d
52: 110293d8 0 NOTYPE LOCAL DEFAULT 1 $a
53: 11029410 0 NOTYPE LOCAL DEFAULT 1 $d
54: 00000010 0 NOTYPE LOCAL DEFAULT 12 $d
55: 11029414 0 NOTYPE GLOBAL DEFAULT 1 __gnu_bssend
56: 11029414 0 NOTYPE GLOBAL DEFAULT 1 __gnu_bssstart
57: 11029414 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end
58: 00000600 0 NOTYPE GLOBAL DEFAULT ABS __image_size
59: 11029000 0 NOTYPE GLOBAL DEFAULT 1 __exidx_start
60: 11029000 0 NOTYPE GLOBAL DEFAULT 1 arm926ejs_reset
61: 11029000 0 NOTYPE GLOBAL DEFAULT 1 __start
62: 11029000 0 NOTYPE GLOBAL DEFAULT 1 __gnu_textstart
63: 1102930c 204 FUNC GLOBAL DEFAULT 1 adc_cgu
64: 11029178 0 NOTYPE GLOBAL DEFAULT 1 dcache_flush
65: 110291b4 344 FUNC GLOBAL DEFAULT 1 c_entry
66: 110293d8 60 FUNC GLOBAL DEFAULT 1 delay
67: 00000000 0 NOTYPE GLOBAL DEFAULT UND ea3131_init
68: 00000000 0 NOTYPE GLOBAL DEFAULT ABS __EH_FRAME_BEGIN__
No version information found in this file.
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "ARM926EJ-S"
Tag_CPU_arch: v5TEJ
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
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_DIV_use: Not allowed
Then i have to use the command below to change my format into binary. That is what i ve heard it does. But can anyone tell me which parts of ELF32 format exactly does parameter "--strip-all" remove and how is binary format then different than ELF32 format?
arm-none-eabi-objcopy -I elf32-littlearm -O binary --strip-all --verbose foo1 foo2
I includded my ELF32 format details above soo you can (if it is possible) color the parts which are removed.
Thank you very much.
binary is pure data and elf is the data in some genral format that describe how to use this data.
elf got a magic, sections, some tables and etc.
binary is only the data itself/