flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > some questions about fas file format

Goto page Previous  1, 2, 3
Author
Thread Post new topic Reply to topic
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
LocoDelAssembly wrote:
Perhaps we are forgetting an important fact for the lack of binary hashes, it is the linker that produce the final executable, not the assembler


Yeah, that's what I was trying to say above:
buzzkill wrote:
but if you assemble a src file to an object file, and then link that with other files/libraries to generate the final binary, then fasm itself doesn't know anything about that binary.

and of course, that also applies to linking just a single object file Smile
Post 02 Apr 2009, 19:57
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Sorry Embarassed
Post 02 Apr 2009, 20:08
View user's profile Send private message Reply with quote
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
Hey no problem Very Happy
Post 02 Apr 2009, 20:19
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7783
Location: Kraków, Poland
Tomasz Grysztar
BTW, .fas format contains one mistake, which perhaps it's too late to correct. Wink The signature was intended to have value 1A736166h, but because of my mistake it has the value 1B736166h.
Post 02 Apr 2009, 20:55
View user's profile Send private message Visit poster's website Reply with quote
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
Well, I personally wouldn't mind if you changed it. And I don't think the average user would even notice. Maybe only programs that check this signature for some reason would need to be very slightly modified (1 byte Smile ) and recompiled.

Another way could be, if you have other ideas to change or add to the fas format, is to just (at some time) introduce version 2 of the fas format. File formats change and are updated, that's not unusual.

BTW, was it just a typo that caused your intended 1A to become 1B, or do these bytes have some special meaning?
Post 02 Apr 2009, 21:10
View user's profile Send private message Reply with quote
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
Tomasz, this is probably a silly question, but does the assembly dump part of a fas file have any value on its own?
I mean, it links src lines from the preprocessed src to offsets in the output file, so you need the output file to be able to see what is actually at those offsets (fasm's own listing tool also needs to open the output file). But I usually assemble to object files, which I later link, so the offsets in the object file are not the same as the offsets in my final binary. Also, with elf binaries, most things are relocatable, so you're not even sure that offsets in the object file are final. Eg, if you disassemble (the .text section of) an object file with objdump, it just shows offsets from 0.
The point is I've written a program (in C Embarassed ) that displays the contents of a fas file in human-readable form, and I have all of the different parts of the format done except for the assembly dump. Since I would like my program to not be dependent on an external object/binary file, and since even such a file might not provide the correct information, I wonder if the assembly dump is very useful for displaying as-is.
Am I correct in thinking this, or am I missing something?
Post 02 Apr 2009, 23:49
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7783
Location: Kraków, Poland
Tomasz Grysztar
Assembly dump is generally crucial for both the listing production, and for the source-level debugging. Of course it's not so useful with object files, because you don't debug object file, nor really need the listing of it - however, if you wanted linker to produce information required for source-level debugging, the linker would still have to get the line offsets from somewhere (and that's what the pecvt tool provides for the COFF objects).
Post 03 Apr 2009, 07:26
View user's profile Send private message Visit poster's website Reply with quote
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
Yes that's what I thought: it's primarily there for debug info. I don't think my program needs to generate a listing, so I guess I won't include the assembly dump then.
Post 04 Apr 2009, 19:49
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
buzzkill wrote:

BTW, was it just a typo that caused your intended 1A to become 1B, or do these bytes have some special meaning?


Since this was never answered, I'll take a guess:

736166h = "saf" ("fas" in reverse). I assume the 1Ah was meant as EOF as some other file formats (ARC? ZOO?) had similar so that you could "type myfile.zoo" and still know what it was without hearing lots of annoying console beeps because it would ignore everything after that EOF byte.
Post 14 Apr 2009, 20:09
View user's profile Send private message Visit poster's website Reply with quote
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
That sounds plausible, so that's probably it then Smile
Post 14 Apr 2009, 21:56
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7783
Location: Kraków, Poland
Tomasz Grysztar
buzzkill wrote:
Well, I personally wouldn't mind if you changed it. And I don't think the average user would even notice. Maybe only programs that check this signature for some reason would need to be very slightly modified (1 byte Smile ) and recompiled.

The 1.68 is going to use 1Ah value there. Please be ready to do that 1-byte modification and recompiling. Wink
Post 12 Jun 2009, 12:20
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.