JWasm version v2.0 now really beta

Started by japheth, August 26, 2009, 04:46:35 PM

Previous topic - Next topic

@lx

Quote from: japheth on October 30, 2009, 07:54:10 AM
jwasm writes errors to <file>.ERR, but it additionally writes the errors to stdout. So I don't think this is the problem. You'll have to supply a test case, but please test first that it works with Masm and fails with JWasm!
Actually, i'm using masm but whenever i try to switch to jwasm and i have a simple error in the asm file, the errors never go to the stdout, moreover as jj2007 mentioned, the error code is not set so VS doesn't complain on compilation but only when linking (because the obj file is missing)...
Running a dos command prompt, i get the errors to the stdout...
Under VS, i have debug and modified jwasm and i'm getting the errors if i set errout to stderr in errmsg.h (like unix). Although the return errorcode is still not set.
Also, i had to change quite a few things in jwasm to make it working in VC++ 2008... (some local variable are not initialized, the lineis() function has a bug when the length of substr > the length of string). I'll try to give you a recap.

jj2007

Quote from: japheth on October 30, 2009, 07:54:10 AM
Thanks! However, JWasm was written mainly for myself and the - few - people who love assembly in Masm-syntax.

It's not only a syntax issue. Only Masm and JWasm have powerful macro facilities. For people who want to code close to the machine but without the clumsiness of coding print "Hello World" in "pure" assembler, JWasm is a precious gift.

Just out of curiosity: Apparently ml64 does no longer support macros; does 64-bit JWasm provide the full macro capability?

japheth

Quote from: @lx on October 30, 2009, 08:57:03 AM
Actually, i'm using masm but whenever i try to switch to jwasm and i have a simple error in the asm file, the errors never go to the stdout, moreover as jj2007 mentioned, the error code is not set so VS doesn't complain on compilation but only when linking (because the obj file is missing)...

The error code is set if the number of errors is > 0. If this wouldn't work, then not just VS had problems, but also all [N]MAKE utilities.

Quote
Running a dos command prompt, i get the errors to the stdout...
Under VS, i have debug and modified jwasm and i'm getting the errors if i set errout to stderr in errmsg.h (like unix). Although the return errorcode is still not set.
If you changed the jwasm source privately, then please don't report errors which occur in that version, even if you think that the errors have nothing to do with your changes!
Btw, it's important that the jwasm Win32 version writes errors to stdout, not stderr. That's how Masm does it.

Quote
Also, i had to change quite a few things in jwasm to make it working in VC++ 2008... (some local variable are not initialized, the lineis() function has a bug when the length of substr > the length of string). I'll try to give you a recap.

Ok! Bug reports must be detailed, best is to supply a description with a - small - test case.

japheth

Quote from: japheth on October 30, 2009, 09:38:10 AM
Quote from: @lx on October 30, 2009, 08:57:03 AM
Actually, i'm using masm but whenever i try to switch to jwasm and i have a simple error in the asm file, the errors never go to the stdout, moreover as jj2007 mentioned, the error code is not set so VS doesn't complain on compilation but only when linking (because the obj file is missing)...

The error code is set if the number of errors is > 0. If this wouldn't work, then not just VS had problems, but also all [N]MAKE utilities.


JJ made me aware that I'm probably a bit tooooo optimistic concerning the "error code" issue. So I made a test and have to confirm that you're right, there is - or better: was - a bug. It has been fixed in v2.01.

Sorry for rejecting an absolutely valid bug report!


@lx

#34
Quote from: japheth on October 30, 2009, 12:40:22 PM
JJ made me aware that I'm probably a bit tooooo optimistic concerning the "error code" issue. So I made a test and have to confirm that you're right, there is - or better: was - a bug. It has been fixed in v2.01.
Sorry for rejecting an absolutely valid bug report!
Hi japheth, cool that you can confirm this bug... i have cheched it also, and the parse_cmdline in the main loop was clearing the ModuleInfo.error_count for the previously parsed file...

For the other errors, here is the sample file :


.686P
.XMM
.model flat

TestDeclareMacro macro funcName:req, procParam
CURRENT_FUNCTION textequ <&funcName>
CURRENT_LABEL_START textequ <&funcName&_Start_>
CURRENT_SECTION textequ <_&funcName&_>
CURRENT_SECTION segment byte public 'CODE'
ifb     <procParam>
CURRENT_FUNCTION proc
else
CURRENT_FUNCTION proc procParam
endif
CURRENT_LABEL_START:
endm

TestEndDeclareMacro macro
CURRENT_FUNCTION endp
CURRENT_SECTION ends
endm           

TestDeclareMacro TestAsmFunction, c public
mov eax, 2
blabla
ret
TestEndDeclareMacro
     
end


I'm getting some runtime error (i'm running VC++ 2008 in debug mode, so it's checking buffer overflow and so on, stuff that you won't see in a release mode or sometimes with other compilers...)

