English Amiga Board


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

 
 
Thread Tools
Old 21 August 2019, 14:30   #81
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,484
Quote:
Originally Posted by prb28 View Post
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.
No, not yet. Sorry.
-linedebug is currently a Q&D solution in the hunk output module, which always puts the name of the main source file in the LINE debug header.

I already implemented a more sophisticated source file management for DWARF debug sections. So the information is theoretically available. I might have a look in improving -linedebug over the next days...
phx is offline  
Old 21 August 2019, 15:01   #82
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 114
Quote:
Originally Posted by phx View Post
No, not yet. Sorry.
-linedebug is currently a Q&D solution in the hunk output module, which always puts the name of the main source file in the LINE debug header.
Thanks for this info.
And what about the macros ?
I imagine it's the same problem.


Quote:
Originally Posted by phx View Post
I already implemented a more sophisticated source file management for DWARF debug sections.
Maybe the way to go is to implement the DWARF parsing in the extension. I've started reading the specs.. but it's a long way to go !
prb28 is offline  
Old 21 August 2019, 17:44   #83
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,484
Quote:
Originally Posted by prb28 View Post
And what about the macros ?
I imagine it's the same problem.
Yes, quite similar. Macros and repetitions also create a new source text instance with their own line numbers. But in this case I should better fetch the real line number from the parent source structure.

Quote:
Maybe the way to go is to implement the DWARF parsing in the extension. I've started reading the specs.. but it's a long way to go !
Unfortunately DWARF sections make no sense with Amiga hunk format. Unless you define a method to hide them in HUNK_DEBUG blocks. But I don't want to define a new debug-format here.

Let me have a look at improving -linedebug first.
phx is offline  
Old 21 August 2019, 22:08   #84
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 26
Quote:
Originally Posted by Antiriad_UK View Post
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.
Hey thanks everyone for taking time to look at this It would be great for me even to have it working with xref / xdef blocks.

Still, while this simple example seems to be working right, simply adding xdef/xrefs to the copper example project is quite flaky, at least on my setup (OSX). Sometimes breakpoints only work in one file, don't know why...

Anyway, having separate modules seems to be a good coding practice, I'm going to refactor my real project into smaller modules (and go for a makefile in the meantime).

I will add all of your names to the credits thanks!...
emiespo is offline  
Old 22 August 2019, 00:22   #85
Antiriad_UK
Registered User

 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 142
Send me your project and I’ll have a look. jon @ autoitscript.com
Antiriad_UK is offline  
Old 22 August 2019, 15:58   #86
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,484
Quote:
Originally Posted by prb28 View Post
Thanks for this info.
And what about the macros ?
I imagine it's the same problem.
Ok, now I analyzed the source and know what to do. The problem with macros and repetitions is easy to solve. Currently they store the line number from inside their own macro/rept-block, so I only have to offset it with the current line number of the real parent source text.

To allow inclusion of code from different source texts I would have to add another DEBUG-LINE hunk with a base-offsets and a different file name, just like the linker would do when merging multiple files. When returning from an include another DEBUG-LINE hunk has to be created which resets the file name and current section offset of the previous source.

Working on it...

EDIT: Done. First tests look ok. Macros, repetitions and multiple source files are supported. Please try tomorrow's vasm source snapshot: http://sun.hasenbraten.de/vasm/index.php?view=source

Last edited by phx; 22 August 2019 at 19:55. Reason: Update
phx is offline  
Old 24 August 2019, 01:39   #87
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 114
Quote:
Originally Posted by phx View Post
EDIT: Done. First tests look ok. Macros, repetitions and multiple source files are supported. Please try tomorrow's vasm source snapshot: http://sun.hasenbraten.de/vasm/index.php?view=source
Thanks !

I've tests it and the included file's breakpoints are resolved.
I'll bundle it the next release.
prb28 is offline  
Old 24 August 2019, 11:14   #88
Antiriad_UK
Registered User

 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 142
Thanks phx, that’s great of you!

Edit: Works great for rept

Last edited by Antiriad_UK; 24 August 2019 at 17:29. Reason: Tested
Antiriad_UK is offline  
Old 31 August 2019, 03:04   #89
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 26
Thanks again from me, I'll be waiting for the next release.

