GoAsm 0.58, GoRC 1.0 and GoBug updates

[wjr]

GoBug – Jeremy has kindly made his Win32 symbolic debugger version 2.0.3.1 now available for free. See here http://www.godevtool.com/#gobug for further details. If you don't already have this, please check it out. It has always been a sweet (yet nasty for the bug) addition to the suite of GoTools.

GoRC – the resource compiler has received a well-deserved promotion to version 1.0.0.0 and is available here http://www.godevtool.com/Gorc.zip with the following changes:

• fixed OBJ file output to have a proper UTC TimeDate Stamp
• finishing touches on the help file

GoRC – version 1.0.0.1 now up with the following adjustment:

• fixed problem with unrecognized preprocessor directive within #if #else #endif ignored block

GoRC – version 1.0.1.0 now up with the following adjustment:

• added command line option /nu for no warning message for a user-defined resource type

GoAsm – version 0.58 is an important assembler update on the x64 side, available here http://www.godevtool.com/Goasm.zip along with some other changes:

• fixed OBJ file output to have a proper UTC TimeDate Stamp
• fixed problem with displacement when using () within [] in x64 mode
• fixed cvtsi2ss and cvtsi2sd for use with D or Q[...]
• fixed USES for case of USES ES
• fixed USES for case of invalid use of DS,ES,SS in x64 mode
• fixed problem with PUSHW/POPW W[...]
• modified JRCXZ to assemble as JECXZ in x86 mode
• modified jump processing to allow a long backward jump when specified as a LONG or << jump
• fixed for correct count of 64-bit register ARGS to save to shadow space
• fixed ADDR for various cases of PUSH ADDR using a large address (*see note below)
• fixed ADDR for various cases of MOV [mem64],ADDR using a large address (*see note below)
• modified output on right hand side of list file for FRAME and related code added by GoAsm
• modified USEDATA which now requires a Label: on or before the line with USEDATA
• modified FRAME to allow use with case of no ARGs and LOCALs
• help file corrections and modifications for some of the above

GoAsm – version 0.58.0.1 now up with the following adjustments:

• fixed FRAME with no ARGs LOCALs with use of USES
• modified x64 INVOKE ARG register overwritten/same tests to include 32-bit case

GoAsm – version 0.58.0.2 now up with the following adjustments:

• modified x64 INVOKE ARG register tests to error for 16-bit case
• fixed x64 PUSH ADDR cases with R11 usage using wrong relocation label
• fixed x64 ADDR cases with R11 usage missing an additional immediate displacement

GoAsm – version 0.58.0.3 now up with the following adjustments:

• modified x64 ARG ADDR LocalLabel to use Q[RSP]
• fixed x64 INVOKE when using a string #define as one of the first four ARG

GoAsm – version 0.58.0.4 now up with the following adjustment:

• fixed x64 problem with address of nested last structure member if it required padding for alignment

GoAsm – version 0.58.0.5 now up with the following adjustment:

• fixed 16-bit alignment for Unicode string with INVOKE or PUSH

GoAsm – version 0.58.0.6 now up with the following adjustment:

• fixed 16-bit alignment for Unicode string with INVOKE or PUSH in UTF-8 or UTF16-LE file

