64-bit 0xFFFFFFFF "Value out of range"?

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

Goto page 1, 2, 3 Next

Author

Thread

KingDemon

Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania

KingDemon 16 Sep 2009, 16:31

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.

16 Sep 2009, 16:31

Fanael

Joined: 03 Jul 2009
Posts: 168

Fanael 16 Sep 2009, 17:24

Immediate in all instructions except mov is a sign-extended DWORD. 0xFFFFFFFF doesn't fit into 32 bits as a signed value.

16 Sep 2009, 17:24

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 16 Sep 2009, 17:57

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")

16 Sep 2009, 17:57

Borsuc

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania

Borsuc 16 Sep 2009, 18:05

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

16 Sep 2009, 18:05

KingDemon

Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania

KingDemon 16 Sep 2009, 20:22

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.

16 Sep 2009, 20:22

KingDemon

Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania

KingDemon 16 Sep 2009, 22:06

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?

16 Sep 2009, 22:06

Borsuc

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania

Borsuc 16 Sep 2009, 23:59

_MAC??? What is that, Macintosh? Laughing

16 Sep 2009, 23:59

Feryno

Joined: 23 Mar 2005
Posts: 514
Location: Czech republic, Slovak republic

Feryno 17 Sep 2009, 08:27

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.

17 Sep 2009, 08:27

KingDemon

Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania

KingDemon 17 Sep 2009, 12:57

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).

17 Sep 2009, 12:57

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 17 Sep 2009, 13:53

Well, the _MAC indeed appears to be symbol defined on Macintosh. Maybe there is bug in POINT structure?

17 Sep 2009, 13:53

KingDemon

Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania

KingDemon 17 Sep 2009, 15:07

Rather, there's a bug in M$'s code. They always screw up.

17 Sep 2009, 15:07

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 17 Sep 2009, 17:35

So you found it? Where exactly?

17 Sep 2009, 17:35

KingDemon

Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania

KingDemon 17 Sep 2009, 18:11

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

17 Sep 2009, 18:11

Borsuc

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania

Borsuc 17 Sep 2009, 21:19

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

17 Sep 2009, 21:19

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 18 Sep 2009, 11:52

I doubt there is any MS bug here. That is extremely unlikely

18 Sep 2009, 11:52

KingDemon

Joined: 16 Oct 2006
Posts: 21
Location: Somewhere in Romania

KingDemon 18 Sep 2009, 14:17

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.

18 Sep 2009, 14:17

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 18 Sep 2009, 14:57

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?

18 Sep 2009, 14:57

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 18 Sep 2009, 15:02

There is only one "struct" macro. I simply forgot to put the second padding into the definition.

18 Sep 2009, 15:02

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 18 Sep 2009, 15:09

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).

18 Sep 2009, 15:09

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 18 Sep 2009, 15:11

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.

18 Sep 2009, 15:11

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