Understanding ELF TBSS and TDATA section loading - elf

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.

Related

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.

What is the format of special section in 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

How to understand the disassemble code output from gdb

Look at the following output from gdb, why does the instruction code is disordered?
It shows:
0xffffffff81107714 <+7>: mov %rdi,%rbx
then shows
0xffffffff8110770f <+2>: cmpq $0x0,0x10(%rdi)
.
(gdb) disassemble /m __d_rehash
Dump of assembler code for function __d_rehash:
1997 {
0xffffffff8110770d <+0>: push %rbp
0xffffffff8110770e <+1>: push %rbx
0xffffffff81107714 <+7>: mov %rdi,%rbx
1998 BUG_ON(!d_unhashed(entry));
0xffffffff8110770f <+2>: cmpq $0x0,0x10(%rdi)
0xffffffff81107717 <+10>: je 0xffffffff8110771b <__d_rehash+14>
0xffffffff81107719 <+12>: ud2
1999 hlist_bl_lock(b);
2000 entry->d_flags |= DCACHE_RCUACCESS;
0xffffffff81107726 <+25>: orl $0x80,(%rbx)
2001 hlist_bl_add_head_rcu(&entry->d_hash, b);
0xffffffff8110772c <+31>: lea 0x8(%rbx),%rdx
2002 hlist_bl_unlock(b);
2003 }
0xffffffff81107756 <+73>: pop %rbx
0xffffffff81107757 <+74>: pop %rbp
0xffffffff81107758 <+75>: retq
The following output by kernel oops shows that __d_rehash+0x19/0x4c is the parent call of crash. But I can't find the exact source responding to __d_rehash+0x19 from above disassemble output.
[ 2630.421613] RIP: 0010:[<ffffffff8110739c>] [<ffffffff8110739c>] bit_spin_lock.constprop.17+0xb/0x1f
[ 2630.421618] RSP: 0018:ffff8800b4a83c00 EFLAGS: 00000202
[ 2630.421619] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000013
[ 2630.421620] RDX: ffffc90000000000 RSI: ffffc900003b6130 RDI: ffffc900003b6130
[ 2630.421621] RBP: ffffc900003b6130 R08: ffff8800b4a83c70 R09: ffff8800bc286880
[ 2630.421622] R10: 0000000000000000 R11: ffff8800bc283940 R12: ffff8800bc283940
[ 2630.421623] R13: ffffc900003b6130 R14: 0000000000000000 R15: 0000000000000000
[ 2630.421625] FS: 00007fd5c5c2f7a0(0000) GS:ffff8800bfd80000(0000) knlGS:0000000000000000
[ 2630.421626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2630.421627] CR2: 000000000042ba30 CR3: 00000000ad201000 CR4: 00000000000406e0
[ 2630.421631] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2630.421632] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 2630.421633] Process dpkg (pid: 9941, threadinfo ffff8800b4a82000, task ffff880030871000)
[ 2630.421634] Stack:
[ 2630.421635] ffff88002f20b600 ffffffff81107726 ffff88002f20b600 ffff88002f20b600
[ 2630.421637] ffffffff8110848b 0000000000000000 ffffffff81108fef 000000000000000c
[ 2630.421639] ffff8800bc283940 ffff88002f20b600 ffff8800b4a83d68 ffff8800bc11bb40
[ 2630.421641] Call Trace:
[ 2630.421644] [<ffffffff81107726>] ? __d_rehash+0x19/0x4c
[ 2630.421646] [<ffffffff8110848b>] ? d_rehash+0x24/0x2a
[ 2630.421648] [<ffffffff81108fef>] ? d_splice_alias+0xb2/0xbd
[ 2630.421655] [<ffffffffa016a121>] ? ext4_lookup+0xc5/0xd2 [ext4]
[ 2630.421658] [<ffffffff8110013a>] ? d_alloc_and_lookup+0x33/0x62
[ 2630.421661] [<ffffffff81100996>] ? walk_component+0x1e7/0x3a0
[ 2630.421663] [<ffffffff81101a29>] ? path_lookupat+0x8b/0x2ac
[ 2630.421666] [<ffffffff8103a683>] ? should_resched+0x5/0x23
[ 2630.421669] [<ffffffff813453b9>] ? _cond_resched+0x7/0x1c
[ 2630.421671] [<ffffffff81101c66>] ? do_path_lookup+0x1c/0x81
[ 2630.421673] [<ffffffff8110346a>] ? user_path_at_empty+0x48/0x7d
[ 2630.421675] [<ffffffff810fb89e>] ? cp_new_stat+0xf0/0x104
[ 2630.421677] [<ffffffff810fb675>] ? vfs_fstatat+0x2d/0x63
[ 2630.421678] [<ffffffff810fb949>] ? sys_newstat+0x12/0x2d
[ 2630.421681] [<ffffffff8134b792>] ? system_call_fastpath+0x16/0x1b
__d_rehash+0x19 is hex, 25 decimal, which corresponds to
2000 entry->d_flags |= DCACHE_RCUACCESS;
0xffffffff81107726 <+25>: orl $0x80,(%rbx)
This is not "parent call" but return address, presumably from a call "hidden" in
1999 hlist_bl_lock(b);
The code is "reordered" because the compiler is free to generate it however it sees fit as long as the resulting semantics are the same and it figured it is beneficial to shuffle things up. Then as you can see gdb figured it will show it in a displaced manner.
A significantly better linux kernel debugger is "crash". It will happen to show all the assembly in order and annotate all blocks with file:line marks if you do 'dis -l'.

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/

