Emulator exited with code/signal 127 before debugger could connect.

[ssav7912]

Hi, whenever I try and launch the init project via VS Code I get a pop-up with this error: Emulator exited with code/signal 127 before debugger could connect.

Building works fine, I have pointed the config to a valid Kickstart ROM, and I can launch and debug the executable separately in WinUAE, however this is a bit unpleasant. I am using WSL, which may be related, although I am on a version with GUI support. Any pointers as to what this error means or how I could solve it?

[BartmanAbyss]

seems the emulator crashes before the debugger can connect. Can you try the regular windows version?

[ssav7912]

Can confirm the native windows version does work. WSL should be capable of calling to windows if invoking a windows executable, but I did try this on the winuae-gdb.exe and while WinUAE does launch, it locks up immediately. Running under windows works well though so not too concerned about making WSL behave.

[BartmanAbyss]

I suspect the problem is if you're using WSL that you're using the Linux version that comes with FS-UAE, probably that's not compatible with WSL. Any specific reason you're not using the native Windows version?

[Tiiffi]

Hello,

I am running this extension native on Linux and stumbled on the same problem.

On my machine the bundled fs-uae cannot open libSDL2_ttf-2.0.so shared object.

There are at least two workarounds:

1. Use LD_PRELOAD=/path/to/libSDL2_ttf-2.0.so ./fs-uae to launch the emulator (you might need to add more dependencies here)

2. Install missing library packages from your package manager (in my case libsdl2-ttf-2.0-0 on Debian / Ubuntu)

Note that this might happen with other shared objects too. Try running the bundled fs-uae manually to see what is happening.

Alternatively you can print bundled fs-uae shared object dependencies with ldd to see if some shared object dependencies are missing.

---

In addition to this problem I had to manually add execute flag to all bundled binaries.

[BartmanAbyss]

@grahambates do we need to bundle that TTF library?

[grahambates]

We do currently bundle libSDL2_ttf-2.0.so.0 in the linux dir. I'll look into why this isn't being loaded in this case.

[Tiiffi]

Hi,

I'm not an expert on these things, but my understanding is that Linux doesn't look for dynamic libraries in the current path by default.

So my suggestion is to set environment variable LD_LIBRARY_PATH to . or '$ORIGIN' (or whatever is the correct library path) before launching the emulator. This can be done via launch script or perhaps the vscode extension has already some other way to do it.

Shell script for example:

#!/bin/sh

# Set dynamic loader search path to current binary path and pass command line arguments ("$@")
LD_LIBRARY_PATH='$ORIGIN' /path/to/fs-uae "$@"

Alternatively, if you compile the emulator yourself, you can tell the linker to add a custom search path using the -rpath flag.

More details about the dynamic loader here: https://man7.org/linux/man-pages/man8/ld.so.8.html

---

Edit:

I had time to investigate bit further and looks like there was already this kind of thing in place: https://github.com/BartmanAbyss/vscode-amiga-debug/blob/ae6e6c7f7a04a258e1b02a480901457fae0a8be7/src/amigaDebug.ts#L556

Changing LD_LIBRARY_PATH: "." to LD_LIBRARY_PATH: "$ORIGIN" seems to make it work properly.

Looks like "." alone points to project workspace directory.

Quote from manpage:

$ORIGIN (or equivalently ${ORIGIN}) This expands to the directory containing the program or shared object. Thus, an application located in somedir/app could be compiled with

              gcc -Wl,-rpath,'$ORIGIN/../lib'

          so that it finds an associated shared object in
          somedir/lib no matter where somedir is located in the
          directory hierarchy.  This facilitates the creation of
          "turn-key" applications that do not need to be installed
          into special directories, but can instead be unpacked into
          any directory and still find their own shared objects.

[Hypexed]

After running fs-uae directly in terminal I can see this problem:

$ cd '/home/damien/.vscode/extensions/bartmanabyss.amiga-debug-1.7.7/bin/linux/fs-uae' 
$ ./fs-uae 
./fs-uae: error while loading shared libraries: libSDL2_ttf-2.0.so.0: cannot open shared object file: No such file or directory
$ LD_LIBRARY_PATH="." ./fs-uae 
./fs-uae: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./fs-uae)
./fs-uae: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./fs-uae)
$ dpkg -s libc6 | grep Version
Version: 2.31-0ubuntu9.16

It also relies on other core libs that may not be present in system as is the case here. I'm running Mint 20.3.

Can fs-uae be compiled as static instead to avoid all these problems? I already have FS-UAE installed and working. So it doesn't make sense to me another fs-uae doesn't work. Another solution would be to divert it to the existing fs-uae if it exists. At /usr/bin/fs-uae in my case. I didn't see a clear way to do that.

[BartmanAbyss]

We use a FS-UAE fork with added gdbserver functionality. https://github.com/grahambates/fs-uae/tree/remote_debugger_barto If you can modify/improve the build, we gladly accept a pull request. As said, I don't know much about Linux, so I can't help there.

[Hypexed]

Thanks for commenting. I thought it would be customised with a debugger somehow. The binutils are set up as static from what I can tell so UAE just needs to be compiled the same way and it should be fine. Another issue is binaries needing execute permission. I thought VSCode would handle that if it does indeed support Linux as a platform. But setting them does require root.

[BartmanAbyss]

ahh... yeah the permissions are an issue. I build the extension on Windows so the permissions get lost, and we compensate that in the extension. But if setting permissions requires root, it probably won't work right...

There seems to be always a problem compiling things statically on linux. Previously we could build gdb statically, but now it's no longer possible due to some new dependencies. And I think if you use OpenGL you can't build statically anyway, so that's probably the reason for UAE. All in all it's a pretty disappointing situation. We even try to build UAE on an older Ubuntu so it has better compatibility..

[Hypexed]

I tried to find info on this in VS docs but it was unclear to me. Got as far as workspace security. But this looks more simple than it seems after some tests.

If the install needs a post fix for the permissions then that will need root since a chmod +x requires root. But I think that complicates it and shouldn't be needed. I just did a test and Tarred up exe2adf with x bit. Unpacked elsewhere. Execute still set. So they don't need any post fix up. Just need to archive it correctly.

According to this script it's already set up to pack up the binaries correctly. But, what tar is running, Windows tar? And where are the file sourced from? If the files are built from a Windows filesystem this will break I imagine unless there are ways around it. Same as if Amiga scripts were LhA'ed or Zipped on Windows the protection bits would be lost. This wouldn't be a new problem, it's simply how to build a Linux app from Windows. But I don't know if it needs a VM or WSL or is even simpler.

https://github.com/BartmanAbyss/vscode-amiga-debug/blob/master/ci/archive-linux.sh

[BartmanAbyss]

yeah that TAR isn't the problem, the problem is creating the .vsix with vsce package. The .vsix file is basically a zip file, but as I'm on Windows, there aren't any permissions to preserve going into the zip. If you know a method that can inject the permissions into the vsix or zip (don't know if permissions are signed), then I could add that.

[Hypexed]

Perhaps the solution is in the script I linked. Tar up the binaries for Mac/Linux. Then include the tar as another binary file and extract it. At this point the extension installer can do that. Since it looks like it can run a post script for installing that should be possible. That looks like the easiest way. Of course it means all binaries need to be moved into a tar file which may be annoying but that is one solution.

[Hypexed]

@BartmanAbyss

I've done some research. The solution it looks is to use a platform target. So you may need to split out Linux/OSX Unix based targets into their own extension. This would reduce clutter but also require to separate binaries. Unless files/folders can be marked as common or platform to ease it. Using a CI or GH action should automate this but my knowledge for that is only basic.

https://code.visualstudio.com/api/working-with-extensions/publishing-extension#platformspecific-extensions

https://code.visualstudio.com/api/working-with-extensions/publishing-extension#why-does-vsce-not-preserve-file-attributes