flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
revolution 13 May 2018, 14:43
If the data is marked as writable then you can overwrite it with some other data. Often either random bytes, or all zeros, is used to "erase" data in memory.
|
|||
![]() |
|
donn 13 May 2018, 21:29
"If it's doable, how do we do it? And is that useful? "
If you clear MyVar to zeroes, then it's useful since you are aware it's filled with zeroes (could indicate it's reset). You won't free up any space, however. You could use that same location with another label, though. There are different memory allocation strategies. One is to allocate and de-allocate memory through the OS. This can be helpful with big memory chunks. Some examples: 64-bit HeapFree on Windows: Code: sub rsp, 8*4 call [GetProcessHeap] add rsp, 8*4 mov [allocFree.heapAddress], rax ; Cache the process' heap address sub rsp, 8*4 mov r8, [allocFree.allocationAddress] ; Previously allocated address to free mov rdx, 0b mov rcx, [allocFree.heapAddress] call [HeapFree] add rsp, 8*4 VirtualAlloc (Windows) from fasm source: Code: ... mov eax,[memory_start] test eax,eax jz do_exit push MEM_RELEASE push 0 push eax call [VirtualFree] Libc from fasm source: Code: movzx eax,al push eax ccall free,[additional_memory] On Linux, glibc is an option, but so is FASMLIB. Some discussion on options here. |
|||
![]() |
|
Melissa 13 May 2018, 23:04
On linux there is sys_mmap syscall to allocate dynamicaly which libc uses internally and sys_brk to grow/shrink data segment.
|
|||
![]() |
|
vivik 14 May 2018, 09:36
In cases where you can't delete memory, you can reuse it for something else. Welcome to memory allocators.
You can make labels that point to the same locations. Be careful not to use both at the same time, very easy to make very hard to debug bugs. You can try if you feel brave. |
|||
![]() |
|
DimonSoft 14 May 2018, 10:31
Mino wrote: Hello, Let me guess you are trying to generate memory labelled block conditionally but the condition is quite complex so that FASM’s capabilities to “predict” values becomes unusable. You may then try to generate such block within virtual … end block and then use load and store directives to copy certain parts from there. |
|||
![]() |
|
Mino 14 May 2018, 17:34
All right, thanks for all your answers:)
Actually, I wanted to know that out of curiosity, and what it could do for me. The idea came to me when I used the delete statement in C++, but obviously, it doesn't do the same thing as a "simple" allocation; at least I think since it acts mainly on structured variables (and/or array), as well as on objects. While we're at it with memory and allocations, someone could explain to me what alloc and/or malloc (C source) looks like in native FASM (so without libraries)? I have already tried with a decompiler, but since these are preprocessor instructions, it is impossible for me to find the origin of allocations and deductions in the program... Thank you ![]() |
|||
![]() |
|
bitRAKE 14 May 2018, 23:11
When HLLs create an object they allocate memory - on the stack, or from the OS/API. At the low-level we must do these things ourselves. Delete is simply the freeing of those resources - which is obviously dependant on the method of allocation.
Without libraries one would need to use the stack or static memory area. |
|||
![]() |
|
Furs 15 May 2018, 12:15
Mino wrote: While we're at it with memory and allocations, someone could explain to me what alloc and/or malloc (C source) looks like in native FASM (so without libraries)? I have already tried with a decompiler, but since these are preprocessor instructions, it is impossible for me to find the origin of allocations and deductions in the program... However in the end they still end up calling the OS library, at least for the raw allocation (perhaps VirtualAlloc on Windows). Not on every allocation or free, though, just the initial block(s). You can't "avoid" calling an OS function or library when allocating unless you write your own operating system. Why are you so against using the OS facilities? They exist to serve you, and they're already there (when you use the OS), loaded in the kernel and so on, not using them in fact leads to even more bloat. I can understand not wanting to use a 3rd party 15MB library... but the OS already has it. |
|||
![]() |
|
revolution 15 May 2018, 12:20
You can preallocate memory in the exe file, but that only serves for static allocations. If you exceed that preallocation then you will need to find some way to get more memory assigned to your app. And that is what OSes are for. If you want fight the OS then you have an uphill battle ahead of you.
|
|||
![]() |
|
Mino 15 May 2018, 19:40
Very well, thank you I understand better:)
Don't worry, I don't suffer from the beginner's syndrome who often want to recreate everything by himself :p. I ask all this out of pure curiosity, and you never know, some things could be useful for my project. And so, in FASM, the use of the operating system library under Windows, is it well kernel32.inc? Should it then be imported at least to each project if we want a stable application (using its features of course)? Are the allocations functions also there (since in C/C++, they are MACRO)? |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.