Hi, I've spent a bit of time debugging this, and by adding setjmp.h to efi/main.c and removing the ampersand from the longjmp()/setjmp() calls (provided a patch in #1091027), I was able to get a working EFI syslinux.
I've used the following configuration for testing: PROMPT 1 TIMEOUT 50 DEFAULT debian LABEL debian LINUX /vmlinuz INITRD /initrd.gz LABEL localboot LINUX .localboot The localboot option actually tests the longjmp() call in efi/main.c, and it successfully returns me to the EFI shell in qemu with OVMF, and I even tried it on my own computer where I added a boot entry for EFI/syslinux/syslinux.efi, and after invoking localboot, it switched to the next boot entry, which was grub, my primary bootloader on this system. However, all of what I've mentioned above applies to the 64-bit image. I was unable to get the 32-bit image running in qemu with OVMF. What happens is that it writes a bunch of space characters, and then quits, throwing me back to the EFI shell prompt. Interestingly enough, I get the same behavior when I try to use the pre-compiled syslinux-6.03 from kernel.org, but when I try to use the syslinux-6.03_8.i686 package from Void Linux, that one actually works. Another interesting thing is that when I've enabled debugging by defining the CORE_DEBUG and DEBUG_STDIO macros, the 32-bit image actually works too, so perhaps it might have to do with some optimizations that cause issues, or perhaps some race condition where the outcome is altered by debugging messages being printed. It's possible that this race condition also happens on the 64-bit syslinux, because I thought I observed such behavior on the 64-bit version as well under qemu, but I can't seem to reproduce it now. It's also possible that I jus got my files mixed up during testing. Either way, I think that's a separate bug from the setjmp() bug, and I think that one is taken care of by adding setjmp.h to efi/main.c. Best Regards, Marek
