Hi,
UASM 2.55 has been packaged up and ready. Code is, as always, in 2.55 branch on Github. Windows x86/x64 release packages are on the site.
This update includes a small set of fixes to WinInc, so that version 2.10 is now available on the site too.
The update includes:
Fixed CRC32 encoding
Added Warning for CRC32 when using an unsized memory type to indicate assumption of BYTE
Fixed KTEST{x} encoding issues and moved to CodeGenV2
More code cleanup and Linux build changes
Fixed FOR negative initalizer bug
Fixed vpbroadcastd ymm, m32 not assembling
Fixed struct member alignment using FIELDALIGN and optional alignment when member is a struct/union defined via a TYPEDEF
Fixed inter-segment OFFSET calculation for 64bit BIN files
Fixed REP scas(N) and REP cmps(N) generation for 64bit
Fixed a General Failure when using an undefined struct member as a type ptr
Fixed CodeView V8 symbolic debugging information where line number info didn't correspond to correct source files
Added AVX512-BW/DQ instructions: KTEST{B/W/D/Q}
Fixed register to error assume when used in EA
Fixed .FOR generation bug
These changes are actually the culmination of work from 2.53 + 2.54, due to my looooong hiatus from coding in general and Uasm, and some conflicting PRs and other troubles I decided to bump the version up, hence why there is no 2.53/54 releases.
Enjoy!
So far my major sources (RichMasm at 23k, MasmBasic at 43k lines) assemble fine with the new version :thumbsup:
Hi John
Thank you for this new release and the time you spent on it. It solves the problems of previous versions.
I tested it by compiling some sources and it works fine.
I need some more time to test other sources, but it seems to work very well :thumbsup:
Regards, Biterider
Excellent, glad to hear it :)
I was really hoping someone would have some brilliant ideas about moving Linux support forward, I think on the Windows front we're pretty much feature complete, bar one or two little things.
The position independent support and elf debugging are the two big things for Linux. I'd like to start putting it to use in AWS/EC2 on Amazon Linux and possibly look at getting some of the AWS SDKs available in asm.
Hello sir johnsa;
Congratulations and thanks.
I'm not being able to compile uasm in linux 64. Please, can you point the right way to do or just compile binaries and upload to terraspace or github!?
I tried compile before post, but not luck. Renamed a file to Makefile, typed make in shell and received an error message. Tried to change Makefile but received other errors.
ps:If you are busy, other member of this board can help me compile this in linux 64? Thanks.
Hi, I'm about to build the Linux binaries today/tomorrow. I might need to update some of makefiles etc and will commit any changes to 2.55 branch as well with Nix build instructions.
PS. I've found another issue with the CV8 line numbers.. It's way better than it was before, but not 100% .. undocumented m$ blah..
Thanks for the benevolence.
No rush, in your own time.
Hi John,
Many thanks :thumbsup:
Updated the Windows packages and 2.55 branch so long with another fix for CV8.. It's working well for me now on all my tests.
Linux builds to follow shortly.
thanks :thumbsup:
Hi John,
Thanks again. I guess you need to add the address of the latest WinInc file to the Downloads section of your website.
Quote9. Downloads
V2.09 WinInc209.zip
V2.08 WinInc208.zip
Here is how I got the zip file :
wget http://www.terraspace.co.uk/WinInc210.zip
V2.10 link added. Thanks! :thumbsup:
Hi John,
Thanks for the new version. The 64-bit version of Easy Code assembles and works fine with the new UASM64 version. :thumbsup:
Hi John!
Thanks for the new version! What types of variables are supported in the new CV8 format? It seems to me that not all information about variables is stored in the debug data.
It should support all the same types as CV1-4, so type defs, structs, primitive types byte/uint8 - qword, float and arrays.
If you have any specific examples where that isn't the case, I would suggest trying with -Zi and -Zi8 to compare in the debugger. If we can produce a small test case the cvdump utility is very useful and we can see the difference between the types exported into the debug data.
Thank you very much for updating UASM! As I compiled AMD64 code for the first time, I encountered what I think is a bug in listing generation. For example, the simple source file below
.code
testprc proc
XOR RAX,RAX ; RAX = 0
XOR RDX,RDX ; RDX = 0
RET
testprc endp
end
when compiled using the command line below
uasm -elf64 -q -mf -Fl -Sa -zcw -Zd test.s
results in the listing file below
UASM v2.55, Mar 30 2022, Masm-compatible assembler.
test.s
* .model FLAT
00000000 * _TEXT segment PARA FLAT PUBLIC 'CODE'
* _TEXT ends
00000000 * _DATA segment PARA FLAT PUBLIC 'DATA'
* _DATA ends
* assume cs:flat,ds:flat,ss:flat,es:flat,fs:ERROR,gs:NOTHING
.code
00000000 * _TEXT segment
* assume cs:FLAT
00000000 testprc proc
00000000 4883EC08 XOR RAX,RA00000004 48300000007 4833D2 XOR RDX,RDX ; RDX = 0
0000000A RET
0000000A 4883C408 * RETn
0000000F stprc endp
end
0000000F * _TEXT ends
(Macros are omitted for brevity.) As a comparison, JWASM using the same source file and command line produces the following listing file:
JWasm v2.11a, Apr 8 2015
test.s
* .model FLAT
00000000 * _TEXT segment PARA FLAT PUBLIC 'CODE'
* _TEXT ends
00000000 * _DATA segment PARA FLAT PUBLIC 'DATA'
* _DATA ends
* assume cs:flat,ds:flat,ss:flat,es:flat,fs:ERROR,gs:ERROR
.code
00000000 * _TEXT segment
* assume cs:FLAT
00000000 testprc proc
00000000 4833C0 XOR RAX,RAX ; RAX = 0
00000003 4833D2 XOR RDX,RDX ; RDX = 0
00000006 RET
00000006 C3 * RETn
00000007 testprc endp
end
00000007 * _TEXT ends
As far as I understand, what corrupts the listing is the generated "SUB RSP,8 / ADD RSP,8" code in the beginning and in the end (before the RET) of the procedure.
Quote from: johnsa on March 31, 2022, 07:06:45 PM
It should support all the same types as CV1-4, so type defs, structs, primitive types byte/uint8 - qword, float and arrays.
If you have any specific examples where that isn't the case, I would suggest trying with -Zi and -Zi8 to compare in the debugger. If we can produce a small test case the cvdump utility is very useful and we can see the difference between the types exported into the debug data.
Hi John!
The problem was that the pdb parser for some reason did not understand the structure of the debug symbols. In the debugger this problem disappeared. It seemed to me that local variables in procedures could also be added to debug symbols as constants. In fact, all examples do not have constants and local variables in the debug information.
Quote from: LiaoMi on April 10, 2022, 03:22:40 AMIt seemed to me that local variables in procedures could also be added to debug symbols as constants.
Several years ago I saw local variable names in OllyDbg, but I can't remember how I did it - and I've tried many options. Does anybody have a clue how to do it?
Quote from: johnsa on March 29, 2022, 04:07:18 AM
Hi,
UASM 2.55 has been packaged up and ready. Code is, as always, in 2.55 branch on Github. Windows x86/x64 release packages are on the site.
By default, this won't build on OSX.
There's a workaround (https://github.com/Terraspace/UASM/issues/148), though:
sed -i -e 's/-ansi/-Wno-error=implicit-function-declaration/' UASM-2.55/ClangOSX64.mak
Quote from: jj2007 on April 10, 2022, 05:03:01 AM
Quote from: LiaoMi on April 10, 2022, 03:22:40 AMIt seemed to me that local variables in procedures could also be added to debug symbols as constants.
Several years ago I saw local variable names in OllyDbg, but I can't remember how I did it - and I've tried many options. Does anybody have a clue how to do it?
Hi jj2007,
I also managed to display local variables, but I don't know how. I remember exactly that it was possible. Most likely it was MASM. If you look at the UASM-map file, there are no local variables in it.
Perhaps old MASM and old Olly?
Yes, it might have been Olly 1.0, but I can't get it to work.
In the phone now, but from memory: there is an option to load the .pdb file? (That file must be in same directory for sure)
From OLLYDBG.HLP:
QuoteShow ARGs and LOCALs in procedures
If this option is on and you have analyzed the code, OllyDbg displays addresses like [SS:EBP+8] and [SS:EBP-8] within recognized procedures as [ARG.1] and [LOCAL.2], hinting you that first address is the first argument of the procedure and another is the second word of the local data allocated on stack.
That's what I actually see now: mov eax, arg1 or mov eax, local.1 :sad:
MyTest proc uses esi edi ebx argPassed1, argPassed2
Local l1, l2,l3, l4,wc:WNDCLASSEX, buffer[bufSize+1]:BYTE
int 3
mov eax, argPassed1
mov eax, argPassed2
mov l1, 11111111h
mov l2, 22222222h
mov wc.cbSize, WNDCLASSEX
mov buffer[0], 1
mov buffer[bufSize], 99
00401031 |. 8B45 08 mov eax, [arg1]
00401034 |. 8B45 0C mov eax, [arg2]
00401037 |. C745 FC 11111 mov dword ptr [local.1], 11111111
0040103E |. C745 F8 22222 mov dword ptr [local.2], 22222222
00401045 |. C745 C0 30000 mov dword ptr [local.16], 30
0040104C |. C685 93FEFFFF mov byte ptr [local.92+3], 1
00401053 |. C645 BF 63 mov byte ptr [local.17+3], 63