Closed davidcanadas closed 2 years ago
maybe there could be a workaround to requiring the extension directory in the Makefile (would prevent calling 'gnumake' from terminal without args), maybe via getting the path from m68k-amiga-elf-gcc.exe or something like that.
Will do. I have one question though: what do you mean with "getting labels & errors/warnings doesn't work for VASM"?
what do you mean with "getting labels & errors/warnings doesn't work for VASM"?
see src/assembly_language_provider.ts
: // get labels
and // get error/warning messages
. Basically I parse the assembly listing output for labels (for navigation with Ctrl+Shift+O) and error messages (to get squiggles)
I've fixed everything but the syntax file. I need you to let me know how to proceed: the only way I've found to add a new syntax for ASM files is to add a new language for the VASM syntax, add a new grammar attached to that particular language, duplicate-sort-of AmigaAssemblyLanguageProvider in order to provide a different result to getLanguageId, add the activationAction, etc etc which looks pretty intrusive to me.
I was wondering if you know a less-intrusive solution to that problem?
I think I found a less intrusive way. Will post in a while for review :)
All changes requested applied. Please review.
vobjdump_win32.exe
no longer needed, removed.$(extensionPath)
no longer needed, removed.Thanks!
- Support labels & errors for VASM (VASM does not accept pipe/console input/output, hence instrumental files have to be created; we can modify VASM to skip creating instrumental files but I think it would be impractical if someone wants to use their on VASM).
that's no problem, I just used pipes because it seems easiest. tmp file is ok aswell.
Btw, thanks very much for your contributions!
Can you help getting 'template/support/depacker_doynax vasm.asm' to compile with VASM? I'm getting multiple weird 'illegal relocation [Ln 2, Col1]' parsing errors while editing.
I'm going to take a look into it. For now I see that errors in macros do not indicate the line of the error in the source file, but the line of the error inside the macro:
error 39 in line 2 of "DOY_OFFSET": illegal relocation
called from line 185 of "D:\GitHub\test\support\depacker_doynax_vasm.asm"
If I refine the error parser for VASM we can get the actual error instead when macros are involved. Additionally, I'll take a look into porting this file.
Fixed:
xdef
to publish the symbol, and had to rename doynaxdepack
to doynaxdepack_vasm
as well to avoid collision with doynaxdepack
(from main.c
) and doynaxdepack_asm
(from depacker_doynax.s
). I would suggest to move the depacker files to a subfolder to make sure the Makefile
will not assemble them by default and in case of need, include the desired file from any of the intro .s
or .asm
files. The other option is to remove the GAS version (you can leave gcc8_a_support.s
as example for GAS, and the packer as example for VASM).BTW, the error in your doynax port attemp was about how macro parameterization in VASM works.
Fixed:
try adding 'x' to line 44 of doynax_vasm at the end so 'd0' reads 'd0x'. doesn't show an error
Error handling in VASM is less deterministic that what I was expecting. By default, VASM treats undefined symbols as external symbols and implicitly xref
s them. However, passing the -x
option when invoking VASM (as I was doing) emits the undefined symbol error but for some reason the error message follows a different pattern the regular expression was unable to catch. I've added code to catch this particular error and then by parsing the source code I can detect the places in which error occur.
Notice though that if I add the 'x' to line 49, the effect is completely different. This is a VASM problem, because VASM detects undefined symbols as the last step in the assemble process. Therefore, in this particular case, during the assembly it assumes d0x
is a full address to a symbol, and by how doynax packer is written, a different error ("branch destination out of range") is raised in line 83 because replacing the register by an actual address makes bra.s
to fail.
see line 69,129,... of doynax_vasm. It tries to color 'db' of 'dbf'
Done. I've updated the regex to match db
followed by a space or tab. I did the same with some other trivial keywords expecting expressions afterwards.
could you please remove the console outputs of your error parser?
Done. I left the one in the GAS error parser because it is enabled in the original source code.
also, when I try to bring up the list of symbols in doynax_vasm, nothing shows up. it worked with the .s file strangely enough this.labels seems (mostly) ok (except 1 undefined entry), however it seems 'provideDocumentSymbols' doesn't seem to be called. can you please take a look?
Done. I misunderstood how the symbols dump file for VASM worked. I modified the code to find the symbol by myself instead of relying on addresses (sometimes the address is not in the symbol dump file).
Let me know any other issue you may encounter. Sorry for the mess, actually I did use VASM rarely and probably I'm missing lots of stuff...
Added commit "Improvement: warnings and lineless errors":
I've digged a little bit into VASM error messages and found that:
This PR introduces support for the VASM assembler.
.s
extension; VASM uses the.asm
extension..text
).Resources: VASM official website VASM fork for vscode-amiga-debug
VASM is Copyright (C) 2002-2022 by Volker Barthelmann.