I have this linker script for my elf executable:
ENTRY(_start)
SECTIONS
{
. = 0x500;
.mboot BLOCK(4K) : ALIGN(4K)
{
*(.mboot)
}
. = 0x7E00;
.ap_stack BLOCK(48K) : ALIGN(4K)
{
*(.ap_stack)
}
.mp_entry BLOCK(4K) : ALIGN(4K)
{
*(.mp_entry)
}
_mp_entry_end = .;
. = 1M;
.init BLOCK(4K) : ALIGN(4K)
{
*(.init)
}
_init_end = .;
. = 0xFFFFFFFF80000000 + _init_end;
.text : AT(ADDR(.text) - 0xFFFFFFFF80000000)
{
_code = .;
*(.text)
*(.rodata*)
*(.stack)
. = ALIGN(4096);
}
.data : AT(ADDR(.data) - 0xFFFFFFFF80000000)
{
_data = .;
*(.data)
. = ALIGN(4096);
}
.eh_frame : AT(ADDR(.eh_frame) - 0xFFFFFFFF80000000)
{
_ehframe = .;
*(.eh_frame)
. = ALIGN(4096);
}
.bss : AT(ADDR(.bss) - 0xFFFFFFFF80000000)
{
_bss = .;
*(.bss)
*(.rodata)
*(COMMON)
. = ALIGN(4096);
}
_end = .;
/DISCARD/ :
{
*(.comment)
}
}
Which should place section .ap_stack at physical/virtual address 0x8000. In assembly, I have:
[BITS 32]
section .ap_stack, nobits
align 16
ap_stack:
resb 0x48000
ap_stack_top:
which should make an empty space at that point, however, if I check final elf, I get:
Idx Name Size VMA LMA File off Algn
0 .mboot 0000000c 0000000000001000 0000000000001000 00001000 2**12
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .mp_entry 00000001 000000000000c000 000000000000c000 00002000 2**12
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .init 00006054 0000000000100000 0000000000100000 00003000 2**12
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .text 0000efa0 ffffffff80106060 0000000000106060 00009060 2**5
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .data 00001000 ffffffff80115000 0000000000115000 00018000 2**5
CONTENTS, ALLOC, LOAD, DATA
5 .eh_frame 00002000 ffffffff80116000 0000000000116000 00019000 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .bss 00012000 ffffffff80118000 0000000000118000 0001b000 2**5
ALLOC
7 .stack, 00005000 ffffffff8012a000 000000000012a000 0001b000 2**4
ALLOC, READONLY
8 .ap_stack, 00048000 ffffffff8012f000 000000000012f000 0001b000 2**4
ALLOC, READONLY
9 .debug_info 000097b8 0000000000000000 0000000000000000 0001b000 2**0
CONTENTS, READONLY, DEBUGGING
10 .debug_abbrev 0000210d 0000000000000000 0000000000000000 000247b8 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_aranges 00000560 0000000000000000 0000000000000000 000268c5 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_line 000030e7 0000000000000000 0000000000000000 00026e25 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_str 000026a5 0000000000000000 0000000000000000 00029f0c 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_ranges 000001b0 0000000000000000 0000000000000000 0002c5b1 2**0
CONTENTS, READONLY, DEBUGGING
because linker has moved my ap_stack to be together with stack, which is definitely what I don't want. Any reason why and how can I stop this behavior?
Related
I have a core dump (created by application running on arm platform) which shows no shared library information (info shared yields no results):
(gdb) info shared
No shared libraries loaded at this time.
It seems to me that core file has the information about shared libraries (how to verify it? confirmed with eu-readelf) and it is just GDB that is not able to read them. I'm using GDB (v 8.3.1) from the same ARM toolchain that was used to build the application. It can read the core and executable but without the shared library information I can't map the memory properly so this makes the core file pretty much useless.
main info secion output looks like:
Exec file:
`app', file type elf32-littlearm.
[0] 0x0154->0x016d at 0x00000154: .interp ALLOC LOAD READONLY DATA HAS_CONTENTS
[1] 0x0170->0x0194 at 0x00000170: .note.gnu.build-id ALLOC LOAD READONLY DATA HAS_CONTENTS
[2] 0x0194->0x01b4 at 0x00000194: .note.ABI-tag ALLOC LOAD READONLY DATA HAS_CONTENTS
[3] 0x01b4->0x05b4 at 0x000001b4: .gnu.hash ALLOC LOAD READONLY DATA HAS_CONTENTS
[4] 0x05b4->0x2aa4 at 0x000005b4: .dynsym ALLOC LOAD READONLY DATA HAS_CONTENTS
[5] 0x2aa4->0x71f7 at 0x00002aa4: .dynstr ALLOC LOAD READONLY DATA HAS_CONTENTS
[6] 0x71f8->0x7696 at 0x000071f8: .gnu.version ALLOC LOAD READONLY DATA HAS_CONTENTS
[7] 0x7698->0x78c8 at 0x00007698: .gnu.version_r ALLOC LOAD READONLY DATA HAS_CONTENTS
[8] 0x78c8->0xf450 at 0x000078c8: .rel.dyn ALLOC LOAD READONLY DATA HAS_CONTENTS
[9] 0xf450->0x10118 at 0x0000f450: .rel.plt ALLOC LOAD READONLY DATA HAS_CONTENTS
[10] 0x10118->0x10124 at 0x00010118: .init ALLOC LOAD READONLY CODE HAS_CONTENTS
[11] 0x10124->0x11470 at 0x00010124: .plt ALLOC LOAD READONLY CODE HAS_CONTENTS
[12] 0x11470->0x273c34 at 0x00011470: .text ALLOC LOAD READONLY CODE HAS_CONTENTS
[13] 0x273c34->0x273c3c at 0x00273c34: .fini ALLOC LOAD READONLY CODE HAS_CONTENTS
[14] 0x273c40->0x32ea4c at 0x00273c40: .rodata ALLOC LOAD READONLY DATA HAS_CONTENTS
[15] 0x32ea4c->0x353744 at 0x0032ea4c: .ARM.extab ALLOC LOAD READONLY DATA HAS_CONTENTS
[16] 0x353744->0x36bc7c at 0x00353744: .ARM.exidx ALLOC LOAD READONLY DATA HAS_CONTENTS
[17] 0x36bc7c->0x36bc80 at 0x0036bc7c: .eh_frame ALLOC LOAD READONLY DATA HAS_CONTENTS
[18] 0x37c544->0x37c564 at 0x0036c544: .init_array ALLOC LOAD DATA HAS_CONTENTS
[19] 0x37c564->0x37c568 at 0x0036c564: .fini_array ALLOC LOAD DATA HAS_CONTENTS
[20] 0x37c568->0x37fea4 at 0x0036c568: .data.rel.ro ALLOC LOAD DATA HAS_CONTENTS
[21] 0x37fea4->0x37fffc at 0x0036fea4: .dynamic ALLOC LOAD DATA HAS_CONTENTS
[22] 0x380000->0x380fe8 at 0x00370000: .got ALLOC LOAD DATA HAS_CONTENTS
[23] 0x380fe8->0x3bbf5c at 0x00370fe8: .data ALLOC LOAD DATA HAS_CONTENTS
[24] 0x3bbf60->0x2443fc0 at 0x003abf5c: .bss ALLOC
[25] 0x0000->0x0011 at 0x003abf5c: .comment READONLY HAS_CONTENTS
[26] 0x0000->0x0039 at 0x003abf6d: .ARM.attributes READONLY HAS_CONTENTS
[27] 0x0000->0x21da0 at 0x003abfa8: .debug_aranges READONLY HAS_CONTENTS
[28] 0x0000->0x4b9ac1 at 0x003cdd48: .debug_info READONLY HAS_CONTENTS
[29] 0x0000->0x1603d at 0x00887809: .debug_abbrev READONLY HAS_CONTENTS
[30] 0x0000->0x100933 at 0x0089d846: .debug_line READONLY HAS_CONTENTS
[31] 0x0000->0xc33c8 at 0x0099e17c: .debug_frame READONLY HAS_CONTENTS
[32] 0x0000->0x11be8b6 at 0x00a61544: .debug_str READONLY HAS_CONTENTS
[33] 0x0000->0x0b31 at 0x01c1fdfa: .debug_loc READONLY HAS_CONTENTS
[34] 0x0000->0x250c0 at 0x01c20930: .debug_ranges READONLY HAS_CONTENTS
Core file:
`app.core', file type elf32-littlearm.
[0] 0x0000->0x0e68 at 0x000009d4: note0 READONLY HAS_CONTENTS
[1] 0x0000->0x0048 at 0x00000a30: .reg/14597 HAS_CONTENTS
[2] 0x0000->0x0048 at 0x00000a30: .reg HAS_CONTENTS
[3] 0x0000->0x0080 at 0x00000b20: .note.linuxcore.siginfo/14597 HAS_CONTENTS
[4] 0x0000->0x0080 at 0x00000b20: .note.linuxcore.siginfo HAS_CONTENTS
[5] 0x0000->0x0098 at 0x00000bb4: .auxv HAS_CONTENTS
[6] 0x0000->0x07f4 at 0x00000c60: .note.linuxcore.file/14597 HAS_CONTENTS
[7] 0x0000->0x07f4 at 0x00000c60: .note.linuxcore.file HAS_CONTENTS
[8] 0x0000->0x0074 at 0x00001468: .reg2/14597 HAS_CONTENTS
[9] 0x0000->0x0074 at 0x00001468: .reg2 HAS_CONTENTS
[10] 0x0000->0x0104 at 0x000014f0: .reg-arm-vfp/14597 HAS_CONTENTS
[11] 0x0000->0x0104 at 0x000014f0: .reg-arm-vfp HAS_CONTENTS
[12] 0x0000->0x0048 at 0x00001650: .reg/14608 HAS_CONTENTS
[13] 0x0000->0x0074 at 0x000016b0: .reg2/14608 HAS_CONTENTS
[14] 0x0000->0x0104 at 0x00001738: .reg-arm-vfp/14608 HAS_CONTENTS
[15] 0x412000->0x412000 at 0x00002000: load1 ALLOC READONLY CODE
[16] 0x78e000->0x792000 at 0x00002000: load2 ALLOC LOAD READONLY HAS_CONTENTS
[17] 0x792000->0x7ce000 at 0x00006000: load3 ALLOC LOAD HAS_CONTENTS
[18] 0x7ce000->0x28d1000 at 0x00042000: load4 ALLOC LOAD HAS_CONTENTS
[19] 0x6a9c8000->0x6aa8c000 at 0x02145000: load5 ALLOC LOAD HAS_CONTENTS
[20] 0x6cfbd000->0x6cfed000 at 0x02209000: load6 ALLOC LOAD HAS_CONTENTS
[21] 0x6cffe000->0x76000000 at 0x02239000: load7 ALLOC LOAD HAS_CONTENTS
[22] 0x76000000->0x76021000 at 0x0b23b000: load8 ALLOC LOAD HAS_CONTENTS
[23] 0x76021000->0x76021000 at 0x0b25c000: load9 ALLOC READONLY
...more entries follow (removed for this post)
not to mention that any attempt to retrieve backtrace looks like
(gdb) bt
#0 0x76967d16 in ?? ()
#1 0x769e2a30 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Does anyone have an idea what the problem could be here?
edit: eu-readelf --notes app.core yields:
eu-readelf --notes app.core
Segment notatki o długości 3688 B pod offsetem 0x9d4:
Właściciel Rozmiar danych Typ
CORE 148 PRSTATUS
info.si_signo: 11, info.si_code: 0, info.si_errno: 0, cursig: 11
sigpend: <>
sighold: <>
pid: 14597, ppid: 4103, pgrp: 14597, sid: 4103
utime: 3.290000, stime: 4.900000, cutime: 0.000000, cstime: 0.000000
orig_r0: 0, fpvalid: 1
r0: 10 r1: 2127907444 r2: 7938048 r3: 2127906060
r4: 4 r5: 2127905872 r6: 1990519627 r7: 4814896
r8: 10 r9: 2127907444 r10: 7938048 r11: 2127907068
r12: 142 sp: 0x7ed54880 lr: 0x769e2a31 pc: 0x76967d16
spsr: 0x80070030
CORE 124 PRPSINFO
state: 0, sname: R, zomb: 0, nice: 0, flag: 0x00400600
uid: 0, gid: 0, pid: 14597, ppid: 4103, pgrp: 14597, sid: 4103
fname: app, psargs: /tmp/app
CORE 128 SIGINFO
si_signo: 11, si_errno: 0, si_code: 0
sender PID: 14597, sender UID: 0
CORE 152 AUXV
HWCAP: 0x8b0d6 <half thumb fast-mult vfp edsp>
PAGESZ: 4096
CLKTCK: 100
PHDR: 0x412034
PHENT: 32
PHNUM: 9
BASE: 0x76f9c000
FLAGS: 0
ENTRY: 0x423471
UID: 0
EUID: 0
GID: 0
EGID: 0
SECURE: 0
RANDOM: 0x7ed54dc3
26
EXECFN: 0x7ed54ff0
PLATFORM: 0x7ed54dd3
NULL
CORE 2036 FILE
58 files:
00412000-0077e000 00000000 3588096 /tmp/app
0078e000-00792000 0036c000 16384 /tmp/app
00792000-007ce000 00370000 245760 /tmp/app
7693a000-7693c000 00000000 8192 /lib/libdl-2.30.so
7693c000-7694b000 00002000 61440 /lib/libdl-2.30.so
7694b000-7694c000 00001000 4096 /lib/libdl-2.30.so
7694c000-7694d000 00002000 4096 /lib/libdl-2.30.so
7694d000-76a2b000 00000000 909312 /lib/libc-2.30.so
76a2b000-76a3a000 000de000 61440 /lib/libc-2.30.so
76a3a000-76a3c000 000dd000 8192 /lib/libc-2.30.so
76a3c000-76a3e000 000df000 8192 /lib/libc-2.30.so
76a40000-76a52000 00000000 73728 /lib/libpthread-2.30.so
76a52000-76a61000 00012000 61440 /lib/libpthread-2.30.so
76a61000-76a62000 00011000 4096 /lib/libpthread-2.30.so
76a62000-76a63000 00012000 4096 /lib/libpthread-2.30.so
76a65000-76a7d000 00000000 98304 /lib/libgcc_s.so.1
76a7d000-76a8c000 00018000 61440 /lib/libgcc_s.so.1
76a8c000-76a8d000 00017000 4096 /lib/libgcc_s.so.1
76a8d000-76a8e000 00018000 4096 /lib/libgcc_s.so.1
76a8e000-76ae4000 00000000 352256 /lib/libm-2.30.so
76ae4000-76af3000 00056000 61440 /lib/libm-2.30.so
76af3000-76af4000 00055000 4096 /lib/libm-2.30.so
76af4000-76af5000 00056000 4096 /lib/libm-2.30.so
76af5000-76c1c000 00000000 1208320 /usr/lib/libstdc++.so.6.0.27
76c1c000-76c2c000 00127000 65536 /usr/lib/libstdc++.so.6.0.27
76c2c000-76c33000 00127000 28672 /usr/lib/libstdc++.so.6.0.27
76c33000-76c34000 0012e000 4096 /usr/lib/libstdc++.so.6.0.27
76c35000-76c3e000 00000000 36864 /apps/app/lib/libunwind.so.8
76c3e000-76c4d000 00009000 61440 /apps/app/lib/libunwind.so.8
76c4d000-76c4e000 00008000 4096 /apps/app/lib/libunwind.so.8
76c4e000-76c4f000 00009000 4096 /apps/app/lib/libunwind.so.8
76c68000-76c83000 00000000 110592 /apps/app/lib/libtid.so
76c83000-76c93000 0001b000 65536 /apps/app/lib/libtid.so
76c93000-76c94000 0001b000 4096 /apps/app/lib/libtid.so
76c94000-76c95000 0001c000 4096 /apps/app/lib/libtid.so
76c95000-76e1c000 00000000 1601536 /usr/lib/libcrypto.so.1.1
76e1c000-76e2b000 00187000 61440 /usr/lib/libcrypto.so.1.1
76e2b000-76e42000 00186000 94208 /usr/lib/libcrypto.so.1.1
76e42000-76e43000 0019d000 4096 /usr/lib/libcrypto.so.1.1
76e47000-76e93000 00000000 311296 /usr/lib/libssl.so.1.1
76e93000-76ea3000 0004c000 65536 /usr/lib/libssl.so.1.1
76ea3000-76ea8000 0004c000 20480 /usr/lib/libssl.so.1.1
76ea8000-76eab000 00051000 12288 /usr/lib/libssl.so.1.1
76eab000-76eb4000 00000000 36864 /apps/app/lib/libtidc.so
76eb4000-76ec3000 00009000 61440 /apps/app/lib/libtidc.so
76ec3000-76ec4000 00008000 4096 /apps/app/lib/libtidc.so
76ec4000-76ec5000 00009000 4096 /apps/app/lib/libtidc.so
76ec5000-76f68000 00000000 667648 /usr/lib/libsqlite3.so.0.8.6
76f68000-76f77000 000a3000 61440 /usr/lib/libsqlite3.so.0.8.6
76f77000-76f79000 000a2000 8192 /usr/lib/libsqlite3.so.0.8.6
76f79000-76f7b000 000a4000 8192 /usr/lib/libsqlite3.so.0.8.6
76f7b000-76f8a000 00000000 61440 /lib/libz.so.1.2.11
76f8a000-76f9a000 0000f000 65536 /lib/libz.so.1.2.11
76f9a000-76f9b000 0000f000 4096 /lib/libz.so.1.2.11
76f9b000-76f9c000 00010000 4096 /lib/libz.so.1.2.11
76f9c000-76fb5000 00000000 102400 /lib/ld-2.30.so
76fc4000-76fc5000 00018000 4096 /lib/ld-2.30.so
76fc5000-76fc6000 00019000 4096 /lib/ld-2.30.so
CORE 116 FPREGSET
f0: 0x000000000000000000000000 f1: 0x000000000000000000000000
f2: 0x000000000000000000000000 f3: 0x000000000000000000000000
f4: 0x000000000000000000000000 f5: 0x000000000000000000000000
f6: 0x000000000000000000000000 f7: 0x000000000000000000000000
LINUX 260 ARM_VFP
fpscr: 0x656e6e6f
d0: 0x64657463656e6e6f d1: 0x0000000000000000
d2: 0x0000000000000000 d3: 0x0000000000000000
d4: 0x0000000000000000 d5: 0x0000000000000000
d6: 0x0000000000000000 d7: 0x0000000000000000
d8: 0x0000000000000000 d9: 0x0000000000000000
d10: 0x0000000000000000 d11: 0x0000000000000000
d12: 0x0000000000000000 d13: 0x0000000000000000
d14: 0x0000000000000000 d15: 0x0000000000000000
d16: 0xffffffffffffffff d17: 0x4059000000000000
d18: 0x412e848000000000 d19: 0x0000000000000000
d20: 0x0000000000000000 d21: 0x0000000000000000
d22: 0x0000000000000000 d23: 0x0000000000000000
d24: 0x0000000000000000 d25: 0x0000000000000000
d26: 0x0000000000000000 d27: 0x0000000000000000
d28: 0x0000000000000000 d29: 0x0000000000000000
d30: 0x0000000000000000 d31: 0x0000000000000000
CORE 148 PRSTATUS
info.si_signo: 11, info.si_code: 0, info.si_errno: 0, cursig: 11
sigpend: <>
sighold: <>
pid: 14608, ppid: 4103, pgrp: 14597, sid: 4103
utime: 0.330000, stime: 0.420000, cutime: 0.000000, cstime: 0.000000
orig_r0: 8183760, fpvalid: 1
r0: 8183760 r1: 128 r2: 0 r3: 0
r4: 8183760 r5: 8183720 r6: 0 r7: 240
r8: 0 r9: 0 r10: 1989361680 r11: 0
r12: 240 sp: 0x76933fe0 lr: 0x76a4bd29 pc: 0x76a50b24
spsr: 0x800f0030
CORE 116 FPREGSET
f0: 0x000000000000000000000000 f1: 0x000000000000000000000000
f2: 0x000000000000000000000000 f3: 0x000000000000000000000000
f4: 0x000000000000000000000000 f5: 0x000000000000000000000000
f6: 0x000000000000000000000000 f7: 0x000000000000000000000000
LINUX 260 ARM_VFP
fpscr: 0x6f662067
d0: 0x756d20726f662067 d1: 0x223a226449746669
d2: 0xa52c550358ebcb70 d3: 0x673aecbbd5d48f94
d4: 0x8e24e4fea9d1060d d5: 0x1e3d32fb3006e21d
d6: 0x447a0000f9a47218 d7: 0x0000000000000000
d8: 0x0000000000000000 d9: 0x0000000000000000
d10: 0x0000000000000000 d11: 0x0000000000000000
d12: 0x0000000000000000 d13: 0x0000000000000000
d14: 0x0000000000000000 d15: 0x0000000000000000
d16: 0x0000000000000000 d17: 0x0000000000000000
d18: 0x0000000000000000 d19: 0x0000000000000000
d20: 0x0000000000000000 d21: 0x0000000000000000
d22: 0x0000000000000000 d23: 0x0000000000000000
d24: 0x0000000000000000 d25: 0x0000000000000000
d26: 0x0000000000000000 d27: 0x0000000000000000
d28: 0x0000000000000000 d29: 0x0000000000000000
d30: 0x0000000000000000 d31: 0x0000000000000000
which confirms the information is there in the core file.
I have a library which has a following variables:
const static volatile int64_t head1 = 0xffffffffffffffff;
const static volatile int64_t head2 = 0xffffffffffffffff;
const static volatile int64_t seed = 1;
const static volatile int64_t tail1 = 0xffffffffffffffff;
const static volatile int64_t tail2 = 0xffffffffffffffff;
I've compiled it to the library file as libnantoka.a. Then linked into the go module by the cgo as follows:
/*
#cgo LDFLAGS: -L. -lssl -lcrypto -lpthread -ldl -lm -lnantoka
#include <nantoka.h>
#include <stdbool.h>
*/
import "C"
Then, created executable file main by go build -o main main.go
I've found the offset address of seed by pattern matching by binary as follows:
od -A x -x main | grep "0001 0000 0000 0000"
0d61f0 ffff ffff ffff ffff 0001 0000 0000 0000
It's seems that the offset address of symbol seed might be 0xd61f8. Also, I've made sure as follows:
od -A x -x -j 0xd61e0 main | head -n4
0d61e0 7472 000a 0000 0000 ffff ffff ffff ffff
0d61f0 ffff ffff ffff ffff 0001 0000 0000 0000
0d6200 ffff ffff ffff ffff ffff ffff ffff ffff
0d6210 3130 3332 3534 3736 3938 3130 3332 3534
It indicates that 0xd61f8 must be the 64bit int with value 1, between 128bit all "f". I've be sure of that the offset address of the symbol seed must be 0xd61f8.
But, the result of nm is surprisingly that:
nm main | grep seed
000e61f8 r seed
The result e61f8 must be the offset address from the start of .rodata segment, but bigger than the real offset address from the file top!
I'm confusing why nm reports so big wrong offset? I really appreciate any suggestions from you! Thank you.
By the way, the environment is Raspberry Pi model B, go version is 1.13.5 as follows:
uname -a
Linux raspberrypi 4.19.50+ #896 Thu Jun 20 16:09:52 BST 2019 armv6l GNU/Linux
go version
go version go1.13.5 linux/arm
Also section infos of the main is as follows:
Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 00000019 00010174 00010174 00000174 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .note.ABI-tag 00000020 00010190 00010190 00000190 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .note.go.buildid 00000064 000101b0 000101b0 000001b0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .note.gnu.build-id 00000024 00010214 00010214 00000214 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .gnu.hash 00000568 00010238 00010238 00000238 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .dynsym 00000b70 000107a0 000107a0 000007a0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .dynstr 00000974 00011310 00011310 00001310 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .gnu.version 0000016e 00011c84 00011c84 00001c84 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .gnu.version_r 000000a0 00011df4 00011df4 00001df4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .rel.dyn 00000020 00011e94 00011e94 00001e94 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .rel.plt 00000368 00011eb4 00011eb4 00001eb4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
11 .init 0000000c 0001221c 0001221c 0000221c 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
12 .plt 00000530 00012228 00012228 00002228 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .text 00094338 00012758 00012758 00002758 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
14 .fini 00000008 000a6a90 000a6a90 00096a90 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
15 .rodata 0004001c 000a6a98 000a6a98 00096a98 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
16 .typelink 00000cfc 000e6ab8 000e6ab8 000d6ab8 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
17 .itablink 0000002c 000e77b4 000e77b4 000d77b4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
18 .gopclntab 0005fd79 000e77e0 000e77e0 000d77e0 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
19 .ARM.exidx 00000008 0014755c 0014755c 0013755c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
20 .eh_frame 00000004 00147564 00147564 00137564 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
21 .tbss 00000008 00157ee8 00157ee8 00137ee8 2**2
ALLOC, THREAD_LOCAL
I have an STM32 project involving a linkerscript which is designed to cap off the end of the image with a ".firmware_header" section. The idea is that this header contains the crc of the image, and there should be no content after this point. However, when I do
arm-none-eabi-objcopy firmware.elf -O binary firmware.bin
there exists some data after the last section which for some reason is required for the image to boot. If I zero this mystery block, the image fails to boot. The first question is, from the elf sections I see, there should be no sections after .firmware_header, where is the data coming from? The second question is, why is this data required at boot? My linker script, readelf output, and a screenshot of the mystery data is below.
ENTRY(Reset_Handler)
MEMORY
{
FLASH (RX) : ORIGIN = 0x08020000, LENGTH = 896K
SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 512K
BKPSRAM (RW) : ORIGIN = 0x40024000, LENGTH = 4K
}
_estack = 0x20080000;
SECTIONS
{
.isr_vector :
{
. = ALIGN(4);
_isr_vector = .;
KEEP(*(.isr_vector))
. = ALIGN(4);
} > FLASH
.firmware_header_vector :
{
. = ALIGN(4);
KEEP(*(.firmware_header_vector))
. = ALIGN(4);
} > FLASH
.text :
{
. = ALIGN(4);
_stext = .;
*(.Reset_Handler)
*(.text)
*(.text*)
*(.rodata)
*(.rodata*)
*(.glue_7)
*(.glue_7t)
KEEP(*(.init))
KEEP(*(.fini))
. = ALIGN(4);
_etext = .;
} > FLASH
.ARM.extab :
{
. = ALIGN(4);
*(.ARM.extab)
*(.gnu.linkonce.armextab.*)
. = ALIGN(4);
} > FLASH
.exidx :
{
. = ALIGN(4);
PROVIDE(__exidx_start = .);
*(.ARM.exidx*)
. = ALIGN(4);
PROVIDE(__exidx_end = .);
} > FLASH
.preinit_array :
{
PROVIDE(__preinit_array_start = .);
KEEP(*(.preinit_array*))
PROVIDE(__preinit_array_end = .);
} > FLASH
.init_array :
{
PROVIDE(__init_array_start = .);
KEEP(*(SORT(.init_array.*)))
KEEP(*(.init_array*))
PROVIDE(__init_array_end = .);
} > FLASH
.fini_array :
{
PROVIDE(__fini_array_start = .);
KEEP(*(.fini_array*))
KEEP(*(SORT(.fini_array.*)))
PROVIDE(__fini_array_end = .);
} > FLASH
.firmware_header :
{
. = ALIGN(4);
KEEP(*(.firmware_header))
. = ALIGN(4);
} > FLASH
. = ALIGN(4);
_sidata = .;
.data : AT(_sidata)
{
. = ALIGN(4);
_sdata = .;
PROVIDE(__data_start__ = _sdata);
*(.data)
*(.data*)
. = ALIGN(4);
_edata = .;
PROVIDE(__data_end__ = _edata);
} > SRAM
.bss :
{
. = ALIGN(4);
_sbss = .;
PROVIDE(__bss_start__ = _sbss);
*(.bss)
*(.bss*)
*(COMMON)
. = ALIGN(4);
_ebss = .;
PROVIDE(__bss_end__ = _ebss);
} > SRAM
PROVIDE(end = .);
.heap (NOLOAD) :
{
. = ALIGN(4);
PROVIDE(__heap_start__ = .);
KEEP(*(.heap))
. = ALIGN(4);
PROVIDE(__heap_end__ = .);
} > SRAM
.reserved_for_stack (NOLOAD) :
{
. = ALIGN(4);
PROVIDE(__reserved_for_stack_start__ = .);
KEEP(*(.reserved_for_stack))
. = ALIGN(4);
PROVIDE(__reserved_for_stack_end__ = .);
} > SRAM
.battery_backed_sram (NOLOAD) :
{
. = ALIGN(4);
KEEP(*(.battery_backed_sram))
. = ALIGN(4);
} > BKPSRAM
/DISCARD/ :
{
*(.ARM.attributes)
}
}
arm-none-eabi-readelf -a ./fw.elf:
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: 0x8027c11
Start of program headers: 52 (bytes into file)
Start of section headers: 339928 (bytes into file)
Flags: 0x5000400, Version5 EABI, hard-float ABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 40 (bytes)
Number of section headers: 25
Section header string table index: 24
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .isr_vector PROGBITS 08020000 010000 0001f8 00 WA 0 0 4
[ 2] .firmware_header_ PROGBITS 080201f8 0101f8 000004 00 WA 0 0 4
[ 3] .text PROGBITS 08020200 010200 021b44 00 AX 0 0 64
[ 4] .ARM.extab PROGBITS 08041d44 043a68 000000 00 W 0 0 1
[ 5] .exidx ARM_EXIDX 08041d44 031d44 000008 00 AL 3 0 4
[ 6] .init_array INIT_ARRAY 08041d4c 031d4c 000008 04 WA 0 0 4
[ 7] .fini_array FINI_ARRAY 08041d54 031d54 000004 04 WA 0 0 4
[ 8] .firmware_header PROGBITS 08041d58 031d58 000008 00 WA 0 0 4
[ 9] .data PROGBITS 20000000 040000 0009c8 00 WA 0 0 8
[10] .RxDecripSection PROGBITS 200009c8 0409c8 000080 00 WA 0 0 4
[11] .RxarraySection PROGBITS 20000a48 040a48 0017d0 00 WA 0 0 4
[12] .TxDescripSection PROGBITS 20002218 042218 000080 00 WA 0 0 4
[13] .TxarraySection PROGBITS 20002298 042298 0017d0 00 WA 0 0 4
[14] .bss NOBITS 20003a68 043a68 045da4 00 WA 0 0 4
[15] .heap PROGBITS 2004980c 043a68 000000 00 W 0 0 1
[16] .reserved_for_sta PROGBITS 2004980c 043a68 000000 00 W 0 0 1
[17] .battery_backed_s NOBITS 40024000 044000 00000c 00 WA 0 0 4
[18] .comment PROGBITS 00000000 043a68 000075 01 MS 0 0 1
[19] .debug_frame PROGBITS 00000000 043ae0 00144c 00 0 0 4
[20] .stab PROGBITS 00000000 044f2c 000084 0c 21 0 4
[21] .stabstr STRTAB 00000000 044fb0 000117 00 0 0 1
[22] .symtab SYMTAB 00000000 0450c8 009b30 10 23 1790 4
[23] .strtab STRTAB 00000000 04ebf8 0042bb 00 0 0 1
[24] .shstrtab STRTAB 00000000 052eb3 000122 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
y (purecode), p (processor specific)
There are no section groups in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x010000 0x08020000 0x08020000 0x21d60 0x21d60 RWE 0x10000
LOAD 0x040000 0x20000000 0x08041d60 0x03a68 0x4980c RW 0x10000
LOAD 0x044000 0x40024000 0x40024000 0x00000 0x0000c RW 0x10000
Turns out this is an issue with the definition of the .data section. It's getting loaded after .firmware_header. Interesting that this wasn't made more clear in readefl, etc output. Solved!
I compiled a simple C program (gcc -o file file.cpp) and obtained the following output on running objdump -h file,
12 .text 00000172 0000000000400400 0000000000400400 00000400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .fini 00000009 0000000000400574 0000000000400574 00000574 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
I have a quick question here.
Why is there a gap of 2 bytes after the .text section? 0x400400 + 0x172 = 0x400572, but the .fini section starts from 0x400574? Has this got something to do with alignment? I noticed similar gaps between some other sections as well.
The last column of the output from objdump -h file is the alignment of the section. The alignment of .fini is 4 (2**2 is 2 to the power of 2), which is why it starts at 0x400574 instead of 0x400572.
When linking against glibc for x86-64, the alignment of 4 for the .fini section is specified in crti.o:
.section .fini,"ax",#progbits
.p2align 2
.globl _fini
.type _fini, #function
_fini:
I need to determine the VMAs for loadable segments of ELF executables. VMAs can be printed from /proc/pid/maps. The relationship between VMAs shown by maps with loadable segments is also clear to me. Each segment consists of one or more VMAs. what is the method used by kernel to form VMAs from ELF segments: whteher it takes into consideration only permissions/flags or something else is also required? As per my understanding, a segment with flags Read, Execute(code) will go in separate VMA having same permission. While next segment with permissions Read, Write(data) should go in an other VMA. But this is not case with second loadable segment, it is usually splitted in two or more VMAs: some with read and write while other with read only. So My assumption that flags are the only culprit for VMA generation seems wrong. I need help to understand this relationship between segments and VMAs.
What I want to do is to programmatically determine the VMAs for loadable segments of ELF with out loading it in memory. So any pointer/help in this direction is the main objective of this post.
A VMA is a homogeneous region of virtual memory with:
the same permissions (PROT_EXEC, etc.);
the same type (MAP_SHARED/MAP_PRIVATE);
the same backing file (if any);
a consistent offset within the file.
For example, if you have a VMA which is RW and you mprotect PROT_READ (you remove the permission to write) a part in the middle of the VMA, the kernel will split the VMA in three VMAs (the first one being RW, the second R and the last RW).
Let's look at a typical VMA from an executable:
$ cat /proc/$$/maps
00400000-004f2000 r-xp 00000000 08:01 524453 /bin/bash
006f1000-006f2000 r--p 000f1000 08:01 524453 /bin/bash
006f2000-006fb000 rw-p 000f2000 08:01 524453 /bin/bash
006fb000-00702000 rw-p 00000000 00:00 0
[...]
The first VMA is the text segment. The second, third and fourth VMAs are the data segment.
Anonymous mapping for .bss
At the beginning of the process, you will have something like this:
$ cat /proc/$$/maps
00400000-004f2000 r-xp 00000000 08:01 524453 /bin/bash
006f1000-006fb000 rw-p 000f1000 08:01 524453 /bin/bash
006fb000-00702000 rw-p 00000000 00:00 0
[...]
006f1000-006fb000 is the part of the text segment which comes from the executable file.
006fb000-00702000 is not present in the executable file because it is initially filled with zeroes. The non-initialized variables of the process are all grouped together (in the .bss segment) and are not represented in the executable file in order to save space (1).
This come from the PT_LOAD entries of the program header table of the executable file (readelf -l) which describe the segments to map into memory:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
[...]
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x00000000000f1a74 0x00000000000f1a74 R E 200000
LOAD 0x00000000000f1de0 0x00000000006f1de0 0x00000000006f1de0
0x0000000000009068 0x000000000000f298 RW 200000
[...]
If you look at the corresponding PT_LOAD entry, you will notice that a part of the the segment is not represented in the file (because the file size is smaller than the memory size).
The part of the data segment which is not in the executable file is initialized with zeros: the dynamic linker uses a MAP_ANONYMOUS mapping for this part of the data segment. This is why is appears as a separate VMA (it does not have the same backing file).
Relocation protection (PT_GNU_RELRO)
When the dynamic, linker has finished doing the relocations (2), it might mark some part of the data segment (the .got section among others) as read-only in order to avoid GOT-poisoning attacks or bugs. The section of the data segment which should be protected after the relocations in described by the PT_GNU_RELRO entry of the program header table: the dynamic linker mprotect(addr, len, PROT_READ) the given region after finishing the relocations (3). This mprotect call splits the second VMA in two VMAs (the first one R and the second one RW).
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
[...]
GNU_RELRO 0x00000000000f1de0 0x00000000006f1de0 0x00000000006f1de0
0x0000000000000220 0x0000000000000220 R
[...]
Summary
The VMAs
00400000-004f2000 r-xp 00000000 08:01 524453 /bin/bash
006f1000-006f2000 r--p 000f1000 08:01 524453 /bin/bash
006f2000-006fb000 rw-p 000f2000 08:01 524453 /bin/bash
006fb000-00702000 rw-p 00000000 00:00 0
are derived from the VirtAddr, MemSiz and Flags fields of the PT_LOAD and PT_GNU_RELRO entries:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
[...]
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x00000000000f1a74 0x00000000000f1a74 R E 200000
LOAD 0x00000000000f1de0 0x00000000006f1de0 0x00000000006f1de0
0x0000000000009068 0x000000000000f298 RW 200000
[...]
GNU_RELRO 0x00000000000f1de0 0x00000000006f1de0 0x00000000006f1de0
0x0000000000000220 0x0000000000000220 R
[...]
First all PT_LOAD entries are processes. Each of them triggers the creation of one VMA by using a mmap(). In addition, if MemSiz > FileSiz, it might create an additional anonymous VMA.
Then all (well there is only once in pratice) PT_GNU_RELRO are processes. Each of them triggers a mprotect() call which might split an existing VMA into different VMAs.
In order to do what you want, the correct way is probably to simulate the mmap and mprotect calls:
// Virtual Memory Area:
struct Vma {
std::uint64_t addr, length;
std::string file_name;
int prot;
int flags;
std::uint64_t offset;
};
// Virtual Address Space:
class Vas {
private:
std::list<Vma> vmas_;
public:
Vma& mmap(
std::uint64_t addr, std::uint64_t length, int prot,
int flags, int fd, off_t offset);
int mprotect(std::uint64_t addr, std::uint64_t len, int prot);
std::list<Vma> const& vmas() const { return vmas_; }
};
for (Elf32_Phdr const& h : phdrs)
if (h.p_type == PT_LOAD) {
vas.mmap(...);
if (anon_size)
vas.mmap(...);
}
for (Elf32_Phdr const& h : phdrs)
if (h.p_type == PT_GNU_RELRO)
vas.mprotect(...);
Some examples of computations
The addresses are slightly different because the VMAs are page-aligned (3) (using 4Kio = 0x1000 pages for x86 and x86_64):
The first VMA is describes by the first PT_LOAD entry:
vma[0].start = page_floor(load[0].virt_addr)
= 0x400000
vma[0].end = page_ceil(load[1].virt_addr + load[1].phys_size)
= page_ceil(0x400000 + 0xf1a74)
= page_ceil(0x4f1a74)
= 0x4f2000
The next VMA is the part of the data segment which as been protected and is described by PT_GNU_RELRO:
vma[1].start = page_floor(relro[0].virt_addr)
= page_floor(0xf1de0)
= 0x6f1000
vma[1].end = page_ceil(relro[0].virt_addr + relo[0].mem_size)
= page_ceil(0x6f1de0 + 0x220)
= page_ceil(0x6f2000)
= 0x6f2000
[...]
Correspondence with the sections
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .interp PROGBITS 0000000000400238 00000238
000000000000001c 0000000000000000 A 0 0 1
[ 2] .note.ABI-tag NOTE 0000000000400254 00000254
0000000000000020 0000000000000000 A 0 0 4
[ 3] .note.gnu.build-i NOTE 0000000000400274 00000274
0000000000000024 0000000000000000 A 0 0 4
[ 4] .gnu.hash GNU_HASH 0000000000400298 00000298
0000000000004894 0000000000000000 A 5 0 8
[ 5] .dynsym DYNSYM 0000000000404b30 00004b30
000000000000d6c8 0000000000000018 A 6 1 8
[ 6] .dynstr STRTAB 00000000004121f8 000121f8
0000000000008c25 0000000000000000 A 0 0 1
[ 7] .gnu.version VERSYM 000000000041ae1e 0001ae1e
00000000000011e6 0000000000000002 A 5 0 2
[ 8] .gnu.version_r VERNEED 000000000041c008 0001c008
00000000000000b0 0000000000000000 A 6 2 8
[ 9] .rela.dyn RELA 000000000041c0b8 0001c0b8
00000000000000c0 0000000000000018 A 5 0 8
[10] .rela.plt RELA 000000000041c178 0001c178
00000000000013f8 0000000000000018 AI 5 12 8
[11] .init PROGBITS 000000000041d570 0001d570
000000000000001a 0000000000000000 AX 0 0 4
[12] .plt PROGBITS 000000000041d590 0001d590
0000000000000d60 0000000000000010 AX 0 0 16
[13] .text PROGBITS 000000000041e2f0 0001e2f0
0000000000099c42 0000000000000000 AX 0 0 16
[14] .fini PROGBITS 00000000004b7f34 000b7f34
0000000000000009 0000000000000000 AX 0 0 4
[15] .rodata PROGBITS 00000000004b7f40 000b7f40
000000000001ebb0 0000000000000000 A 0 0 64
[16] .eh_frame_hdr PROGBITS 00000000004d6af0 000d6af0
000000000000407c 0000000000000000 A 0 0 4
[17] .eh_frame PROGBITS 00000000004dab70 000dab70
0000000000016f04 0000000000000000 A 0 0 8
[18] .init_array INIT_ARRAY 00000000006f1de0 000f1de0
0000000000000008 0000000000000000 WA 0 0 8
[19] .fini_array FINI_ARRAY 00000000006f1de8 000f1de8
0000000000000008 0000000000000000 WA 0 0 8
[20] .jcr PROGBITS 00000000006f1df0 000f1df0
0000000000000008 0000000000000000 WA 0 0 8
[21] .dynamic DYNAMIC 00000000006f1df8 000f1df8
0000000000000200 0000000000000010 WA 6 0 8
[22] .got PROGBITS 00000000006f1ff8 000f1ff8
0000000000000008 0000000000000008 WA 0 0 8
[23] .got.plt PROGBITS 00000000006f2000 000f2000
00000000000006c0 0000000000000008 WA 0 0 8
[24] .data PROGBITS 00000000006f26c0 000f26c0
0000000000008788 0000000000000000 WA 0 0 64
[25] .bss NOBITS 00000000006fae80 000fae48
00000000000061f8 0000000000000000 WA 0 0 64
[26] .shstrtab STRTAB 0000000000000000 000fae48
00000000000000ef 0000000000000000 0 0 1
It you compare the Address of the sections (readelf -S) with the ranges of the VMAs, you find the mappings:
00400000-004f2000 r-xp /bin/bash : .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
006f1000-006f2000 r--p /bin/bash : .init_array, .fini_array, .jcr, .dynamic, .got
006f2000-006fb000 rw-p /bin/bash : .got.plt, .data, beginning of .bss
006fb000-00702000 rw-p - : rest of .bss
Notes
(1): In fact, its more complicated: a part of the .bss section might be represented in the executable file for page alignment reasons.
(2): In fact, when it has finished doing the non-lazy relocations.
(3): MMU operations are using the page-granularity so the memory ranges of mmap(), mprotect(), munmap() calls are extended to cover full-pages.