Index
> DOS > bootstrapping FASM? |
| Author |
|
|
rugxulo 20 Feb 2018, 05:08
Someone in another subforum here (re: making a FASM package for Gentoo) mentioned the idea of bootstrapping FASM.
To me, the simplest way is to use an old DOS .COM version of FASM to build a newer version and then ultimately use that to build the latest version. So, if someone really "needed" (wanted?) to bootstrap FASM from something else (NASM?), all they'd have to do is convert the ancient .COM version and go on from there. Of course, that's not directly useful to Gentoo, obviously, but it's not hard to setup some kind of DOS-compatible environment. And yes, I know, totally pointless since it's obvious that FASM can (and should) continue to build itself. I'm not paranoid enough to worry about The Ken Thompson Hack. To me, it's fairly obvious that FASM does only what it implies. Code: @echo off REM ... bootstrapping FASM from other asm? here's where to start ... for %%a in (140 164 172) do unzip -q fasm%%a -d fasm%%a -x *.exe *.com *.sys unzip -qj fasm140 SOURCE\DOS\FASM.COM cd fasm164\source\dos gsed -i -e "1i\salc equ setalc" ..\formats.inc gsed -i -e "1i\macro align value{rb(value-1)-($+value-1)mod value}" fasm.asm ..\..\..\fasm.com fasm.asm f1.exe >NUL f1.exe fasm.asm f2.exe >NUL echo. echo (FASM 1.64) unzip -qqv ..\..\..\fasm164.zip fasm.exe | awk "{print $8,toupper($7)}" crc32 f2.exe REM 5DAC0852 echo. cd ..\..\..\fasm172\source\dos echo short equ byte>oldshort.inc gsed -i -e "1i\include 'oldshort.inc'" modes.inc ..\..\..\fasm164\source\dos\f2.exe fasm.asm f3.exe >NUL echo. >oldshort.inc f3.exe fasm.asm good.exe >NUL echo. echo (FASM 1.72) unzip -qqv ..\..\..\fasm172.zip fasm.exe | awk "{print $8,toupper($7)}" crc32 good.exe REM 5F7C1ECC echo. cd ..\..\.. rm -rf fasm140 fasm164 fasm172 rm -f fasm.com |
|||
20 Feb 2018, 05:08 |
|
|
revolution 21 Feb 2018, 06:20
It is actually quite easy to disassemble the binary and compare to the sources. And if you are really good with awk/sed/etc then it could even be automated. That might make for an interesting project for someone to make an automated verification tool.
|
|||
|
21 Feb 2018, 06:20 |
|
|
rugxulo 22 Feb 2018, 00:03
revolution wrote: It is actually quite easy to disassemble the binary and compare to the sources. You mean .COM? Obviously that's about as simple as you can get, (almost) raw binary. That was my point, it's somewhat easier than using ELF and a linker. But various potential complications can occur (self-modifying code, cpu-specific code, data put between code instead of only in one place, etc). So disassembly isn't always simple. Also, x86 is variable-length, which complicates things. So if you change one instruction, all the other displacements get adjusted accordingly. So it's hard to disassemble two similar binaries, even if they only differ in length of common JMPs (two bytes or three?). Maybe comparing (partial) listing would suffice? Nope, not if it doesn't simplify / unify / normalize basic forms, not counting other complex stuff. revolution wrote:
In what way? I did make a simple script to compare PSR Invaders .COM, using NDISASM + AWK to avoid the raw opcodes and only compare actual (100% equivalent) instructions. "mov cx,ax" (8B C8) vs. "mov cx,ax" (89 C1), etc. Of course, FASM and NASM share most opcodes, so that's less of a problem here. They are usually identical output. (I did sometimes find one rare quirk difference in YASM, though.) I don't think anyone here really wants me to convert it to NASM for us. But it would be an interesting, albeit pointless, task. |
|||
|
22 Feb 2018, 00:03 |
|
|
revolution 22 Feb 2018, 08:50
Compare by disassembled instructions, that is, the text output from the disassembler compared to the text input from the source. It really isn't that hard to do if one has the need. But if there is no need then it is just either a waste of time or a learning opportunity for someone. For a one-off job then comparing by sight will be a bit tedious but quite doable.
Even a really simple instruction count comparison can give a lot of confidence that there are no unexpected bad things in there. It would be really really hard to keep the instruction count the same but at the same time have it altered in some way to make it do bad things. In fact so hard that I would almost discount it as not worth worrying about unless you have some extra special need where a more thorough investigation is warranted. Or if you are bored one day. Note that my definition of "bad things" above covers a lot of situations. Like deliberate meddling, bad encoding, corrupted bits, missing instructions, duplicated instructions, etc. |
|||
|
22 Feb 2018, 08:50 |
|
|
Tomasz Grysztar 22 Feb 2018, 13:13
You could use fasmg to bootstrap fasm, even providing your own copy of x86 macros. Since everything is a macro then, the instruction handlers could be easily modified so that they would collect additional statistics and/or checksums that could then be used to verify the generated file.
|
|||
|
22 Feb 2018, 13:13 |
|
|
rugxulo 21 Aug 2018, 00:13
rugxulo wrote: Someone in another subforum here ... mentioned the idea of bootstrapping FASM. Gotta love how I unzipped fasm140.zip, then deleted it, but never used it! The main complaint that I had here, looking back, was using GNU sed. I didn't think it was necessary. Shouldn't FASM be able to handle "salc equ setalc", even if appended at the very end of the source file? Surely preprocessing is done first, no? Ugh, apparently not. (Or at least not in old 1.40. But maybe I'm misunderstanding ... probably!) So, basically, you don't need GNU sed, just COMMAND.COM's "COPY /B +" (and ECHO redirecting to file). Also, I just used DELTREE since that's relatively common (since something like DOS v5 ??) instead of relying on *nix RM. So yeah, probably not worth mentioning, but I'm doing so anyways. Quote:
|
|||
|
21 Aug 2018, 00:13 |
|
< Last Thread | Next Thread > |
Forum Rules:
|