In the meantime I did two things:
  • built vlink and vasm from the nightly sources
  • converted all my include --> include sources into separate modules, + STRUCT(s) (from exec/types), relocated all variables into a separate module

...the debugger seems to pick up breakpoints sometimes - but fails after a few steps - especially on jsr/rts - and seems to also mess fs-uae status (I see the stack pointer getting corrupted during subroutine X, but if I put the breakpoint right after subroutine X, it works up until the next jsr.

I've also noticed that changing the emulated machine changes mileage with the debugger. So it seems that fs-uae is also responsible for these issues.

Hope this information might help. Soon this will be the Amiga development environment.

Better than an asm/C compiler + debugger there could only be a Blitz Basic compiler + debugger (Blitz supports including asm sources if I am not mistaken ).

Cheers!
emiespo is offline  
Old 31 August 2019, 11:50   #90
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 114
Quote:
Originally Posted by emiespo View Post
...the debugger seems to pick up breakpoints sometimes...
That's interesting, if you find a way to reproduce it, please add an issue in the github project. I'll try to fix it.



Quote:
Originally Posted by emiespo View Post

I've also noticed that changing the emulated machine changes mileage with the debugger. So it seems that fs-uae is also responsible for these issues.
Yes it comes from fs-uae and even if I got my hand on it, it's still a dark place for me.
I always found the stack trace weird, the first lines (in the program) are normally ok but the rest.... looks like a fs-uae inner mess.



Quote:
Originally Posted by emiespo View Post


Hope this information might help. Soon this will be the Amiga development environment.
Better than an asm/C compiler + debugger there could only be a Blitz Basic compiler + debugger (Blitz supports including asm sources if I am not mistaken ).
There are other projects emerging to debug amiga emulator from sources !
Like beebo's gcc with eclipse and bartman with gcc and vscode.
They should fit better for "THE Amiga development environment contest" than mine !


And it's open source so help and push requests are welcome !



Thanks for you return !
prb28 is offline  
Old 10 September 2019, 01:30   #91
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 26
Quote:
Originally Posted by prb28 View Post
That's interesting, if you find a way to reproduce it, please add an issue in the github project. I'll try to fix it.
I found a way to get rid of it actually! Let me explain what I did: I tried to reinstall everything from scratch on a Windows machine... given the totally different env - and the fact that the config file was in a hidden folder, thus not synched by Google drive - I used a config file copied from the pre-built dev environment, and slightly adapted it to my project.

You know what? It worked! No longer a stuck debugger and skipped breakpoints... I then copied this config over to my OSX env, and guess what? It also works. As simple as it sounds, it might be a good advice to tell people to stick with the default config or else the debugger might stop working...

I'll now resume my project, stay tuned! ;-)
emiespo is offline  
Old 10 September 2019, 23:40   #92
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 114
Quote:
Originally Posted by emiespo View Post
You know what? It worked!
Happy to hear that ! But it's still a mystery for me...



I'll keep it in mind for next issues.


Quote:
Originally Posted by emiespo View Post
I'll now resume my project, stay tuned! ;-)
Happy coding ! Have fun !
prb28 is offline  
Old 15 September 2019, 15:12   #93
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 26
Quote:
Originally Posted by prb28 View Post
Happy to hear that ! But it's still a mystery for me...



I'll keep it in mind for next issues.



Happy coding ! Have fun !
So I made some more tests. What works is the default config with A1200 as the emulated machine, and the AROS ROM replacement. If I switch to a real ROM (OS 3.1) the debugger starts misbehaving badly.

Another couple of issues:
  1. Macros can't be debugged, the disassembler doesn't show anything, but you can still put a breakpoint and press play out of them. Not a big deal ;-)
  2. The BSR/BRA instructions lock the debugger if you press the "Step Over" icon, while they work fine with "Step Into". This could possibly be fixed, I assume

Thanks again, making again some progress...

OT: does anyone know of a site with some examples of decent os-friendly Intuition programming? I've noticed that Piru's startup doesn't work with AROS 68K, I get a blank screen now, so I am looking into opening a standard Intuition screen and manage double buffering manually (replacing the bitmap pointers is all I need).

