flat assembler
Message board for the users of flat assembler.

Index > Windows > 64-bit 0xFFFFFFFF "Value out of range"?

Goto page 1, 2, 3  Next
Author
Thread Post new topic Reply to topic
KingDemon



Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania
KingDemon
Hi, everyone!

When I try to compile this:
Code:
        and     rax, 0xFFFFFFFF    

, as part of a 64-bit Windows program I get:
Code:
"Error: Value out of range"    

0xFFFFFFFF is only the largest DWORD, so it doesn't fit into a QWORD? :)

Cheers!

_________________
Don't mind me! I'm just a crazy next-door neighbor.
Post 16 Sep 2009, 16:31
View user's profile Send private message Reply with quote
Fanael



Joined: 03 Jul 2009
Posts: 168
Fanael
Immediate in all instructions except mov is a sign-extended DWORD. 0xFFFFFFFF doesn't fit into 32 bits as a signed value.
Post 16 Sep 2009, 17:24
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
Suggested replacement:
Code:
mov eax, eax; NOT RAX, EAX    
(Provided you only want to clear the upper bits and the RFLAGS are not important, otherwise use "and eax, eax")
Post 16 Sep 2009, 17:57
View user's profile Send private message Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2468
Location: Bucharest, Romania
Borsuc
In 64-bit mode, all operations on 32-bit registers clear the upper dword, that's why Loco's method works. Weird, I know. Confused

_________________
Previously known as The_Grey_Beast
Post 16 Sep 2009, 18:05
View user's profile Send private message Reply with quote
KingDemon



Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania
KingDemon
Thanks! I'm just starting to learn about 64 bit programming.
I thought this was a bug or something. :D

_________________
Don't mind me! I'm just a crazy next-door neighbor.
Post 16 Sep 2009, 20:22
View user's profile Send private message Reply with quote
KingDemon



Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania
KingDemon
Also found another problem: the MSG structure is 48 bytes long, and the USER64.INC header gives it only 44.

This is how it's defined in winuser.h:
Code:
typedef struct tagMSG {
    HWND        hwnd;
    UINT        message;
    WPARAM      wParam;
    LPARAM      lParam;
    DWORD       time;
    POINT       pt;
#ifdef _MAC
    DWORD       lPrivate;
#endif
} MSG, *PMSG, NEAR *NPMSG, FAR *LPMSG;    

And this is from USER64.INC:
Code:
struct MSG
  hwnd         dq ?
  message dd ?,?
  wParam  dq ?
  lParam  dq ?
  time          dd ?
  pt    POINT
ends    

sizeof(MSG) in a C++ program gives 48, while sizeof.MSG in FASM gives only 44. I'm not sure why, but the extra DWORD is at the end and GetMessage always overwrites it. Mostly, it just puts 0 in there, but sometimes I saw a negative value. Maybe it's the lPrivate member?
Post 16 Sep 2009, 22:06
View user's profile Send private message Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2468
Location: Bucharest, Romania
Borsuc
_MAC??? What is that, Macintosh? Laughing
Post 16 Sep 2009, 23:59
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 449
Location: Czech republic, Slovak republic
Feryno
Perhaps pt POINT should be aligned 8 so then 1 extra padding dword is necessary between time and pt
Years ago I spent a lot of time to manually examine structures and identify same basics like that handle is qword, every qword must be aligned at 8 etc. I examined structures by debugger (e.g. finding the API name in win64 app - e.g. notepad.exe, calc.exe and then using debugger to load that executable, putting breakpoint at the starting address of API and then examining input parameters when breakpoint hit). Hard way but worked almost every time. In that time, FASM hadn't its headers for win64 yet. After about 1-2 years I understood and learned rules so then I was able to port headers from microsoft (I obtained C style headers after downloading few gigabytes of SDK, WDK). Coding in assembler under win64 was like a small baby in nappy in that old and early times, win64 was available only in release candidates. Linux AMD64 was already here for more than 1-2 years.
Post 17 Sep 2009, 08:27
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
KingDemon



Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania
KingDemon
No padding is required between time and pt. Only at the end, after pt.
If you add that padding before pt., then pt.'s data will be broken because you'll be reading it wrong.
Also, if it is padding, then how come it's written to by the API? What is it, free temp space? Smile AFAIK from MSDN, you can't use padding as temp space, because you can't be sure that it's always there.