How to detect text mode or graphics mode on boot loader?

I want to detect which mode I just using now with BIOS intXX when running bootloader I wrote.
How to detect now is text mode or graphics mode?
Which interrupt function I should use?
Thank you~
I didn't figure out why when I run int 10 ,the value of AL doesn't change.
(0) Breakpoint 1, 0x00007c00 in ?? ()
Next at t=12943079
(0) [0x00007c00] 0000:7c00 (unk. ctxt): mov ah, 0x0f ; b40f
<bochs:3> reg
eax: 0x0000aa55 43605
ecx: 0x00090000 589824
edx: 0x00000000 0
ebx: 0x00000000 0
esp: 0x0000ffd6 65494
ebp: 0x00000000 0
esi: 0x000e476c 935788
edi: 0x0000ffac 65452
eip: 0x00007c00
eflags 0x00000082: id vip vif ac vm rf nt IOPL=0 of df if tf SF zf af pf cf
<bochs:4> n
Next at t=12943080
(0) [0x00007c02] 0000:7c02 (unk. ctxt): mov al, 0xaa ; b0aa
<bochs:5> reg
eax: 0x00000f55 3925
ecx: 0x00090000 589824
edx: 0x00000000 0
ebx: 0x00000000 0
esp: 0x0000ffd6 65494
ebp: 0x00000000 0
esi: 0x000e476c 935788
edi: 0x0000ffac 65452
eip: 0x00007c02
eflags 0x00000082: id vip vif ac vm rf nt IOPL=0 of df if tf SF zf af pf cf
<bochs:6> n
Next at t=12943081
(0) [0x00007c04] 0000:7c04 (unk. ctxt): int 0x0a ; cd0a
<bochs:7> reg
eax: 0x00000faa 4010
ecx: 0x00090000 589824
edx: 0x00000000 0
ebx: 0x00000000 0
esp: 0x0000ffd6 65494
ebp: 0x00000000 0
esi: 0x000e476c 935788
edi: 0x0000ffac 65452
eip: 0x00007c04
eflags 0x00000082: id vip vif ac vm rf nt IOPL=0 of df if tf SF zf af pf cf
<bochs:8> n
Next at t=12943083
(0) [0x00007c06] 0000:7c06 (unk. ctxt): mov dl, al ; 88c2
<bochs:9> reg
eax: 0x00000faa 4010
ecx: 0x00090000 589824
edx: 0x00000000 0
ebx: 0x00000000 0
esp: 0x0000ffd6 65494
ebp: 0x00000000 0
esi: 0x000e476c 935788
edi: 0x0000ffac 65452
eip: 0x00007c06
eflags 0x00000082: id vip vif ac vm rf nt IOPL=0 of df if tf SF zf af pf cf
<bochs:10>
INT10, F
AH = 0F
on return:
AL = mode currently set(page mode)
BH = current display page
Page mode:
AL = 00 40x25 B/W text (CGA,EGA,MCGA,VGA)
= 01 40x25 16 color text (CGA,EGA,MCGA,VGA)
= 02 80x25 16 shades of gray text (CGA,EGA,MCGA,VGA)
= 03 80x25 16 color text (CGA,EGA,MCGA,VGA)
= 04 320x200 4 color graphics (CGA,EGA,MCGA,VGA)
= 05 320x200 4 color graphics (CGA,EGA,MCGA,VGA)
= 06 640x200 B/W graphics (CGA,EGA,MCGA,VGA)
= 07 80x25 Monochrome text (MDA,HERC,EGA,VGA)
= 08 160x200 16 color graphics (PCjr)
= 09 320x200 16 color graphics (PCjr)
= 0A 640x200 4 color graphics (PCjr)
= 0B Reserved (EGA BIOS function 11)
= 0C Reserved (EGA BIOS function 11)
= 0D 320x200 16 color graphics (EGA,VGA)
= 0E 640x200 16 color graphics (EGA,VGA)
= 0F 640x350 Monochrome graphics (EGA,VGA)
= 10 640x350 16 color graphics (EGA or VGA with 128K)
640x350 4 color graphics (64K EGA)
= 11 640x480 B/W graphics (MCGA,VGA)
= 12 640x480 16 color graphics (VGA)
= 13 320x200 256 color graphics (MCGA,VGA)
= 8x EGA, MCGA or VGA ignore bit 7, see below
= 9x EGA, MCGA or VGA ignore bit 7, see below