vscode-amiga-debug now supports Linux, MacOS

[Bartman]

New version 1.6.2 of vscode-amiga-debug available https://marketplace.visualstudio.com...ss.amiga-debug
**Linux & MacOS now supported** Thanks to @PetMac#8708 and Graham Bates
Please do test it out and report issues on the GitHub page!

[walkero]

That's really awesome news. Does it use a modified FS-UAE for this?
Also, is it necessary to use the GCC 12 that comes with the package or we can use any gcc compiler, like for example, the ones from bebbo?

Thank you to everyone involved.

[Bartman]

Yep, Graham ported all the required changes from WinUAE to FS-UAE.
I strongly recommend using the included gcc12, as it produces vastly faster code than the old gcc6. The whole workflow requires ELF files, and bebbo's directly uses amiga hunk files, so that won't work.

[walkero]

@Bartman
Do you have somewhere how do you create that gcc version for linux, and how someone could create his own setup? I am asking because I would like to use it inside a docker container. I tried bebbo's and I had some issues and I wonder if it would be possible to test again with your setup.

[Bartman]

sure, here are the scripts: https://github.com/BartmanAbyss/vsco...tree/master/ci

[girv]

I've ported my project from bebbo/vasm over to gcc12/gas on macOS (also 12). A fresh sample project launches and debugs OK. Mine did for a while and then has seemingly stopped launching fsuae at all.

There's no indication why it might be failing that I can find. I can launch the included fsuae from command line or Finder, but vscode just hangs after you press F5 and the build completes. After some poking around I noticed it's not getting to the part where it updates the dh0/s/startup-sequence with my exe name, FWIW.

Any suggestions?

[gigabates]

Originally Posted by girv

After some poking around I noticed it's not getting to the part where it updates the dh0/s/startup-sequence with my exe name, FWIW.

Any suggestions?

The step right before that is building the symbol table using the output from objdump. You could try running the command yourself to see if it's failing e.g.

~/.vscode/extensions/bartmanabyss.amiga-debug-1.6.4/bin/darwin/opt/bin/m68k-amiga-elf-objdump --section-header out/a.elf

[girv]

Seems to run OK?

22:14 girv ~/projects/RDeclan: ~/.vscode/extensions/bartmanabyss.amiga-debug-1.6.4/bin/darwin/opt/bin/m68k-amiga-elf-objdump --section-header build-debug-bartman/RDeclan.elf

build-debug-bartman/RDeclan.elf:     file format elf32-m68k

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000a7c4  00000000  00000000  00002000  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .rodata       00001768  0000a7c4  0000a7c4  0000c7c4  2**1
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  2 .mbind.rodata 00000270  0000c000  0000c000  0000e000  2**13
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .data         00000a50  0000e270  0000e270  0000e270  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  4 .bss          000025e4  0000ecc0  0000ecc0  0000ecc0  2**2
                  ALLOC
  5 .comment      00000012  00000000  00000000  0000ecc0  2**0
                  CONTENTS, READONLY
  6 .debug_aranges 00000940  00000000  00000000  0000ecd2  2**0
                  CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS
  7 .debug_info   00036a62  00000000  00000000  0000f612  2**0
                  CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS
  8 .debug_abbrev 000073b0  00000000  00000000  00046074  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
  9 .debug_line   0002142f  00000000  00000000  0004d424  2**0
                  CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS
 10 .debug_frame  0000647c  00000000  00000000  0006e854  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS
 11 .debug_str    0000115b  00000000  00000000  00074cd0  2**0
                  CONTENTS, READONLY, DEBUGGING, OCTETS
 12 .debug_loclists 00007bce  00000000  00000000  00075e2b  2**0
                  CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS
 13 .debug_rnglists 00001a76  00000000  00000000  0007d9f9  2**0
                  CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS

[gigabates]

Probably not that then. One other thing to check: are you sure the build is completing? I was having an issue where GCC was hanging on the linking stage for a particular bad object file. Maybe try running the make command in the terminal.

Other than that, I think the next thing would be to run a local build of the extension and step through the code.

[girv]

I'd converted the task to cmake so I didn't have to port everything to makefile, but a clean and build shows no errors and regenerates the elf and exe so I guess it's working.

Any guides on running a local copy of the extension? Not something I've messed with.

[gigabates]

Originally Posted by girv

Any guides on running a local copy of the extension? Not something I've messed with.

Sure, check out or download the project from Github, run 'npm install' and open it in VS Code. You can click the 'Run Extension' task from the Run and Debug tab to open a local build of the extension in a new window [Extension Development Host]. You can then open your project in this window and use the extension as normal, but it will hit any breakpoints that you set in the extension source. I'd maybe set a breakpoint at the start of launchRequest in amigaDebug.ts and step through line by line to see where it's getting stuck.

Alternatively I'm happy to look into it if you're able to share your project source.

[girv]

Got the extension debugging, thanks. That was unexpectedly easy!

It -is- failing at the objdump bit after all.

It's throwing this at symbols.ts:100:

if(sectionName !== "*ABS*" && section === undefined)
    throw new Error(`Section ${sectionName} not found. Symbol: ${name}`);

sectionName == ".mbind.rodata"
name == ".mbind.rodata"

edit 1:
'.mbind.rodata' is not in this.sections so I guess it's not being parsed by getSections().

edit 2:
The line
" 2 .mbind.rodata 00000270 0000c000 0000c000 0000e000 2**13" is not matched by SECTION_REGEX1

edit 3:
Changed the final clause to '2\*\*([0-9]+)' and fsuae launches

[girv]

Next problem, the one I was actually looking into when I hit the problem above It's not profiling.

I can debug step all right but on clicking either of the profiling buttons I get a VSCode popup with something like:

Unable to start profiling:
Error: error parsing UnwindTable in line 2833:
00001d84 r13+8    c-1048 c-1044 c-1040 c-8   c-1036 c-4

[PeterM]

Hello, "@PetMac#8708" here

Really awesome to see people using and enjoying this on non-Windows machines.

Graham Bates did most of the work I think. I mostly faffed around trying to get GCC to build. I expect the FS-UAE changes were not fun.

[girv]

Originally Posted by PeterM

Really awesome to see people using and enjoying this on non-Windows machines.

I've been waiting a year or more for this Since doing my own faffing around getting Bartman's GCC 10 and 11 to build on macOS.

The other thing I'm wondering about - are there any benchmarks comparing bebbo to gcc12 for C99 code? I'd been mostly using bebbo up until now and supporting both in the code is kind of a pain.

[gigabates]

Originally Posted by girv

Changed the final clause to '2\*\*([0-9]+)' and fsuae launches

Glad you figured this out. I've opened a PR with this change. Let's see what's going on with the other error now.

[gigabates]

Originally Posted by PeterM

Graham Bates did most of the work I think. I mostly faffed around trying to get GCC to build. I expect the FS-UAE changes were not fun.

It was a team effort

[girv]

Originally Posted by gigabates

Glad you figured this out. I've opened a PR with this change.

Originally Posted by gigabates

Let's see what's going on with the other error now.

I can send you a zip of the cmake build folder if it will help? It would have the exe, elf, data files and so on.

[gigabates]

Originally Posted by girv

I can send you a zip of the cmake build folder if it will help? It would have the exe, elf, data files and so on.

Just the elf file should be enough for this issue.

edit:
In fact just the output from 'm68k-amiga-elf-objdump --dwarf=frames-interp yourfile.elf' should do it.

[girv]

Sent in PM.