The file  macro.c, line 182 : if (qlevel == brlevel) : qlevel used but not initialized. I have modified line 149 to have a correct init : int qlevel = 0;
The file macro.c, line 208 : if( string[len] != '\0' && !isspace( string[len] ) ) {. The parameters are string = "endp", substr = "macro", len = 5. This line is not working and is reading from an unitialized memory : string[len] is undefined  if strlen(substr) > strlen(string).

Cosmetic things : The exe was not working on VC++ 2008 getting a runtime error on :  symbols.c : line 520   strftime( szDate, 9, "%D", now ); line    526   strftime( szTime, 9, "%T", now );
I suspect strftime microsoft to be not compliant. Because D and T are not recognized, i had to add something like :

#ifdef _MSC_VER >= 1300
    strftime( szDate, 9, "%x", now );
#else
    strftime( szDate, 9, "%D", now );
#endif
...
#ifdef _MSC_VER >= 1300
    strftime( szTime, 9, "%X", now );
#else
    strftime( szTime, 9, "%T", now );
#endif


After checking more about the stdout error, in fact errors are effectively going to stdout (Output Windows) but not in the "Error List" window of VC++. ([Edit]MASM doesn't have the problem[/Edit]).  but if you change this two lines in msgdef.h (line 15-21)
: instead of "Warning" use "warning", instead of "Error" use "error", the errors will show up in the "Error List" windows of VC++.

With this simple fix, i'm able to ger errors in the Error List (in the screenshot, with MASM and modified version of Jwasm 2.0) :



Hope that you will be able to integrate this in JWasm 2.01!  :wink







japheth

Quote from: @lx on October 30, 2009, 02:49:07 PM
The file  macro.c, line 182 : if (qlevel == brlevel) : qlevel used but not initialized. I have modified line 149 to have a correct init : int qlevel = 0;
True but irrelevant IMO, because if qlevel is uninitialized then the value of quote is NULLC; In other words, the worst thing what may happen is that a value is written to a variable which has that value already.

Quote
The file macro.c, line 208 : if( string[len] != '\0' && !isspace( string[len] ) ) {. The parameters are string = "endp", substr = "macro", len = 5. This line is not working and is reading from an unitialized memory : string[len] is undefined  if strlen(substr) > strlen(string).
This is also a somewhat mechanistic analysis. The code works. Agreed, memory might be read from uninitialized locations, but it's ensured that value of len will be small enough to not cause an exception.

Quote
Cosmetic things : The exe was not working on VC++ 2008 getting a runtime error on :  symbols.c : line 520   strftime( szDate, 9, "%D", now ); line    526   strftime( szTime, 9, "%T", now );
I suspect strftime microsoft to be not compliant. Because D and T are not recognized, i had to add something like :

#ifdef _MSC_VER >= 1300
    strftime( szDate, 9, "%x", now );
#else
    strftime( szDate, 9, "%D", now );
#endif
...
#ifdef _MSC_VER >= 1300
    strftime( szTime, 9, "%X", now );
#else
    strftime( szTime, 9, "%T", now );
#endif

Yes, this should be changed. However, %X and %x are flagged as "locale dependent",  so it may be a  better idea to use %d, %m, %H, ... instead.

Quote
After checking more about the stdout error, in fact errors are effectively going to stdout (Output Windows) but not in the "Error List" window of VC++. ([Edit]MASM doesn't have the problem[/Edit]).  but if you change this two lines in msgdef.h (line 15-21)
: instead of "Warning" use "warning", instead of "Error" use "error", the errors will show up in the "Error List" windows of VC++.

With this simple fix, i'm able to ger errors in the Error List (in the screenshot, with MASM and modified version of Jwasm 2.0) :
Ok.

jcfuller

Are there (or would someone show) examples of dynamic loading and calling of shared libraries (dll,so) with JWASM at run time?
The reason is to offer both console and gui in one program on linux. First check for gtk needed shared libraries and if not available
provided a text only interface
James


@lx

Hi japeth,
It seems that I have an unexpected result with JWasm here. If you try to reference the field of a nested structure inside another structure you'll get a zero offset.


NestedStruct struct
level db ?
NestedStruct ends

TopStruct struct
member1 NestedStruct <>
member2 NestedStruct <>
member3 NestedStruct <>
TopStruct ends

.code
    mov eax, [esi + TopStruct.member1.level]            ; Generated assembler is : mov eax, [esi]


Can you confirm?

Also, seems that the debug obj file is not working with VS 2008... I'm unable to step in the code generated with jwasm... but I need to investigate a bit more...

japheth

Quote from: Jimg on October 12, 2009, 04:01:21 PM
The following works in masm but not in jwasm-
.686
.model Flat, Stdcall
option Casemap :None
.code
tst22 proc
ret
tst22 endp
program:
    baseroutine = tst22
    invoke tst22        ; this works
    invoke baseroutine  ; gives Error! E232: INVOKE requires prototype for procedure
    ret
end program


Is this on the to do list for the next version, or do you consider this a bug in masm that shouldn't work and won't be changed?

@Jimg: this has been fixed for v2.01. Please test!