News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Bug repport

Started by nidud, February 03, 2016, 01:51:30 AM

Previous topic - Next topic

johnsa

Hi,

We've just updated the 2.14 release binaries and code in github with the fix for CreateVariable.

John

habran

Hi ToutEnMasm,
Use a search in VS and find the first 'myassert'
than click with right button on it and chose "Ind all references"
they already have /**/myassert, just move the '*/' to the end of line

let me know if you succeed to build without myassert, please
Cod-Father

TouEnMasm

I have put all myassert in comment but,same error

Fa is a musical note to play with CL

habran

If you google that error, you will find out that it happens to others as well.
It has to do something with Visual Studio.
Cod-Father

habran

ToutEnMasm, try to put in Property Pages C\C++\Preprocessor _NDEBUG
and in a linker _DEBUG
Cod-Father

TouEnMasm

Found from where it com:
tokenize.c
Quote
static void StartComment( const char *p )
/***************************************/
{
    while ( isspace( *p ) ) p++;
    if ( *p == NULLC ) {
        EmitError( COMMENT_DELIMITER_EXPECTED );
        return;
    }
    ModuleInfo.inside_comment = *p++;
    if( strchr( p, ModuleInfo.inside_comment ) )
        ModuleInfo.inside_comment = NULLC;
    return;
}
the assertion failed using isspace say it's a bug using bad char to find the zero.
recommended method is to use len>> if len = 0
http://stackoverflow.com/questions/22952087/debug-assertion-failed-error-with-null-terminated-character-array
Fa is a musical note to play with CL

habran

Great find :t
Did you find solution for that?
Cod-Father

TouEnMasm

The line is a "comment ยต",I let you search why there is a bug here in debug mode ?!.
Fa is a musical note to play with CL

TouEnMasm

I try my best proc this time :biggrin:
Quote
         .686P         
      .MMX
      .XMM
                                 
         .model flat, stdcall                     
         option casemap :none 
         ExitProcess PROTO :DWORD 
         includelib kernel32.lib              
   .code

   start:
   comment q
   rien                       
   q
   
   invoke ExitProcess,0
   end start      
result
Quote
bug_jwasm.asm: 17 lines, 2 passes, 1 ms, 0 warnings, 0 errors
32 items in symbol table, expected 32
max items in a line=1, lines with 0/1/<=5/<=10 items=7977/32/0/0,
1937 items in resw table, max items/line=7 [0=695 1=695 357 105 35 8 2 3]
invokation CATSTR=0 SUBSTR=0 SIZESTR=0 INSTR=0 EQU(text)=0
lines read(files)/processed in pass one: 17 / 17
invokations: PreprocessLine=30/24/24, Tokenize=33/0
memory used: 408 kB
The debug version don't accept ascii char > 7Eh 126d ~
Fa is a musical note to play with CL

habran

Thanks ToutEnMasm :t
I will look at it ASAP
Cod-Father

LiaoMi

Hallo,

what does this message mean?

HJWasm v2.14, Jun  9 2016, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.

Translated Windows SDK 8.1 64 bits
Win64Test.asm: 575 lines, 3 passes, 9 ms, 0 warnings, 0 errors
Microsoft (R) Incremental Linker Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Win64Test.obj : error LNK2017: 'ADDR32' relocation to '_insn' invalid without /LARGEADDRESSAWARE:NO
Win64Test.obj : error LNK2017: 'ADDR32' relocation to '_insn' invalid without /LARGEADDRESSAWARE:NO
Win64Test.obj : error LNK2017: 'ADDR32' relocation to '_insn' invalid without /LARGEADDRESSAWARE:NO
LINK : fatal error LNK1165: link failed because of fixup errors
Press any key to continue . . .



Here is an example of code that I use

.if rax
xor rbx, rbx
           .WHILE rbx < rax
                 invoke printf, offset _Dis, _insn[rbx].address, _insn[rbx].mnemonic, _insn[rbx].op_str;
            inc rbx
        .ENDW
