flat assembler
Message board for the users of flat assembler.

Home Search Register
Log in to check your private messages Log in

Index > Compiler Internals > DOS - FASM 1.71.58 - spurious errors (unknown regression)
Author
Thread Post new topic Reply to topic
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo 20 Dec 2016, 00:22
I hadn't bothered to test latest FASM (1.71.58) until now. I had assumed everything was fine, but the DOS version is giving me false errors (while 1.71.57 works fine). Also, FASMD seems to assemble correctly whereas the normal cmdline .EXE does not. I didn't bother to diff the two to isolate the problem, but of course I felt it was important to mention anyways. I'm not sure what's wrong, internal memory error?
Post 20 Dec 2016, 00:22
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 19872
Location: In your JS exploiting you and your system
revolution 20 Dec 2016, 04:18
Can you give sample code for us to assemble and test?
Post 20 Dec 2016, 04:18
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo 21 Dec 2016, 13:53
This is not code specific, it's seemingly getting confused about perfectly valid code that used to assemble with no errors. But now it's giving false errors, even in the simplest of macros, even in the simplest of data definitions (dw or dd). I don't know what else to tell you, it's a regression.
Post 21 Dec 2016, 13:53
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 19872
Location: In your JS exploiting you and your system
revolution 21 Dec 2016, 14:49
Can you show some "perfectly valid code" that it gets "confused about". Your error report is very vague.

AFAICT no one else is seeing a problem.
Post 21 Dec 2016, 14:49
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8267
Location: Kraków, Poland
Tomasz Grysztar 21 Dec 2016, 16:32
revolution wrote:

AFAICT no one else is seeing a problem.
The problem probably only occurs when unreal mode variant is used, and there are probably few people that use fasm in real mode DOS. I'm going to check it when I'm back at my own DOS machine.
Post 21 Dec 2016, 16:32
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo 13 Jan 2017, 20:19
Sorry, I'm even more disorganized these days, and I also don't have any obvious code to test.

But here's an example:

Code:
[ FreeDOS ] G:\TONY>fasm d2x.asm
flat assembler  version 1.71.57  (2734325 kilobytes memory)
2 passes, 169 bytes.
[ FreeDOS ] G:\TONY>d2x 20816
00005150
[ FreeDOS ] G:\TONY>fasm inv-fasm.asm
flat assembler  version 1.71.57  (2734325 kilobytes memory)
4 passes, 9194 bytes.
[ FreeDOS ] G:\TONY>fasm fas17158\source\win32\fasm.asm fasmw32.exe
flat assembler  version 1.71.57  (2734325 kilobytes memory)
5 passes, 113664 bytes.
[ FreeDOS ] G:\TONY>pestub -q -n fasmw32.exe
[ FreeDOS ] G:\TONY>fasmw32 d2x.asm
flat assembler  version 1.71.58  (2097152 kilobytes memory)
2 passes, 169 bytes.
[ FreeDOS ] G:\TONY>d2x 20816
00005150
[ FreeDOS ] G:\TONY>fasmw32 inv-fasm.asm
flat assembler  version 1.71.58  (2097152 kilobytes memory)
4 passes, 9194 bytes.
[ FreeDOS ] G:\TONY>stubit fasmw32.exe >nul
[ FreeDOS ] G:\TONY>fasmw32 d2x.asm
flat assembler  version 1.71.58  (1048464 kilobytes memory)
2 passes, 169 bytes.
[ FreeDOS ] G:\TONY>d2x 20816
00005150
[ FreeDOS ] G:\TONY>fasmw32 inv-fasm.asm
flat assembler  version 1.71.58  (1048464 kilobytes memory)
4 passes, 9194 bytes.
[ FreeDOS ] G:\TONY>FAS17158\fasm d2x.asm
flat assembler  version 1.71.58  (2734325 kilobytes memory)
d2x.asm [22]:
macro MUL10 {
error: invalid macro arguments.
[ FreeDOS ] G:\TONY>FAS17158\fasm inv-fasm.asm
flat assembler  version 1.71.58  (2734325 kilobytes memory)
inv-fasm.asm [492]:
LetterCounter           DW      0
processed: LetterCounter DW 0
error: invalid size of operand.
Post 13 Jan 2017, 20:19
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8267
Location: Kraków, Poland
Tomasz Grysztar 20 Jan 2017, 13:41
I think I know what caused these problems. I'm going to make some additional tests on my DOS machine and the I'll upload the fix.
Post 20 Jan 2017, 13:41
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8267
Location: Kraków, Poland
Tomasz Grysztar 20 Jan 2017, 14:49
I think it should be fixed in 1.71.59. Please try it out.
Post 20 Jan 2017, 14:49
View user's profile Send private message Visit poster's website Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1140
Location: Russian Federation
comrade 20 Jan 2017, 23:54
What was the problem?
Post 20 Jan 2017, 23:54
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo 21 Jan 2017, 01:18
Tomasz Grysztar wrote:
I think it should be fixed in 1.71.59. Please try it out.


Yes, seems to work fine now. Thanks.
Post 21 Jan 2017, 01:18
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8267
Location: Kraków, Poland
Tomasz Grysztar 21 Jan 2017, 13:27
comrade wrote:
What was the problem?
Recently I got rid of the CALL/POP pairs that fasm's core sometimes used to get the EIP value (because they required special handling in 64-bit mode), and I forgot that I cannot just use "PUSH label" instead, since the unREAL version uses different segment bases for the preprocessor and assembler modules, so the value of EIP may be different from the value of label. This is why a position-independent code was needed there and I changed it back, but this time I made it in such way that there is always RET to clean up after CALL (therefore the special handling in 64-bit mode is no longer necessary). This may also improve the predictability of CALL/RET pairings on modern processors.
Post 21 Jan 2017, 13:27
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 19872
Location: In your JS exploiting you and your system
revolution 21 Jan 2017, 13:40
But why the unpredictable behaviour? Wouldn't it always still follow the same execution path?
Post 21 Jan 2017, 13:40
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8267
Location: Kraków, Poland
Tomasz Grysztar 21 Jan 2017, 15:11
It would always land in the same place in code, but the data pointed to by registers could differ, so I guess that's where the unpredictability came from.
Post 21 Jan 2017, 15:11
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:  


< 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


Main index Download Documentation Examples Message board

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

Website powered by rwasa.