English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 16 June 2019, 20:18   #61
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 111
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...
prb28 is offline  
Old 16 June 2019, 23:20   #62
Jeeg
Registered User

Jeeg's Avatar
 
Join Date: Jun 2016
Location: France
Posts: 8
I set the stopOnEntry and trace to true and after rebuilding the project it worked. Thank you very much for your advices.
Jeeg is offline  
Old 11 August 2019, 13:03   #63
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 26
Quote:
Originally Posted by Jeeg View Post
I set the stopOnEntry and trace to true and after rebuilding the project it worked. Thank you very much for your advices.
Hi, I'm facing the same issue. I've tried to delete the build folder, but no lack.

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 13:19.
emiespo is offline  
Old 11 August 2019, 16:10   #64
Antiriad_UK
Registered User

 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 112
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)
Antiriad_UK is offline  
Old 11 August 2019, 16:27   #65
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 26
Quote:
Originally Posted by Antiriad_UK View Post
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)
Thanks. In fact I've noticed that before deleting the build folder, I had a lot of ".o" files in there... now it tries to build a single file every time I save it, and obviously it doesn't work as it can't find macros, etc...

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...
emiespo is offline  
Old 11 August 2019, 18:52   #66
Antiriad_UK
Registered User

 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 112
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
Antiriad_UK is offline  
Old 12 August 2019, 10:17   #67
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 111
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.
prb28 is offline  
Old 12 August 2019, 10:46   #68
Antiriad_UK
Registered User

 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 112
Nice. I’ll take a look
Antiriad_UK is offline  
Old 15 August 2019, 01:26   #69
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 26
Quote:
Originally Posted by prb28 View Post
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.
I've used vasm to get the list of files - from the includes - to generate a makefile, and it worked seamlessly from the command line. Something like:

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...
emiespo is offline  
Old 15 August 2019, 01:36   #70
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 111
Quote:
Originally Posted by emiespo View Post
I've used vasm to get the list of files - from the includes - to generate a makefile, and it worked seamlessly from the command line. Something like:

vasm -depend=list ...
Please check that :

- you use the vasm option : -linedebug
- The launch.json configuration parameter "program" is correct
prb28 is offline  
Old 17 August 2019, 01:12   #71
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 26
Quote:
Originally Posted by prb28 View Post
Please check that :

- you use the vasm option : -linedebug
- The launch.json configuration parameter "program" is correct
Thanks for your reply. My config seems to be correct, I guess that the environment is trying to assemble all files as separate object files (.o) and this confuses the linker.

Now I get a bunch of:

Code:
Error 21: init_copperlist.o (CODE+0x7e): Reference to undefined symbol CprPln1.
...if I try to define those symbols, eventually I get:

Code:
Error 19: /build/main.o: Global symbol bplxmod from main.o is already defined in copperlist.o.
It seems that main is already including the symbol, but since "vlink" is called on all the .o files generated singularly, it gets confused as it sees some symbols twice.

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...
emiespo is offline  
Old 17 August 2019, 09:56   #72
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 111
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).
prb28 is offline  
Old 18 August 2019, 23:41   #73
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 26
Quote:
Originally Posted by prb28 View Post
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).
Thanks a lot for your support!

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!
Attached Thumbnails
Click image for larger version

Name:	Screenshot 2019-08-18 at 21.33.05.png
Views:	36
Size:	144.0 KB
ID:	64145   Click image for larger version

Name:	Screenshot 2019-08-18 at 22.03.33.png
Views:	29
Size:	90.0 KB
ID:	64146  

Last edited by emiespo; 19 August 2019 at 00:07.
emiespo is offline  
Old 19 August 2019, 10:14   #74
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 111
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.
prb28 is offline  
Old 20 August 2019, 23:44   #75
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 26
Quote:
Originally Posted by prb28 View Post
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.
I still think it doesn't work properly I was already using the "entrypoint" option.

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.
Attached Thumbnails
Click image for larger version

Name:	Screenshot 2019-08-20 at 21.38.13.png
Views:	26
Size:	151.1 KB
ID:	64165   Click image for larger version

Name:	Screenshot 2019-08-20 at 21.34.40.png
Views:	22
Size:	64.9 KB
ID:	64166   Click image for larger version

Name:	Screenshot 2019-08-20 at 21.34.21.png
Views:	24
Size:	71.6 KB
ID:	64167  
emiespo is offline  
Old 21 August 2019, 00:49   #76
Antiriad_UK
Registered User

 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 112
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
Antiriad_UK is offline  
Old 21 August 2019, 01:43   #77
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 26
Quote:
Originally Posted by Antiriad_UK View Post
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
I've tried that as well... I've added a
Code:
jsr xrefSymbol
code was executed fine, but the breakpoint (in the external file) was not picked up.

The external file looked like:

Code:
     xdef xrefSymbol

xrefSymbol:
     moveq #0,d0
     rts
emiespo is offline  
Old 21 August 2019, 12:07   #78
Antiriad_UK
Registered User

 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 112
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 14:00. Reason: Typo
Antiriad_UK is offline  
Old 21 August 2019, 12:57   #79
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 111
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.
prb28 is offline  
Old 21 August 2019, 14:02   #80
Antiriad_UK
Registered User

 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 112
Quote:
Originally Posted by prb28 View Post
@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.
Yeah I saw that when I opened up a file in hex (I was just curious how any of this works at all!). Saw that it's linenumber/source file based.
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.
Antiriad_UK is offline  
 


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 28 December 2017 00:16
very basic C/ASM/Visual Studio hand holding Sephnroth Coders. C/C++ 2 08 March 2016 21:15
Amiga Audio/Visual KhneFr request.Other 6 03 January 2015 11:25
Profiling WinUAE with Visual Studio 2013 mark_k support.WinUAE 3 14 January 2014 21:26
amiga visual editor thinlega request.Apps 1 22 January 2003 16:48

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 10:32.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.09207 seconds with 14 queries