.else
    nop
.endif


Description

QuoteThe /LARGEADDRESSAWARE option tells the linker that the application can handle addresses larger than 2 gigabytes. In the 64-bit compilers, this option is enabled by default. In the 32-bit compilers, /LARGEADDRESSAWARE:NO is enabled if /LARGEADDRESSAWARE is not otherwise specified on the linker line.
If an application was linked with /LARGEADDRESSAWARE, DUMPBIN /HEADERS will display information to that effect.

This is required? After all, I do not break the boundaries of memory.

Regards!

johnsa

Hi,

When doing 64bit coding you cannot use OFFSET to obtain the address of a variable (as you would in 32bit as an argument to invoke etc).

To obtain an address you should use LEA, or for an argument to invoke you can use the ADDR operator.

For example:



lea rdi,myBuffer   ; get the address of myBuffer into RDI.

invoke myProc, ADDR myBuffer2, myBuffer



The warning relating to largeaddressaware is telling you that you're trying to create a 64bit image that is using 32bit style relocations (for runtime loading by the OS).

LiaoMi

Quote from: johnsa on July 03, 2016, 08:12:29 PM
Hi,

When doing 64bit coding you cannot use OFFSET to obtain the address of a variable (as you would in 32bit as an argument to invoke etc).

To obtain an address you should use LEA, or for an argument to invoke you can use the ADDR operator.

For example:



lea rdi,myBuffer   ; get the address of myBuffer into RDI.

invoke myProc, ADDR myBuffer2, myBuffer



The warning relating to largeaddressaware is telling you that you're trying to create a 64bit image that is using 32bit style relocations (for runtime loading by the OS).

Hallo,

the difficulty was not offset, but instead a pointer that has not been properly defined. With Offset is also interesting, since I did not notice the difference when assembled program. Thanks for the help :t

Regards

qWord

Quote from: johnsa on July 03, 2016, 08:12:29 PM
When doing 64bit coding you cannot use OFFSET to obtain the address of a variable (as you would in 32bit as an argument to invoke etc).
There are 64Bit offsets as well JWASM and ml64 handle them (either by using MOV or making them RIP-relative). I guess you mean the problem when using offsets/labels with SIB-Addressing, which is not possible**  because these kind of addressing is not RIP-relative.

regards

**except if using LARGEADDRESSAWARE:NO, which tells that that our image is in [0, 232) thus 64bit offsets could be truncate to 32bit.
MREAL macros - when you need floating point arithmetic while assembling!

mineiro

Hello, please, can you check this about rip addressing.
This is output from yasm and as on other side of moon.
as output
0000000000000000 <_start>:
   0:   8a 05 08 00 00 00       mov    al,BYTE PTR [rip+0x8]        # e <_start+0xe>
   6:   66 8b 05 00 00 00 00    mov    ax,WORD PTR [rip+0x0]        # d <_start+0xd>
   d:   8b 05 00 00 00 00       mov    eax,DWORD PTR [rip+0x0]        # 13 <_start+0x13>
  13:   48 8b 05 08 00 00 00    mov    rax,QWORD PTR [rip+0x8]        # 22 <_start+0x22>


The same code with adjustment using hjwasm:
hjwasm output
0000000000000000 <.text>:
   0:   67 8a 05 08 00 00 00    mov    al,BYTE PTR [eip+0x8]        # 0xf
   7:   67 66 8b 05 00 00 00    mov    ax,WORD PTR [eip+0x0]        # 0xf
   e:   00
   f:   67 8b 05 00 00 00 00    mov    eax,DWORD PTR [eip+0x0]        # 0x16
  16:   67 48 8b 05 08 00 00    mov    rax,QWORD PTR [eip+0x8]        # 0x26
  1d:   00


Thanks.
I'd rather be this ambulant metamorphosis than to have that old opinion about everything