"start_image() returned Load Error" when built against gnu-efi 3.0.18

[nl6720]

If rEFInd is built against gnu-efi 3.0.18, I get

start_image() returned Load Error

in VirtualBox (I didn't test on real hardware yet). Booting is not possible.

This is using Arch Linux package refind 0.14.1-1 (currently in the testing repo) which is built against the gnu-efi 3.0.18-1 package.

Rebuilding refind 0.14.1 against Arch package gnu-efi 3.0.17-3 makes it work.

See Arch Linux bug: https://gitlab.archlinux.org/archlinux/packaging/packages/refind/-/issues/2

[nl6720]

Build logs attached.

[nl6720]

I bisected gnu-efi and the offending commit is https://github.com/ncroxon/gnu-efi/commit/262c1f4604dded6485ef338345487c421ab3c8cb

[Roderick W. Smith]

To quote Marge Gunderson ("Fargo"), "I'm not sure I agree with you a hundred percent on your police work there, Lou."

Poking through the Sourceforge git repo for GNU-EFI, I find that the following commit is the troublesome one:
https://sourceforge.net/p/gnu-efi/code/ci/deb8a7f267d96299b9aa41300539f617db54c2a9

All commits prior to that one work fine for me, but once I build with that one, it fails in the way you describe.

The commit in question changes SetMem() and CopyMem() to use the EFIAPI calling convention, and makes a couple more small changes. I'm looking into this to figure out precisely what's going wrong, but haven't found the answer just yet....

[Roderick W. Smith]

Further information: It's also necessary to add -j .rodata as an objcopy option. This may well be related to the commit you identified, @nl6720. (I'd been experimenting with that and forgot I had it set when I found the EFIAPI commit.)

[Roderick W. Smith]

I think I've got this sorted out. There are actually three problems:

• The change you identified that causes failures to launch if -j .rodata is not used with objcopy. This was the easiest to deal with.
• The commit I identified, which changed the way CopyMem() was defined. This one's weird; it was as if the rEFInd build process was ignoring the EFIAPI option on that function, thus calling it with the wrong ABI. Maybe it was; the rEFInd build process is pretty convoluted. I've worked around the problem by using a new custom function and calls to gBS->CopyMem(). Without this workaround, rEFInd would crash upon launch.
• GNU-EFI 3.0.17 introduced changes that affected the objcopy options used to build ARM64/AARCH64 binaries. I've added support for setting these options in the Make.common file.

My changes are still a little rough around the edges, so I haven't committed them yet, but I hope to do so this week.

[Roderick W. Smith]

I've pushed my changes to the git repository. Could you please try them, @nl6720? They work for me on Ubuntu 22.04 on x86-64, Ubuntu 24.04 pre-release on ARM64, and Arch Linux on ARM64. Both the Ubuntus used a locally-built GNU-EFI 3.0.18, but the Arch used the Arch GNU-EFI 3.0.18 package. I'm afraid I don't have a working Arch installation on x86-64 for testing. Note that the ARM64 build change requires editing Make.common or passing GNUEFI_ARM64_TARGET_SUPPORT=y when using GNU-EFI 3.0.17 or later; see NEWS.txt or BUILDING.txt for details. This is not required on x86-64 systems.

[nl6720]

Build at commit c1a97f5780259de42d80f9dfdedbe17e4fa86051 works fine! 🎉