-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emulator exited with code/signal 127 before debugger could connect. #242
Comments
seems the emulator crashes before the debugger can connect. Can you try the regular windows version? |
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 |
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? |
Hello, I am running this extension native on Linux and stumbled on the same problem. On my machine the bundled fs-uae cannot open There are at least two workarounds:
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. |
@grahambates do we need to bundle that TTF library? |
We do currently bundle |
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 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 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: vscode-amiga-debug/src/amigaDebug.ts Line 556 in ae6e6c7
Changing Looks like Quote from manpage:
|
After running fs-uae directly in terminal I can see this problem:
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. |
We use a FS-UAE fork with added gdbserver functionality. https://github.com/grahambates/fs-uae/tree/remote_debugger_barto |
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. |
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.. |
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 |
yeah that TAR isn't the problem, the problem is creating the .vsix with |
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. |
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. |
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?
The text was updated successfully, but these errors were encountered: