Author Topic: Upcoming GoAsm x86/x64 changes  (Read 4131 times)

wjr

  • Member
  • **
  • Posts: 185
    • WJR's website
Upcoming GoAsm x86/x64 changes
« on: September 08, 2013, 09:27:37 AM »
While progress is being made on a GoLink update (done, see version 1.0), I have started more planning for GoAsm. For x64 exception handling, FRAME should be providing pdata RUNTIME_FUNCTION info and xdata UNWIND_INFO on the function's prolog stack usage (work in progress). Version 0.58 started with some FRAME and USEDATA adjustments required for this, and a few more are on the way for your info:

x86/x64 LOCALFREE (done, see version 0.59)
Since this stack re-allocation will usually alter that which was recorded in the prolog UNWIND_INFO, LOCALFREE would be changed to not be allowed for x86 and x64 modes (only allowed for regular 32-bit code).

x64 USES
Currently only one USES line is allowed. The xmm registers should be allowed here for x64. However, since the xmm registers would be dealt with differently by allocating (properly aligned) stack space and using movdqa, and also x86 would most likely use the FPU registers (x86/x64 conditional assembly), it will be easier and better to save xmm registers with a separate USES line that should be placed after the regular register USES line (if used).

x86/x64 USEDATA
Currently there is a default SHIELDSIZE (100h bytes for 32-bit, 200h bytes for 64-bit, also with a minimum of 20h) which allows for possible stack usage in the FRAME beyond that which was done in the prolog since GoAsm does not track this. There is a several step adjustment to RSP which is a fixed amount relative to RBP, but the amount relative to RSP is not known by GoAsm at assembly-time, and this is required for assembly-time UNWIND_INFO.

The change here would be to alter default the SHIELDSIZE to 4h bytes for x86 and 8h bytes for x64 (unchanged for regular 32-bit code). These would also be the new minimum values which take into account just the return value on the stack for the call in INVOKE. The USEDATA prolog would be simplified, and the epilog change would have RSP restored using the LEA valid format for SEH. Note that this may require adjusting current x86/x64 code by specifying a different SHIELDSIZE value for the amount of stack space actually used (ex. for manually supplying arguments to a USEDATA procedure, along with the return value for the call). See also the following...

x64 INVOKE
The current x64 approach is somewhat similar to 32-bit code which pushes function arguments on the stack, except for the first 4 which are passed through registers (a stack allocation for these 4 are still always made for each INVOKE, and removed after the call). Due to stricter x64 stack 16-byte alignment for a call, there is also extra code added with each x64 INVOKE.

This is where the above USEDATA change can get a bit tricky. Depending upon the USES and LOCAL lists, there may be an extra 8-bytes for stack alignment, and if so they need to be included in the SHIELDSIZE.

Because of this USEDATA related issue and also for better optimised and easier to follow code for x64 INVOKE, there is another approach. This involves creating enough stack space in advance for the arguments (properly 16-byte aligned) and reuse these for each INVOKE using mov for the non-register arguments (for ARG [Label] this 'memory to memory' mov would most likely go through the R11 register). However, in order to use this, you would need to ensure that when you use x64 INVOKE the stack has not changed from where it was after the prolog, which still may require adjusting current x86/x64 code.
 
x64 FRAME / USEDATA / LOCAL
The above would only be available on a per x64 FRAME (or USEDATA) basis by specifying the maximum number of ARGs (or more if you want to waste stack space, or not be bothered with error messages) that will be used by INVOKE within the FRAME (or USEDATA). GoAsm is a single pass assembler and does not look that far in advance, but would give an error message with the ARG count if INVOKE exceeds the maximum.

The syntax to achieve this would be added to LOCAL with the keyword ARGS and a required [N], placed at the end of the LOCAL list, where N is the maximum number of arguments allowed for any INVOKE within the FRAME or USEDATA procedure (the minimum N would be 4 for the required shadow space). For example:

Code: [Select]
LOCAL Loc1, Loc2, ARGS[4] ;placed at end on same line

;also

LOCAL Loc1, Loc2
LOCAL ARGS[8] ;placed at end on a separate line

The use of ARGS would not alter x86 mode stack allocation or INVOKE.

That is it for now...
« Last Edit: November 29, 2014, 11:20:37 AM by wjr »

wjr

  • Member
  • **
  • Posts: 185
    • WJR's website
Re: Upcoming GoAsm x86/x64 changes
« Reply #1 on: April 15, 2014, 11:53:13 AM »
Shifting main focus back to GoAsm...

wjr

  • Member
  • **
  • Posts: 185
    • WJR's website
Re: Upcoming GoAsm x86/x64 changes
« Reply #2 on: November 29, 2014, 11:22:28 AM »
Other progress didn't make it into version 0.59. Back to regularly scheduled programming...

satpro

  • Member
  • **
  • Posts: 116
Re: Upcoming GoAsm x86/x64 changes (Program Listings)
« Reply #3 on: January 25, 2015, 02:05:51 AM »
Hi Wayne,

I was wondering if there is a chance we may see improved (enhanced) source listings for GoAsm.  As it is now, listings are cropped at 80-columns, which is quite limiting, especially if comments are taken into consideration.  More times than not, a source listing is all one needs for de-bugging, and I frequently use listings in place of GoBug for the simpler things (and also really like to see the translation into binary).  Also, as it is now, listings at the assembler stage are only partially helpful for viewing the binary, so would a linker stage listing be better in this respect?

GoAsm is really a great assembler and I work with it literally every day, but am wondering about this one topic and if there is anything planned for the future and what would be involved in tackling it.  If not, is there a workaround I might implement on my own?

Thank you.
« Last Edit: January 25, 2015, 04:23:38 AM by satpro »

wjr

  • Member
  • **
  • Posts: 185
    • WJR's website
Re: Upcoming GoAsm x86/x64 changes
« Reply #4 on: January 25, 2015, 09:48:46 AM »
The listing file will have plenty of [00000000] since the address relocations are done at a later stage with linking. Having those values filled in would be more accurate along with instruction and label addresses showing, but having the linker do this would most likely involve GoAsm passing line number information (COFF line number info has been deprecated). No easy work around to implement on your own that I can think of.

The intent may have been to limit for printer friendlier output, but more characters can be fit in per line going with a smaller font and landscape orientation.

The current typical listing line format is 26 characters for opcodes plus 74 characters from the source file (that is 100 characters; perhaps your text editor is cropping this further to 80 characters for printing).

I made some small changes already to the listing file in an earlier version for display of code that GoAsm inserts, and have considered an adjustment which would extend the opcode section to at least 32 characters (also displaying a bit more in the data section, ex. strings). I took a quick look, and it should be very easy to extend the portion copied from the source file. Going with around 98 characters (an extra 24) seems reasonable to fit a total of 130 characters at font size 9 with landscape orientation and narrower margins.

As for the opcode adjustment, instead of left justified, I was considering some spacing and lining up so that it would be easier to identify portions of the instruction encoding (various Prefixes, Opcode(s), ModRM, SIB, Displacement, and Immediate values).

satpro

  • Member
  • **
  • Posts: 116
Re: Upcoming GoAsm x86/x64 changes
« Reply #5 on: January 27, 2015, 07:58:29 AM »
Thanks for the response.  Actually, I did later notice it was cropped at 100 columns, not 80, and my confusion was from using two different vertical edge settings (one in the editor for writing source, and the other in Notepad2 for opening up .asm files quickly  :icon_redface: ).  My source, including comments, does extend to 130 columns.  One can live with using printouts from source text in landscape mode and de-bugging with the .lst file.

Anything you feel might help with GoAsm listings will certainly be appreciated here.

Thanks again,
Bert

wjr

  • Member
  • **
  • Posts: 185
    • WJR's website
Re: Upcoming GoAsm x86/x64 changes
« Reply #6 on: February 13, 2015, 05:01:37 AM »
The next update will have some changes to the list file and also include support for SSE3 and SSSE3 instructions. Relatively soon, depending on how far I can go with the list file changes...

FlySky

  • Regular Member
  • *
  • Posts: 36
Re: Upcoming GoAsm x86/x64 changes
« Reply #7 on: February 14, 2015, 05:18:44 AM »
Great news wjr.
keep it up, GoASM is getting better and better!

FlySky

  • Regular Member
  • *
  • Posts: 36
Re: Upcoming GoAsm x86/x64 changes
« Reply #8 on: February 15, 2015, 01:15:56 AM »
wjr,

Maybe you can explain the following.

I am building a x64 bit dialogbox.
What I am wondering is the following on other x64 bit processes all system dll's are loaded into the 7ffc'........ range being 64 bit addresses.
on my x64 bit program only ntdll is inside 64 bit range range all other system dll's are below that.
Could you explain why that is?
I tested Jeremy's HelloWorld2 program and on that program all system dll's are in 64 bit range.

wjr

  • Member
  • **
  • Posts: 185
    • WJR's website
Re: Upcoming GoAsm x86/x64 changes
« Reply #9 on: February 15, 2015, 07:37:42 AM »
Use the GoLink /LARGEADDRESSAWARE command line switch.

This assumes that you have made any necessary 64-bit pointer changes in your program. For example, instructions accessing memory using a base register and/or index register with a label address (ex. [rdx*4+MyTable]) do not use RIP-relative addressing, so this would need to be adjusted to handle a larger Image Base (ex. [rax+rdx*4] with rax as ADDR of MyTable).

wjr

  • Member
  • **
  • Posts: 185
    • WJR's website
Re: Upcoming GoAsm x86/x64 changes
« Reply #10 on: April 26, 2015, 04:35:27 PM »
SSE4 looks fairly straight forward to add as well...