Author Topic: Bug repport  (Read 14079 times)

habran

  • Member
  • *****
  • Posts: 1178
    • uasm
Re: Bug repport
« Reply #60 on: July 08, 2016, 11:54:24 PM »
Sir mineiro,
67h is a prefix for 32 bite, as you can see it uses eip instead of rip
Can you post your source code you are using please
Cod-Father

qWord

  • Member
  • *****
  • Posts: 1473
  • The base type of a type is the type itself
    • SmplMath macros
Re: Bug repport
« Reply #61 on: July 09, 2016, 01:45:16 AM »
I guess the problem is the definition of OP_RIP, which cause memory_operand() to set CodeInfo->prefix.adrsiz = TRUE.
There is also a bug in set_rm_sib() that allows to use index registers in (explicit) RIP-relative addresses (e.g. mov eax,[rip+rax*2]).


BTW: comments like "//ADDED BY HABRAN" are not really useful ;)
BTW2: floating point literals as operands were already implemented in JWasm (Issue #22)
MREAL macros - when you need floating point arithmetic while assembling!

mineiro

  • Member
  • ***
  • Posts: 450
Re: Bug repport
« Reply #62 on: July 09, 2016, 06:30:31 AM »
source code sir
Code: [Select]
.x64
.code
public _start
_start:
mov al,byte ptr [rip+8]
mov ax,word ptr [rip+0]
mov eax,dword ptr [rip+0]
mov rax,qword ptr [rip+8]
end

command line:
hjwasm -10 -nologo -elf64 -Fo=quiz.o quiz.hjwasm

--edited-- Added other example, maybe can help a bit
Code: [Select]
.x64
.code
public _start
_start:
lea rbx, [rip] ; RBX now points to the next instruction
nop
cmp byte ptr [rbx], 90h ; Should be equal!

;0000000000000000 <_start>:
;   0:   67 48 8d 1d 00 00 00    lea    rbx,[eip+0x0]        # 8 <_start+0x8>
;   7:   00
;   8:   90                      nop
;   9:   80 3b 90                cmp    BYTE PTR [rbx],0x90

This is as source used and disassembled code
Code: [Select]
#command line: as -o quiz.o quiz.asm
.intel_syntax noprefix
.text
.global _start

_start:
lea rbx, [rip] # RBX now points to the next instruction
nop
cmp byte ptr [rbx], 0x90 # Should be equal!

#0000000000000000 <_start>:
#   0:   48 8d 1d 00 00 00 00    lea    rbx,[rip+0x0]        # 7 <_start+0x7>
#   7:   90                      nop
#   8:   80 3b 90                cmp    BYTE PTR [rbx],0x90
I'd rather be this ambulant metamorphosis than to have that old opinion about everything

habran

  • Member
  • *****
  • Posts: 1178
    • uasm
Re: Bug repport
« Reply #63 on: July 09, 2016, 09:00:51 AM »
Thanks mineiro, it looks like RIP instruction is creating 32 bite code, that is probably unwanted byproduct while implementing EVEX instructions.
At this moment I am focused on implementing VECTORCALL in hjwasm, as soon as I finish it I will rework RIP relative instructions.

qWORD, "//ADDED BY HABRAN" was an atavism from the time while I was working parallel wit Japheth on JWasm
It is still useful sometimes because it shows me where I have changed existing code.
If that bothers you, I apologize for inconvenience. 
Cod-Father

qWord

  • Member
  • *****
  • Posts: 1473
  • The base type of a type is the type itself
    • SmplMath macros
Re: Bug repport
« Reply #64 on: July 09, 2016, 12:03:14 PM »
Changing the definition of OP_RIP to OP_R64 in operands.h and OP_RSPEC to OP_RIP in special.h seems to solve the problem...
MREAL macros - when you need floating point arithmetic while assembling!

habran

  • Member
  • *****
  • Posts: 1178
    • uasm
Re: Bug repport
« Reply #65 on: July 09, 2016, 06:41:30 PM »
Thanks qWORD :t
That fixes the problem indeed :biggrin:
It will be changed in next release.
Anyway, we will recheck all possible RIP-relative instruction formats
Cod-Father

johnsa

  • Member
  • ****
  • Posts: 710
    • Uasm
Re: Bug repport
« Reply #66 on: July 09, 2016, 07:18:42 PM »
I guess the problem is the definition of OP_RIP, which cause memory_operand() to set CodeInfo->prefix.adrsiz = TRUE.
There is also a bug in set_rm_sib() that allows to use index registers in (explicit) RIP-relative addresses (e.g. mov eax,[rip+rax*2]).


BTW: comments like "//ADDED BY HABRAN" are not really useful ;)
BTW2: floating point literals as operands were already implemented in JWasm (Issue #22)

With regards to the BTW2, the floating point literal changes we're making are:

ability to use floating point literals in invoke without need macros like FP4, FP8 and ability to use them directly with fp and simd instructions where a memory address is expected (will produce a warning that you can switch off)
so that you can do:
vmovss xmm0,2.3

and if you happen to use 2.3 again later hjwasm will re-use the same anonymous variable (unlike fp4/fp8 macros)..

At present invoke will generate the following if you use a direct floating point literal:
000000013F599188 B8 00 00 80 3F       mov         eax,3F800000h 
000000013F59918D 66 0F 6E C0          movd        xmm0,eax

which I personally think would be better as the above anonymous variable, one less instruction in the generation of the invoke and possible re-use of the literal value.

johnsa

  • Member
  • ****
  • Posts: 710
    • Uasm
Re: Bug repport
« Reply #67 on: September 07, 2016, 01:24:38 AM »
I guess the problem is the definition of OP_RIP, which cause memory_operand() to set CodeInfo->prefix.adrsiz = TRUE.
There is also a bug in set_rm_sib() that allows to use index registers in (explicit) RIP-relative addresses (e.g. mov eax,[rip+rax*2]).


BTW: comments like "//ADDED BY HABRAN" are not really useful ;)
BTW2: floating point literals as operands were already implemented in JWasm (Issue #22)

With regards to the BTW2, the floating point literal changes we're making are:

ability to use floating point literals in invoke without need macros like FP4, FP8 and ability to use them directly with fp and simd instructions where a memory address is expected (will produce a warning that you can switch off)
so that you can do:
vmovss xmm0,2.3

and if you happen to use 2.3 again later hjwasm will re-use the same anonymous variable (unlike fp4/fp8 macros)..

At present invoke will generate the following if you use a direct floating point literal:
000000013F599188 B8 00 00 80 3F       mov         eax,3F800000h 
000000013F59918D 66 0F 6E C0          movd        xmm0,eax

which I personally think would be better as the above anonymous variable, one less instruction in the generation of the invoke and possible re-use of the literal value.

Just in case anyone was interested what happened here, after a bunch of performance profiling I decided not to change this as the mov eax/movd combination was considerably faster than memory read, so it remained as is.