Index
> Projects and Ideas > fasm 2 as a set of scripts and headers for fasmg |
| Author |
|
|
Tomasz Grysztar 11 Jul 2023, 22:31
After updating my advanced x86 encoder prototype I decided to finally combine it with the existing set of fasm compatibility headers and demonstrate the vision I had for fasm 2.
This is a self-contained package, which includes the fasmg binary, set of include files and "fasm2" script that launches fasmg with the x86 instruction sets and formats automatically included (and the environment set up with headers like "win32ax.inc" available if sources need them). This provides a non-trivial level of compatibility with fasm 1 out of the box. As long as the sources do not use the {} syntax of fasm's preprocessor, there is a high chance they can be assembled with this prototype (and in some simple cases it is enough to replace braces with appropriate statements like "end rept" or "end macro", but proceed with caution). In fact, both FASMD.ASM and FASMW.ASM from the standard fasm 1 distribution can be assembled with no changes and no additional setup. That being said, it is just a prototype that I expect to fail in many ways when confronted with new environments and source bases. It has only Win32 and x64 Linux versions of fasmg binaries, so if you need a different one for your system, you should get the complete fasmg package separately. The purpose of this preview is to demonstrate what I envisioned fasm 2 could be. I do not promise to keep working on it.
|
|||||||||||
11 Jul 2023, 22:31 |
|
|
Roman 12 Jul 2023, 13:03
fasm 2 this is fasmg or grounded on fasmg ?
What difference fasm 2 and fasmg ? |
|||
|
12 Jul 2023, 13:03 |
|
|
Tomasz Grysztar 13 Jul 2023, 20:24
As a demonstration of what a transitional project could look like, here's a source code of fasmg that I simplified into a form that can be assembled with fasm or fasm2 (except for the Mach-O variant, which is unsupported by fasm). Almost everything is directly compatible, except for tricky variants (x64, DLL) that require special macros (there I still used the trick to include either the .INC variant for fasm, or .ALM variant for fasm2).
Changes from the standard source code of fasmg are limited to subdirectories with specific OS interfaces.
|
|||||||||||
|
13 Jul 2023, 20:24 |
|
|
vityacv 16 Jul 2023, 08:26
In include file
\include\equates\gdi64.inc there seems some extra text on structure definition 'packed' struct BITMAPFILEHEADER, packed probably compiler should return error on this? sample: Code: format binary Main: ret align 16 error while compiling: Code: Processed: align 16 Error: illegal instruction. If you try to create: Code: format PE64 as 'bin' entry Main Main: ret compiler returns: Code: macro format?.PE64? [54] Custom error: invalid argument. For PE64 format shoud we set flag IMAGE_DLLCHARACTERISTICS_HIGH_ENTROPY_VA as default? What about no reloc data and ASLR: Code: data fixups dd 0,8 <- can it be created automatically? end data In PE, MajorLinkerVersion\MinorLinkerVersion probably can fill with 2.0 instead of 0's "Extended implementation of anonymous labels", will be included later? |
|||
|
16 Jul 2023, 08:26 |
|
|
Tomasz Grysztar 16 Jul 2023, 08:43
vityacv wrote: In include file vityacv wrote: What about no reloc data and ASLR: vityacv wrote: "Extended implementation of anonymous labels", will be included later? |
|||
|
16 Jul 2023, 08:43 |
|
|
vityacv 23 Jul 2023, 06:05
Works perfectly with latest changes, thanks!
There's another sample that doesn't compile Code: format binary use64 struct IMAGE_DOS_HEADER e_magic rw 1 e_cblp rw 1 e_cp rw 1 e_crlc rw 1 e_cparhdr rw 1 e_minalloc rw 1 e_maxalloc rw 1 e_ss rw 1 e_sp rw 1 e_csum rw 1 e_ip rw 1 e_cs rw 1 e_lfarlc rw 1 e_ovno rw 1 e_res rw 4 e_oemid rw 1 e_oeminfo rw 1 e_res2 rw 10 e_lfanew rd 1 ends teste IMAGE_DOS_HEADER 'MZ',0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,testq.size testq: mov rax,1 ret align 4 testq.size = $-teste If you try to use Code: teste IMAGE_DOS_HEADER 'MZ',0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 IMAGE_DOS_HEADER [2] struct?.instantiate [62] Custom error: value too long to fit in e_magic. if I fill e_magic with 0 but e_lfanew with value Code: teste IMAGE_DOS_HEADER 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,testq.size Error: not enough memory to complete the assembly. if you use 0's as initializer it compiles Code: teste IMAGE_DOS_HEADER 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 |
|||
|
23 Jul 2023, 06:05 |
|
|
Tomasz Grysztar 23 Jul 2023, 07:54
The version of STRUCT that is currently included in the compatibility package executes the data directive with values in the arguments. This works with any data types that contain the value in the statement (without knowing what they might be - as opposed to the limited catalogue of supported data statements in fasm'1 version of macro), but cannot work with statements like RW where the argument is the size and not the value.
As discussed in the thread about STRUCT there are various directions we could go when implementing it. I've chosen this variant when building the package because it is the most robust one I have available for fasmg right now. This particular version is the most similar to built-in STRUC, as it basically defines a macro, a freely formed collection of statements, and the values are injected into these statements as the macro is executed to instantiate the structure. Another potential approach (also discussed in the linked thread) would be to make it gather labeled data definitions, while processing all other statements (including control directives) during the definition time. Then at the time of instantiation, the collected data fields would be generated with EMIT instead of calling the original statements that defined it. I have not written such variant, though, so I could not use it here. |
|||
|
23 Jul 2023, 07:54 |
|
< Last Thread | Next Thread > |
Forum Rules:
|