Cheers!
emiespo is offline  
Old 16 September 2019, 20:44   #94
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 114
Quote:
Originally Posted by emiespo View Post
So I made some more tests. What works is the default config with A1200 as the emulated machine, and the AROS ROM replacement. If I switch to a real ROM (OS 3.1) the debugger starts misbehaving badly.
Never tried the OS 3.1 rom, I'll try it.
Quote:
Originally Posted by emiespo View Post
Macros can't be debugged, the disassembler doesn't show anything, but you can still put a breakpoint and press play out of them. Not a big deal ;-)
I'll add issue on github and test it. Thanks.
Quote:
Originally Posted by emiespo View Post
The BSR/BRA instructions lock the debugger if you press the "Step Over" icon, while they work fine with "Step Into". This could possibly be fixed, I assume
Yes that's a point in the first implementation of the fs-uae debugger from emoon. First I thought it had to be modified (I'm used to java/C debuggers)... but for assembly code it may make sense like that.
If there are some other points of view, I would like to ear them !
prb28 is offline  
Old 16 September 2019, 22:55   #95
emiespo
Registered User

 
Join Date: Jul 2017
Location: Oxford
Posts: 26
Quote:
Originally Posted by prb28 View Post
If there are some other points of view, I would like to ear them !
Well, one more insight on this:
Code:
jsr
seems to work as expected, ie the skip button works. I wonder if it's the fact that the assembled code might have a difference due to optimizations there? as in a "bra.s" converted to "bra.w" or "jmp"?
emiespo is offline  
Old 21 September 2019, 18:42   #96
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 114
New Release 0.18:
  • Numerical popups with parametrized format and ASCII representation
  • Format a document with TABs
  • Enhanced formatting for generated data: dc.w $0 -> dc.w $0000
  • Gdb protocol review (new fs-uae binaries)
  • Bug fixes (windows uppercase filename in debug and others)
prb28 is offline  
Old 30 September 2019, 19:58   #97
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,001
Is the 0.18 example workspace supposed to work out of the box? When I try to launch the debug config, I get a dialog saying "Invalid program to debug -review launch settings".
In "launch.json", it says:
"windows": {
"emulator": "${workspaceFolder}/bin/fs-uae.exe",
},

and when I run that exe manually, I get an Aros kickstart screen.
I just installed the vscode extension and haven't used any earlier versions.

vscode 1.38.1, windows 10 64bit.

edit: the run config seems to work. and after running that, debug also seems to run, but doesn't stop at breakpoints.

Last edited by hooverphonique; 30 September 2019 at 20:18. Reason: add info about run config
hooverphonique is offline  
Old 30 September 2019, 21:09   #98
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 114
Quote:
Originally Posted by hooverphonique View Post
Is the 0.18 example workspace supposed to work out of the box?
You're right it should.
And.. it's not working on windows.
Sorry !

Quote:
Originally Posted by hooverphonique View Post
edit: the run config seems to work. and after running that, debug also seems to run, but doesn't stop at breakpoints.
At least, I saw that, in the workspace file, the binaries are missing a ".exe".
Try to build again (with the button on the status bar).


I'm not on a windows right now but I'll check it later and will update the release tonight.
prb28 is offline  
Old 30 September 2019, 21:46   #99
prb28
Registered User

 
Join Date: May 2018
Location: France
Posts: 114
Seems to work out of the box on windows.

Please try :
  • Open the workspace in vscode (not the folder)
  • Open gencop.s file
  • Build the source with the build button on the status bar
  • Place a breakpoint in line 32
  • Select the debug config
  • Type F5

You should stop on line 32.

It works on my windows 10 64b worstation.
Tell me if it worked.
prb28 is offline  
Old 30 September 2019, 22:26   #100
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,001
Quote:
Originally Posted by prb28 View Post
Seems to work out of the box on windows.

Please try :
  • Open the workspace in vscode (not the folder)
  • Open gencop.s file
  • Build the source with the build button on the status bar
  • Place a breakpoint in line 32
  • Select the debug config
  • Type F5

You should stop on line 32.

It works on my windows 10 64b worstation.
Tell me if it worked.
Yes, this seems to work now - I tried the stopOnEntry as true once, which worked, then set it back to false, and then breakpoints worked - it could very well have been something else I did that "fixed" it though.. Thanks!


Btw, I think there's a rogue "emulator" line in launch.json line 9.


I made a couple of pull requests for some fixes to gencop.s btw
hooverphonique 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 05:02.


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