Repo and binaries are up, give it a try.
Hi johnsa
Seems to work fine here. :thumbsup:
Biterider
Quote from: johnsa on April 03, 2021, 03:12:03 AM
Repo and binaries are up, give it a try.
Hi John,
the archive with uasm252_x86 contains the old 2.51 version :tongue:
Quote from: johnsa on April 03, 2021, 03:12:03 AM
Repo and binaries are up, give it a try.
OK for my major sources :thumbsup:
Quote from: LiaoMi on April 03, 2021, 03:47:23 AM
Quote from: johnsa on April 03, 2021, 03:12:03 AM
Repo and binaries are up, give it a try.
Hi John,
the archive with uasm252_x86 contains the old 2.51 version :tongue:
story of my life.. will update now. :nie:
Should be sorted.
Quote from: johnsa on April 03, 2021, 07:08:36 AM
Should be sorted.
The release 2.52 works flawlessly :eusa_dance: :thup: :thup: :thup: :thup: Thanks for the work you've done!
P.S. UASM 2.51
1618 Views :dazzled:
deleted
Nidud, thanks a million :)
I've been investigating another strange issue, proc parameters. The symbol offsets in RBP/RSP based frames is spot on and the debugger picks them up perfectly .. except when you have a leaf proc with no locals/invokes and thus no SUB RSP,x
Even though the RSP+ofs values are correct and present on the sym->offset VS seems to have them all shifted out by 8. It appears as if the VS debugger expects RSP to always be aligned 16, which in the case of the leaf proc I don't bother.
I'm debating whether the sub rsp,8 should always be mandatory to keep align-16 even when nothing in the proc would require it.
Ok for me
Compiling the source code (vs2019),I get
Quote
Erreur C2065 'LANG_REGCALL' : identificateur non déclaré uasm I:\UASM-master\x86macros.c 317
The LANG_REGCALL refer to
Quote
enum lang_type {
LANG_NONE = 0,
LANG_C = 1,
LANG_SYSCALL = 2,
LANG_STDCALL = 3,
LANG_PASCAL = 4,
LANG_FORTRAN = 5,
LANG_BASIC = 6,
LANG_FASTCALL = 7,
LANG_VECTORCALL = 8,
LANG_SYSVCALL = 9,
LANG_DELPHICALL = 10
};
deleted
Agreed that's where my head was at.. if the user builds with /ZiN then we always keep the RSP aligned, don't optimize out the sub rsp.. I think that is the best solution.
Quote from: TouEnMasm on April 08, 2021, 07:16:42 PM
Ok for me
Compiling the source code (vs2019),I get
Quote
Erreur C2065 'LANG_REGCALL' : identificateur non déclaré uasm I:\UASM-master\x86macros.c 317
The LANG_REGCALL refer to
The archived VS2019 project files are not synchronized with the archived source files. You'll need to change the project information via VS2019.
I don't know the French for "Exclude from project", but you need to exclude x86macros.c and x86macros.h.
You can also exclude trmem.c and trmem.h, as TRMEM is not enabled by the archived project files. It needs to be updated to handle 64-bit pointers.
You also need to add pseudoFilter.c and pseudoFilter.h.
Quote from: tenkey on April 09, 2021, 12:17:05 AM
Quote from: TouEnMasm on April 08, 2021, 07:16:42 PM
Ok for me
Compiling the source code (vs2019),I get
Quote
Erreur C2065 'LANG_REGCALL' : identificateur non déclaré uasm I:\UASM-master\x86macros.c 317
The LANG_REGCALL refer to
The archived VS2019 project files are not synchronized with the archived source files. You'll need to change the project information via VS2019.
I don't know the French for "Exclude from project", but you need to exclude x86macros.c and x86macros.h.
You can also exclude trmem.c and trmem.h, as TRMEM is not enabled by the archived project files. It needs to be updated to handle 64-bit pointers.
You also need to add pseudoFilter.c and pseudoFilter.h.
Are you talking about UASM or the derivative work? These files don't exist in UASM... hence my previous concern over confusion having different people building and release under the same name.
x86macros better to remove, I have adopted remove all macros to .inc files to get better control off platform and arch environments definitions as also calling conventions.
I'm coming with a proposal for merge to an 2.53 with the x64 x32 platform conventions fix and the addition of regcall convention as also thiscall and experimental 32 bits vectorcall, and linux64 syscall.
And more tho add after test this is working.
Hi johnsa,
Thanks for the update. Did you also add the unreferenced symbols removal with the use of option /OPT:REF ?
Quote from: johnsa on April 09, 2021, 02:14:35 AM
Are you talking about UASM or the derivative work? These files don't exist in UASM... hence my previous concern over confusion having different people building and release under the same name.
I think it's UASM. Those files exist in the repository at
your link to github.com/Terraspace/UASM. Including the VS2019 solution and project files in the build folder. I've downloaded the master and the 2.52 branch. I'm assuming you're the one updating that repository, on account of your link. I may need to get newer versions, now that I've taken another look at the repository.
Today is a good day.It's the first time I can debug in source mode with windbg a 64 bit prog.
:thumbsup:
/c /nologo /coff /Zi8 /Zd on windows 10
hi johnsa
I can't build it (Linux):
Quotedbgcv.c:20:10: fatal error: 'direct.h' file not found
#include <direct.h>
Thanks for the spot, I'll check it out!
Quote from: TouEnMasm on April 19, 2021, 03:23:46 AM
Today is a good day.It's the first time I can debug in source mode with windbg a 64 bit prog.
:thumbsup:
/c /nologo /coff /Zi8 /Zd on windows 10
Can you post a screenshot? I am curious...
Hello,
Here the option for link NOLOGO /SUBSYSTEM:WINDOWS /LARGEADDRESSAWARE /DEBUG:FASTLINK /debugtype:cv
for uasm /c /nologo /coff /Zi8 /Zd
I am not sure they are the best,some chance is needed.
Thanks, Yves, interesting. For comparison, below the x64 view of...
WinMain proc
LOCAL msg:MSG
wc equ [rbx.WNDCLASSEX] ; we use an equate for better readability
int 3
lea rbx, wcx
mov wc.hInstance, rv(GetModuleHandle, 0)
mov wc.hIcon, rv(LoadIcon, rax, IDI_APPLICATION) ; click on the first Rsrc bookmark to change the icon
mov wc.hIconSm, rax ; the rv macro returns results in rax
mov wc.hCursor, rv(LoadCursor, NULL, IDC_ARROW) ; get a cursor
jinvoke RegisterClassEx, rbx ; the window class needs to be registered
The x64 interface is clearly inspired by Oleh Yuschuk alias Olly (http://www.ollydbg.de/version2.html).
(http://www.jj2007.eu/pics/x64WinMain.png)
Hi John,
UASM 2.49 (Linux 64bit) 21/06/2019 uasm249_linux64.zip 64bit Linux Executable (GCC)
UASM 2.47 (OSX Universal) 17/11/2018 uasm247_osx.zip 64bit OSX Executable (GCC)
Not Found
The requested URL was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Quote from: lucho on May 02, 2021, 04:10:58 AM
Thank you for working on UASM! I could build it OK, but an old bug that was present also in the old version 2.49 is still there. The following code
.code
tst proc
.for (eax = 0: edx == 0: )
nop
.endfor
tst endp
end
when built with "uasm -elf -3 -mf -Fl -Sa test.s", results in this listing:
test.s
* .model FLAT
00000000 * _TEXT segment DWORD FLAT PUBLIC 'CODE'
* _TEXT ends
00000000 * _DATA segment DWORD 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 tst proc
00000000 .for (eax = 0: edx == 0: )
00000000 33C0 * xor eax, eax
00000002 * @C0001:
00000002 90 nop
00000003 .endfor
00000003 EBFD * jmp @C0001
00000005 tst endp
end
00000005 * _TEXT ends
As you see, there is no check for the condition.
The bug must be in the "hll.c" file
Here's a version of hll.c for the Terraspace UASM code base that fixes the problem.