Maybe it's padding for the whole struct, and some memcpy is done on it, which also copies the padding.
But what I can't explain is why the C++ sizeof operator takes that structure padding into account (I'm not fully acquainted with padding for alignment).
Post 17 Sep 2009, 12:57
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
vid
Well, the _MAC indeed appears to be symbol defined on Macintosh. Maybe there is bug in POINT structure?
Post 17 Sep 2009, 13:53
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
KingDemon



Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania
KingDemon
Rather, there's a bug in M$'s code. They always screw up.
Post 17 Sep 2009, 15:07
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
vid
So you found it? Where exactly?
Post 17 Sep 2009, 17:35
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
KingDemon



Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania
KingDemon
Nope, but it's there. I only said that because there can't possibly be a bug in the POINT structure. It's just data, not code... Smile
Post 17 Sep 2009, 18:11
View user's profile Send private message Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2468
Location: Bucharest, Romania
Borsuc
This is ridiculous, you mean on a Windows operating system, a value specific for Macs (Microsoft and Macs??? does not compute!) gets overwritten with 0s or negative value? Epic fail for M$ Confused

_________________
Previously known as The_Grey_Beast
Post 17 Sep 2009, 21:19
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
vid
I doubt there is any MS bug here. That is extremely unlikely
Post 18 Sep 2009, 11:52
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
KingDemon



Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania
KingDemon
I forgot to mention that I'm working on Windows 7. Very Happy
And like I said, the C++ sizeof operator takes the elusive padding into account, which means it's not really a bug, just something that's probably wrong in the USER64.INC file. I added an 8 byte padding manually at the end of the structure, and everything's ok.
Post 18 Sep 2009, 14:17
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
http://ntcore.com/files/vista_x64.htm wrote:
As you can see, I tried to stay as low level as I could. The reason why I avoided for other functions other than the main the proc macro is that the ml64 puts a prologue end an epilogue, which I didn't want, by itself. Avoiding the macro made it possible to define my own stack frame without any intermission by the compiler. The first thing to notice scrolling this code is the structure:

Code:
MSG struct     
  hwnd              dq      ?
  message           dd      ?
  padding1          dd      ?      ; padding
  wParam            dq      ?
  lParam            dq      ?
  time              dd      ?
  pt                POINT   <>
  padding2          dd      ?      ; padding
MSG ends
    

It requires two paddings which the x86 declaration of the same structure didn't. The reason, in a few words, is that qword members should be aligned to qword boundaries (this for the first padding). The additional padding at the end of the structure follows the rule that: every structure should be aligned to its largest member. So, being its largest member a qword, the structure should be aligned to an 8-byte boundary.


Perhaps struct macro needs to be modified for 64-bit?
Post 18 Sep 2009, 14:57
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7496
Location: Kraków, Poland
Tomasz Grysztar
There is only one "struct" macro. I simply forgot to put the second padding into the definition.
Post 18 Sep 2009, 15:02
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

There is only one "struct" macro.

Yes, I meant that the same struct macro used for 32-bit may not be fully usable for 64-bit so a modification for 64-bit may be needed. If this alignment rules needs to always be applied then I think it should be automatic (having a new STRUCT64).
Post 18 Sep 2009, 15:09
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7496
Location: Kraków, Poland
Tomasz Grysztar
LocoDelAssembly wrote:
Yes, I meant that the same struct macro used for 32-bit may not be fully usable for 64-bit so a modification for 64-bit may be needed. If this alignment rules needs to always be applied then I think it should be automatic.

In 32-bit world you may also meet some alignment rules with some languages, which you have to take into consideration when you convert the structure into assembly. The "struct" macro itself may be used for your own structures, or other kinds than the Windows' as well, so it should be left verbatim.
Post 18 Sep 2009, 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:  
Goto page 1, 2, 3  Next

< 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-2019, Tomasz Grysztar.

Powered by rwasa.