flat assembler
Message board for the users of flat assembler.

Index > Windows > Correct Win64 support?

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



Joined: 10 Dec 2006
Posts: 5
Myria
Does this assembler support making legal x86-64 Windows programs? I have yet to find an assembler other than MASM that can do x86-64 Windows.

GNU as, Yasm, etc. can do x86-64, but none of them can generate the mandatory .pdata markup required for Win64. Does Flat Assembler support generating the .pdata section?

Melissa
Post 10 Dec 2006, 03:53
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
Melissa, the documentation says
Quote:
data directive begins the definition of special PE data, it should be followed by one of the data identifiers (export, import, resource or fixups) or by the number of data entry in PE header. The data should be defined in next lines, ended with end data directive. When fixups data definition is chosen, they are generated automatically and no more data needs to be defined there. The same applies to the resource data when the resource identifier is followed by from operator and quoted file name - in such case data is taken from the given resource file.


If you know the number of .pdata section then you can define it. (I don't know if fasm do it already automatically).

PS: And wellcome to the board Smile
Post 10 Dec 2006, 04:29
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
For those like me that didn't know the existence of this new section, this one serves for exception handling proposes and replaces the stack based one.

Here an explanation http://msdn.microsoft.com/msdnmag/issues/06/05/x64/default.aspx

And here http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx the PE spec that shows the structure of this new section
Post 10 Dec 2006, 04:58
View user's profile Send private message Reply with quote
Myria



Joined: 10 Dec 2006
Posts: 5
Myria
In order to generate the .pdata section, you have to output information about every assembly function in your program. You have to describe the layout of your stack frame, including which nonvolatile registers went there. You must also follow a strict set of guidelines regarding function prolog and epilog code.

All this is mandatory, otherwise exception handling breaks. Even functions that don't have an exception handler must have metadata, because a __try block in an outer function may cover an inner function.

An executable without such markup on all non-leaf functions is not a valid Win64 executable.
Post 10 Dec 2006, 05:32
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
interesting, I wonder if Vista 64 checks for this and as a result doesn't allow fasm compiled 64bit programs to run on it?
Post 10 Dec 2006, 06:08
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7795
Location: Kraków, Poland
Tomasz Grysztar
Well, in context of mentioned "data" directive - it's not the fasm that doesn't generate this section, it's the programmer. Wink As this is the mechanism that manages the exception handling, I also guess the skilled assembly programmer should be able to define that structure in a way to bend those mechanisms to his own purposes.

In assembly language code doesn't have to reside in functions, and the functions may be in fact just a programmer's mind constructs. Also "__try" constructs wouldn't make much sense in the assembly... And the idea that stack frame should be only modified by function prologues... that's so incompatible... Do they want to allow only programs written in C-like languages to run? Silly thing. However I've never heard before that executables that don't define exception handling structures are not the valid one. Any reference?

Well, apart from assembler itself, fasmw distribution does now also have some standard Win64 headers, including the "proc" macro. vid proposed to build into "proc" macro the support for generating the unwind information. This is a good idea, since if you use "proc" macro, you (in most cases) agree this way to use the default prologue/epilogue, and thus the unwind info can be generated automatically. But that would only be a modification of a macro, not the assembler itself - and this is the only possibly way to automate.
Post 10 Dec 2006, 09:24
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
Myria wrote:
An executable without such markup on all non-leaf functions is not a valid Win64 executable.

What do you mean by "not a valid executable"? I doesn't work for you? I can run such an executable without any problems under winxp x64 and it works well. Only when an exception occurs, the application is silently killed with no warnings or messages.
Post 10 Dec 2006, 17:57
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:
Only when an exception occurs, the application is silently killed with no warnings or messages.

I checked it with a "mov [0], rax" and no warning appeared as you say, THAT'S TERRIBLE!! Maybe fasm should add the .pdata section initializing it with some defaults values that guaranties that the exception will be handled by Windows (like in Win32 apps when you don't destroy [FS:0])
Post 10 Dec 2006, 21:05
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
why should it do it? It should do it only when you want FASM to do it
Post 10 Dec 2006, 23:29
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Myria



Joined: 10 Dec 2006
Posts: 5
Myria
What's needed is commands in fasm (or any other assembler) to tell it what it needs to know in order to build the .pdata section. It's still manual but at least the programmer isn't having to calculate the raw table data themselves.
Post 11 Dec 2006, 02:33
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
vid wrote:
why should it do it? It should do it only when you want FASM to do it


Because if Myria is right then it's mandatory and fasm should add some default info when you don't specify custom data. Or fasm should stop including a default stub telling "This program cannot run in DOS mode." because you didn't specified a stub? You see, fasm already adds default things, so why it should be different?
Post 11 Dec 2006, 03:23
View user's profile Send private message Reply with quote
Myria



Joined: 10 Dec 2006
Posts: 5
Myria
The only way I can think of to have a default is to call AddVectoredExceptionHandler or RtlInstallFunctionTableCallback at the entry point of the program to put in a default handler.
Post 11 Dec 2006, 06:04
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Loco: stub is formatting thing. Having extra section is different. What would you do if you don't want any pdata info for some reason?
Post 11 Dec 2006, 11:36
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
LocoDelAssembly wrote:
Quote:
Only when an exception occurs, the application is silently killed with no warnings or messages.

I checked it with a "mov [0], rax" and no warning appeared as you say, THAT'S TERRIBLE!!

Yeah, I really don't know why windows couldn't pop up a simple message box Confused
I'm curious whether vista x64 works same - weird - way in this case.
Post 11 Dec 2006, 12:12
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:

Yeah, I really don't know why windows couldn't pop up a simple message box

Maybe the same reason as when you overwrite [FS:0] with garbage on Win32 apps.

vid, well I don't have a more strong argument right now Razz So for now I only suggest that the ".end" macro of the not done yet WIN64AX.INC/WIN64AXP.INC add a default .pdata section using the entry point as the unique function (only if this is really mandatory and/or helps to show the message box provided by Windows when an unhandled exception ocurrs).

BTW, how can I add such section with current fasm?
Post 11 Dec 2006, 15:25
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
loco: since "proc" macros doesn't supported that, you have to do manually. I tried to make tomasz write such macros, but it seems he is as lazy about this as me Very Happy
one of arguments was that FASM would be first assembler to have this done properly.

something like:
Code:
 proc excpt name arg1, arg2    

to build unwind info

I agree about .end
Post 11 Dec 2006, 16:31
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
MazeGen, I have news, I got a warning message now.

Here templete example modified to produce the run-time error dialog
Code:
section '.code' code readable executable

  start:
        mov     [0], rax
        sub     rsp,8*6         ; reserve stack for API use and make stack dqword aligned
    

And here the one that silently dies
Code:
section '.code' code readable executable

  start:
        sub     rsp,8*6         ; reserve stack for API use and make stack dqword aligned
        mov     [0], rax    
I wonder if my suggestion is enough now, seems that every stack adjustment will produce this behavior (and since calling something obviously affects the stack then vid's proposal seems to be mandatory too). I tried to produce my own "data 3" this way
Code:
; #define IMAGE_DIRECTORY_ENTRY_EXCEPTION       3   // Exception Directory
section '.pdata' data readable
data 3
  dd rva start
  dd rva start
  dd 0 ; while I don't know how to produce this unwind info I use NULL (which probably is wrong and I must study this more of couse)
end data    


But not success...
Just I hope that one good defined entry it is enough
[edit] Tryed using dq instead of dd and removing rva. My last attempt:
Code:
; #define IMAGE_DIRECTORY_ENTRY_EXCEPTION       3   // Exception Directory
section '.pdata' data readable
data 3
  dq  start
  dq  endOfCode
  dq  start
end data    
But the second code persists in dying silently...[/edit]
Post 12 Dec 2006, 00:37
View user's profile Send private message Reply with quote
Myria



Joined: 10 Dec 2006
Posts: 5
Myria
It terminates without warning because it believes that it just detected an exploit. Messing with exception handlers is a classic trick for exploiting bugs in Windows programs. It can't display a dialog box, because there is a risk that doing so will end up executing shellcode.
Post 17 Dec 2006, 21:00
View user's profile Send private message Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
LocoDelAssembly, interesting, thanks.
Post 18 Dec 2006, 08:13
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
Since there was some proc64 development recently I must bump this thread.

Any plans to support this? Is it still an issue or now Windows drops some error dialog?
Post 23 Aug 2009, 22:29
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  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-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.