flat assembler
Message board for the users of flat assembler.
Index
> Compiler Internals > format elf(64) executable segment alignment |
Author |
|
revolution 21 Oct 2023, 00:22
The alignment is correct for the ELF format. The "Align" column shows 0x1000 (4096).
The offset of 0x78 is just how ELF works. |
|||
21 Oct 2023, 00:22 |
|
revolution 21 Oct 2023, 00:32
I made a patched version to show that it doesn't work when the segment offset is 0x00.
Code: format elf executable 3 at 0x10000 entry start segment readable executable start: mov eax,[0x11000] int 0x80 segment readable exit_code: dd 1 Code: EElf file type is EXEC (Executable file) Entry point 0x10074 There are 2 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x00010000 0x00010000 0x0007b 0x0007b R E 0x1000 LOAD 0x00007b 0x00011000 0x00011000 0x00004 0x00004 R 0x1000 Code: Segmentation fault |
|||
21 Oct 2023, 00:32 |
|
s54820 21 Oct 2023, 01:41
revolution wrote: The alignment is correct for the ELF format. The "Align" column shows 0x1000 (4096). Yes, it is sort of correct. In ELF terms. But then fasm documentation is wrong. revolution wrote: I made a patched version to show that it doesn't work when the segment offset is 0x00. I made a patched version to show that is does work. You have to align^W make sure that both virtual address and an offset match mod (whatever you put in p_align). Code: Elf file type is EXEC (Executable file) Entry point 0x10074 There are 2 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x00010000 0x00010000 0x0007b 0x0007b R E 0x1000 LOAD 0x001000 0x00011000 0x00011000 0x00004 0x00004 R 0x1000
Last edited by s54820 on 21 Oct 2023, 01:51; edited 1 time in total |
|||||||||||
21 Oct 2023, 01:41 |
|
revolution 21 Oct 2023, 01:48
s54820 wrote: I made a patched version to show that is does work. You have to align both virtual address and an offset to whatever you put in p_align. Using the same code I posted above and patching the offset: Code: ~ fdbg ./s54820 0000000000010074 > mov eax,[00011000] ; []=464C457F |
|||
21 Oct 2023, 01:48 |
|
s54820 21 Oct 2023, 01:56
revolution wrote: Using the same code I posted above and patching the offset. And inserting almost 4K bytes to make an offset correct? ;-) Code: 0x00010074 in ?? () => 0x00010074: a1 00 10 01 00 mov eax,ds:0x11000 (gdb) x/4xb 0x11000 0x11000: 0x01 0x00 0x00 0x00 |
|||
21 Oct 2023, 01:56 |
|
revolution 21 Oct 2023, 02:03
s54820 wrote: [And inserting almost 4K bytes to make an offset correct? If you need a particular alignment for your data you can do it. Code: format elf executable 3 at 0x10000 entry start segment readable executable start: mov eax,[exit_code] int 0x80 segment readable align 4096 exit_code: dd 1 Code: 0000000000010074 > mov eax,[00012000] ; []=00000001 ; perfect |
|||
21 Oct 2023, 02:03 |
|
s54820 21 Oct 2023, 03:51
Well, okay. It is not a bug, fasm saves some space in a file. But it certainly could be improved by having something like [tt]segment readable align 4096[/tt]
revolution wrote: It is the same format as used by the major tools like GCC and others. Not quite. "GCC and others" align at least some segments. If you inspect a random file with readelf -Wl /usr/bin/gcc | grep -A 1 'LOAD.*R E' you will see that both executable segment (.text) and the following segment (usually .rodata) have offsets and virtual addresses aligned to a page boundary: Code: LOAD 0x004000 0x0000000000404000 0x0000000000404000 0x114d71 0x114d71 R E 0x1000 LOAD 0x119000 0x0000000000519000 0x0000000000519000 0x0babb5 0x0babb5 R 0x1000 revolution wrote: If you need a particular alignment for your data you can do it. This way it inserts the same amount of bytes that it "saved" by making holes in memory. But okay, I can see now that this behavior is intentional and the documentation is wrong. |
|||
21 Oct 2023, 03:51 |
|
revolution 21 Oct 2023, 04:04
To have both the exe file and the in-memory layout appear at 4096 alignment then you have to pad with bytes, right? The Linux loader doesn't shift the bytes like Windows does. At least IME anyway. Has that changed lately?
Here is the result for GCC on my system. Code: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000040 0x0000000000400040 0x0000000000400040 0x000230 0x000230 R E 0x8 INTERP 0x000270 0x0000000000400270 0x0000000000400270 0x00001c 0x00001c R 0x1 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x0dcaac 0x0dcaac R E 0x200000 LOAD 0x0dcf20 0x00000000006dcf20 0x00000000006dcf20 0x001f98 0x004590 RW 0x200000 DYNAMIC 0x0dddf8 0x00000000006dddf8 0x00000000006dddf8 0x0001e0 0x0001e0 RW 0x8 NOTE 0x00028c 0x000000000040028c 0x000000000040028c 0x000044 0x000044 R 0x4 TLS 0x0dcf20 0x00000000006dcf20 0x00000000006dcf20 0x000000 0x000010 R 0x8 GNU_EH_FRAME 0x0ca394 0x00000000004ca394 0x00000000004ca394 0x002c74 0x002c74 R 0x4 GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10 GNU_RELRO 0x0dcf20 0x00000000006dcf20 0x00000000006dcf20 0x0010e0 0x0010e0 R 0x1 |
|||
21 Oct 2023, 04:04 |
|
revolution 21 Oct 2023, 04:06
s54820 wrote: ... the documentation is wrong. |
|||
21 Oct 2023, 04:06 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.