* this fix goes a long way towards making ADDR go a long way with large addresses, but note that this in the first case MAY (doesn't when one of the first four INVOKE parameters) and in the second case WILL use the R11 register. This should have no impact on x86/x64 code. With greater register usage on the x64 only side, if you are using R11 for other purposes, please select a more suitable 64-bit register and manually MOV reg64,ADDR (actually LEA) then MOV [mem64],reg64.

The above is now good for addresses up to 4GB. There are still a few changes that I need to make with GoLink in order to allow the full 8TB. Once I finish up with these and another item, I can then return focus to some of the remaining GoAsm items, mainly x64 floating point INVOKE / FRAME issues and FRAME XDATA and PDATA which I was working on before some of the above accumulated detours became significant enough to prompt a release.

Enjoy,
WJR

[FlySky]

Great to see another update of this fine set of tools. I am a very happy GoASM user for a couple of years now, keep it up.
btw will there be any SSE3, SSE4 .. or higher support in GoASM.

[Yuri]

Great update. Thanks! :icon14:

[wjr]

I have become somewhat familiar with the code generating engines of GoAsm, so after the above focus I can sse3 what I can do.

It has been brought to my attention that FRAME without ARG and LOCAL has a problem with USES, looking into it...

[Yuri]

There is one inconsistency I forgot to mention earlier. If in x64 mode we mix up registers, e.g. use RDX for the first Invoke argument, GoAsm catches this as an error:

Error!
Line 27 of assembler source file (edx.asm):-
RDX overwritten by 2nd parameter material: use a register other than RDX

But it doesn't do so if we use EDX, although the result is the same.

[wjr]

An update is now available with fixes for these last two items.

GoRC also revised, but same version number, with very minor removal of IMAGE_FILE_LINE_NUMS_STRIPPED and IMAGE_FILE_LOCAL_SYMS_STRIPPED noting that for both "This flag is deprecated and should be zero" as part of the work in progress on the upcoming GoLink update...

[Yuri]

Thanks, Wayne! But how about DX, R8W and R9W? Maybe it doesn't make much sense to use them for passing arguments, so GoAsm could do what it does for DL, R8B and R9B:

Error!
Line 28 of assembler source file (edx.asm):-
Invalid operand for this mnemonic:-
dl, "hello", "test", 0

[Yuri]

Something seems to be wrong with the use of R11.

Code Select Expand


DATA SECTION

aa  DD 0
bb  DD 0


CODE SECTION

Start:
    lea r11,[aa]
    invoke Func, 0, 0, 0, 0, addr bb
    invoke Func, 0, 0, 0, 0, addr bb
    ret

Func:
    ret


Code Select Expand


0000000000401000: 4C 8D 1D F9 0F 00 00  lea r11,[00402000h]             

000000000040100F: 4C 8D 1D EA 0F 00 00  lea r11,[00402000h]  ; should be 00402004h
0000000000401016: 41 53                 push r11               

0000000000401026: E8 31 00 00 00        call 000000000040105C

0000000000401039: 4C 8D 1D 1C 00 00 00  lea r11,[0040105Ch]  ; should be 00402004h
0000000000401040: 41 53                 push r11         


Also, if the address is with a displacement, i.e. addr aa + 2, the displacement isn't added to the address.

[wjr]

An update is now available with fixes for these last three items.

Yes, for the 16-bit cases I have gone with invalid to be similar to 8-bit, higher up PUSHs, and x86 cases. Sorry about that on the other two... ended up being easy fixes, but takes a while to trace through and verify after with debugger.

[Yuri]

Thanks! But I have one more question. A local address in a FRAME is pushed like this:

Code Select Expand


0000000000401010: 55            push rbp
0000000000401011: 83 04 24 F8   add  dword ptr [rsp],0FFFFFFF8h

Is it safe to use dword ptr and not qword ptr here? I tried loading a DLL above 4 GB and creating a new thread using one of its functions as the starting point, and its stack was still below 4 GB, but is that guaranteed to always be so?

[wjr]

Under normal circumstances I would say safe, but not always guaranteed to be so. Perhaps this should be changed with an extra byte for a qword ptr.

Each thread gets its own stack, so I would be curious how RSP progresses as you create more threads. There should be a problem with this for the many thread case. The extent of this depends upon the next point...

I played around with /DYNAMICBASE and HIGHENTROPYVA for an EXE {just a note that I apparently have some more GoLink work to do for x64 with the /DYNAMICBASE option (remove .reloc for .rsrc)}. Although there is some variability, again well below 4GB for the typical case. However, by playing around with the PE32+ Stack Reserve, you can get there quickly. If you start with a Stack Reserve of 70000000h, you would typically find RSP starting between 7005xxxx and 7152xxx. However, starting with a Stack Reserve of 80000000h, you jump to a starting RSP around 0FFFEFxxx. With a Stack Reserve further above 2GB, you end up with an RSP >4GB.

[wjr]

Although probably not common for such a large stack, or somewhat smaller ones with multiple threads, to be on the safer side, I went with the qword option.

As for GoLink, the next update will have a fix for this bug:
For x64, if you link resources using a RES file for the case of a /DLL or an EXE with /DYNAMICBASE (not a problem for just an EXE), these options include relocations, but there are some relocations for the .rsrc section that shouldn't be there.

[wjr]

GoAsm version 0.58.0.4 and GoRC version 1.0.0.1 are now available. I'm still finishing up on some SAFESEH adjustments for a GoLink update...

[Yuri]

Thanks for the fixes, Wayne! :icon14:

[wjr]

GoRC version 1.0.1.0 now available.