16 June 2019, 19:18 | #61 |
Registered User
Join Date: May 2018
Location: France
Posts: 246
|
Do you have the stopOnEntry option set ?
Could you remove the built files and try to rebuild all the workspace? I’ll try it on windows, maybe a bug... |
16 June 2019, 22:20 | #62 |
Registered User
Join Date: Jun 2016
Location: France
Posts: 20
|
I set the stopOnEntry and trace to true and after rebuilding the project it worked. Thank you very much for your advices.
|
11 August 2019, 12:03 | #63 | |
Registered User
Join Date: Jul 2017
Location: Oxford
Posts: 107
|
Quote:
EDIT: I've also set both options to true, but it still stops elsewhere and is out of sync with code lines. I've an 'include startup.s" right at the top that might confuse the debugger? EDIT2: I think I've got the issue. I don't see all the files being rebuilt, but just the main module and another I've touched... what's the proper way to clean the build then? Last edited by emiespo; 11 August 2019 at 12:19. |
|
11 August 2019, 15:10 | #64 |
OCS forever!
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 418
|
Yes includes like that confuse the debugger. Makes sense as the line number vs source file name info that is stored in the exe cant/wont match. You get similar problems with macros and rept structures.
I’ve moved to a style where I assemble everything separately and the have them all linked. So like your include startup I have that as its own file to be assembled and linked so if it needs to be debugged it can easily work out the correct file. You can probably get away with just putting a breakpoint as the first line after your include when debugging starts it should stop there (may need to press f5 once if using stoponentry) |
11 August 2019, 15:27 | #65 | |
Registered User
Join Date: Jul 2017
Location: Oxford
Posts: 107
|
Quote:
I think I might have assembled them in a different way, but really can't remember how :-) what I remember is that the debugger was working like a charm. Would you suggest building all separately with Vasm? Is there any example I could look at? I only code a few lines every few months (sad) that's why I keep forgetting... |
|
11 August 2019, 17:52 | #66 |
OCS forever!
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 418
|
The design of the extension and default config is such that it will auto compile anything with an .s extension. So it gets a bit messy for programs with multiple source files where some are included manually and others aren't. You can of course rename files that you want to include but not automatically assemble to startup.i or something.
Personally, I love the extension for the in editor tools and debugging, but I'm finding it easier to do the build myself with a batch file (can use a makefile of course, but I doubt I'll ever have more than a dozen files) My vscode config for the extension in launch.json I removed the auto build: Code:
"buildWorkspace": false, Example batchfile I'm using to assemble and link my multiple files. I just run the batch and then jump back into the editor to run the debug. Code:
@set DemoName=Demo @rem General build params set BuildParam=-m68000 -showopt -Fhunk -kick1hunks -linedebug -x -DDebug=%Debug% -I Include -D_INTROWRAPPER=0 -nowarn=62 @rem General linker params, strip symbols unless debugging set LinkParam=-bamigahunk -Bstatic if %debug% NEQ 1 set LinkParam=%LinkParam% -s REM Assemble all sections and link together. Assemble entry point file first set ObjFileList= set SrcFile=Framework\IntroStandalone.s set ObjFile=%ObjDir%\IntroStandalone.o ECHO ASSEMBLING: %SrcFile% vasmm68k_mot_win32.exe %BuildParam% -o %ObjFile% %SrcFile% if errorlevel 1 goto failed set ObjFileList=%ObjFileList% %ObjFile% ECHO. set SrcFile=Framework\IntroFramework.s set ObjFile=%ObjDir%\IntroFramework.o ECHO ASSEMBLING: %SrcFile% vasmm68k_mot_win32.exe %BuildParam% -o %ObjFile% %SrcFile% if errorlevel 1 goto failed set ObjFileList=%ObjFileList% %ObjFile% ECHO. REM ... REM More files go here and repeat the above for each file REM ... REM Link objects echo. echo LINKING %DemoName% vlink %LinkParam% -o %OutDir%\%DemoName%.exe %ObjFileList% if errorlevel 1 goto failed echo SUCCESS exit /b 0 :failed echo FAILED exit /b 1 |
12 August 2019, 09:17 | #67 |
Registered User
Join Date: May 2018
Location: France
Posts: 246
|
For bigger builds, one better way to do it is using a makefile. Here is an example: https://github.com/prb28/vscode-amiga-vbcc-example.
It’s with a mix of C and ASM but you can remove the C build instructions. |
12 August 2019, 09:46 | #68 |
OCS forever!
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 418
|
Nice. I’ll take a look
|
15 August 2019, 00:26 | #69 | |
Registered User
Join Date: Jul 2017
Location: Oxford
Posts: 107
|
Quote:
vasm -depend=list ... the main source file is then successfully compiled via "make" into one single exe, however VisualStudio is still unable to correctly detect my breakpoints. Even the entry breakpoint is not correct. I remember it used to work earlier, but then I haven't touched it in a while... |
|
15 August 2019, 00:36 | #70 | |
Registered User
Join Date: May 2018
Location: France
Posts: 246
|
Quote:
- you use the vasm option : -linedebug - The launch.json configuration parameter "program" is correct |
|
17 August 2019, 00:12 | #71 | |
Registered User
Join Date: Jul 2017
Location: Oxford
Posts: 107
|
Quote:
Now I get a bunch of: Code:
Error 21: init_copperlist.o (CODE+0x7e): Reference to undefined symbol CprPln1. Code:
Error 19: /build/main.o: Global symbol bplxmod from main.o is already defined in copperlist.o. This would also explain why if I only link main.o (main.s includes files including other files in turn) the exe works but the debugger doesn't. What confuses me is that I am pretty sure it was working a few months ago, and I was really happy to get this kind of functionality as in the past I used to debug UAE via RAM breakpoints, ie breakpoints triggered by writing 0 at specific addresses in RAM... |
|
17 August 2019, 08:56 | #72 |
Registered User
Join Date: May 2018
Location: France
Posts: 246
|
Maybe the debugger can’t reach the sources and you have to set the sourceFileMap option in the launch.json file. The best way to check it is to open the exe with a hex editor and see if there is debug info and the name of the files in it.
If you want to the easiest way for me to check it is to build your project on my desktop. If you want you can send me a link in pm, and I’ll have a look next week (I’m far from a computer this weekend). |
18 August 2019, 22:41 | #73 | |
Registered User
Join Date: Jul 2017
Location: Oxford
Posts: 107
|
Quote:
I am now thinking that the editor doesn't (still) support multiple sources. I've tried something simpler that you could easily replicate, I've downloaded the example workspace here: https://github.com/prb28/vscode-amiga-wks-example and then added as the very first file a "test.s" with just one instruction. I've set up a breakpoint to this single instruction, and it is completely ignored (see the attached screenshot). The debugger only seem to take into account the breakpoints set in the main source. Now I wonder if it has ever worked - as I happen to remember - or it was "just my imagination". Either way, this is an awesome project, pretty sure it will become THE Amiga IDE EDIT: to add more info to my investigation, I've noticed that if I set the instruction in "test.s" at line 5, and start the debug with "stopOnEntry", the debugger will stop at the very beginning of the file, the disassembler will show an empty instruction there. If I then jump one step, the debugger will jump at line 5, where the instruction in "test.s" actually is! Hope this helps understanding what is missing/wrong, cheers! Last edited by emiespo; 18 August 2019 at 23:07. |
|
19 August 2019, 09:14 | #74 |
Registered User
Join Date: May 2018
Location: France
Posts: 246
|
Hopefully it supports multiple files projects ;-).
But be careful, the program starts at the first linked source, you should set it’s name in the settings. Actually there is a bug due to how it’s implemented in fs-uae and extension that prevents adding a breakpoint in the 2 or 3 first lines. So the stoponentry is mandatory in this case. |
20 August 2019, 22:44 | #75 | |
Registered User
Join Date: Jul 2017
Location: Oxford
Posts: 107
|
Quote:
Things I've tried: Include the ".s" inline ---> doesn't work (see attached screenshots) Use a XREF/XDEF pair + a JSR to it later in the source ---> doesn't pick up the breakpoint on the separate file Breakpoints on included files seem to never be encountered. "Test.s" accepts the breakpoint (red dot) while test2.s becomes grey while the debugger is running. |
|
20 August 2019, 23:49 | #76 |
OCS forever!
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 418
|
You can’t set a break point on an included file. You have to not use include. Let the extension auto assemble test.s and test2.s itself and use xref and xdef. It all works fine then. I’ll knock up an example tomorrow
|
21 August 2019, 00:43 | #77 | |
Registered User
Join Date: Jul 2017
Location: Oxford
Posts: 107
|
Quote:
Code:
jsr xrefSymbol The external file looked like: Code:
xdef xrefSymbol xrefSymbol: moveq #0,d0 rts |
|
21 August 2019, 11:07 | #78 |
OCS forever!
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 418
|
Just knocked this up (you'll need to replace the bin folder with your windows/mac binaries)
https://www.autoitscript.com/files/a...de-example.zip 3 files: main.s - entry point test1.s - contains test1Func test2.s - contains test2Func I find it works best if you set the breakpoint first, then build, then run in Debug. Sometimes it doesn't work if you build then set breakpoint. I tried setting a breakpoint in both test1/test2 and it stopped on both. Last edited by Antiriad_UK; 21 August 2019 at 13:00. Reason: Typo |
21 August 2019, 11:57 | #79 |
Registered User
Join Date: May 2018
Location: France
Posts: 246
|
Back, in front of my computer! (sorry for the partial answers)
So I've tried the code... and ... filed a bug to investigate further: https://github.com/prb28/vscode-amig...mbly/issues/90 @emiespo, you're right there is something weird when including a .s file, the produced source does not contain all the lines info and looks like a mess. I must dig some more with a hexdump to see what's happening. The inner part of the simplistic implementation of the build process in the extension is -> build every source file, then link them all (you can select the first one - it's the entry point). It's simple and straightforward for people starting asm on amiga, but it's too simple for a "real" project. And in this case seems to be a bad choice. I've to look what vasm and vlink docs say about this scenario. I don't know if including a ".s" file is support by the -linedebug option. And @Antiriad_uk, thanks! Your solution and support is great. I will add next info in the github issue, just for keeping track of it, feel free to add some comments in it's discussion. |
21 August 2019, 13:02 | #80 | |
OCS forever!
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 418
|
Quote:
You get the same effect with macros or REPT, the debugger jumps to line zero while you are single stepping and then back to the correct line number after. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
assembly code to test for assign (2.0+) | jotd | Coders. System | 2 | 27 December 2017 23:16 |
very basic C/ASM/Visual Studio hand holding | Sephnroth | Coders. C/C++ | 2 | 08 March 2016 20:15 |
Amiga Audio/Visual | KhneFr | request.Other | 6 | 03 January 2015 10:25 |
Profiling WinUAE with Visual Studio 2013 | mark_k | support.WinUAE | 3 | 14 January 2014 20:26 |
amiga visual editor | thinlega | request.Apps | 1 | 22 January 2003 15:48 |
|
|