flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
revolution 28 Jan 2022, 01:28
Please show your source code that produces the wrong output.
|
|||
![]() |
|
bugmaker 28 Jan 2022, 10:15
The second segment will be in memory region 401000-402000. But do contain the file.
So the mov content of al will go to address 0x4010c4 in this example. While I made the ELF from scratch with the content of second programheader as described in the post, nothing would be loaded in that memory region, data: would be at address 0x401000 Code: use64 format ELF64 executable 3 entry main segment readable executable main: mov al,0xff mov [dataseg],al xor rdi,rdi mov rax,60 syscall segment readable writeable dataseg: rb 1 Last edited by bugmaker on 28 Jan 2022, 12:38; edited 2 times in total |
|||
![]() |
|
revolution 28 Jan 2022, 11:08
If you use rb 1 then there is no data to put into the output file. It is an empty segment of only uninitialised data.
If you change the last line to db 0xff then data is put into the output file. |
|||
![]() |
|
bugmaker 28 Jan 2022, 12:36
I do not really know what i'm talking about btw.
But there is some odd ways data is loaded into memory. In the code below, everything is loaded as part of read + execute segment 0x400000 - 0x402000, what's in the second segment is included as well, as part of it. Then there's the second segment, where only part of the 0xff are shown, then all the 0x88. So what i'm getting at is what is the point of loading the same data twice, what is going on? Code: use64 format ELF64 executable 3 entry main segment readable executable main: mov al,0xff mov [dataseg],al xor rdi,rdi mov rax,60 syscall db 0x1000 dup 0xff segment readable writeable dataseg: db 0x1000 dup 0x88 |
|||
![]() |
|
revolution 28 Jan 2022, 12:55
The loader used by your OS might make shortcuts when laying out the code into memory. It isn't required to zero out undefined memory locations so the data could be anything.
The only guarantee you have is that the addresses that have defined location in the file will be correctly initialised into the memory. Other memory locations are undefined and may contain any values. This does not break the loader contract. |
|||
![]() |
|
FlierMate 28 Jan 2022, 15:24
bugmaker wrote:
I run your example and a "readelf -a" produces: Code: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x00000000000000c4 0x00000000000000c4 R E 0x1000 LOAD 0x00000000000000c4 0x00000000004010c4 0x00000000004010c4 0x0000000000000000 0x0000000000000001 RW 0x1000 Can notice the VirtAddr and PhysAddr of second segment starts at 0x4010c4 (c4 = 196 bytes, the size of entire program), whereas your custom program header fixed the VirtAddr at 0x401000. Is this your finding? |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.