[solved] PCIe config space access hangs on aarch64

[linuxyne]

Could you let me know what the issue with linking the bootloader was? Is there something I need to fix or document on my side to help people build it?

The problem is with linking bootaa64.efi. It seems the behaviour of lld-link differs between versions 12.0.1 and later, for instance, 14.0.6.

The lld-link command links boot.dir obj files with those in libmetal.a. The boot.dir obj files use symbols from obj files inside libmetal.a, but the linker isn't able to pull/find those symbols even though they are present.

A workaround is to modify the following line inside boot/src/CMakeLists.txt:

Code: Select all

#diff
-target_link_libraries(boot PRIVATE metal)
+target_link_libraries(boot PUBLIC metal)

Another workaround is to add the switch -wholearchive to the linker commandline.

With any of those workarounds, "make run" successfully builds the required components and launches qemu-system-aarch64.

Edit: The kernel too links with metal, but there the linker doesn't need any changes.

Edit2: The kernel is an ELF binary while bootaa64.efi is an EFI binary.

[kzinti]

I added jobs to the CI to test with clang 13,14 and 15. I was expecting the builds to fail as you reported. But to my surprise, they all pass without me having to change anything.

See https://github.com/kiznit/rainbow-os/ac ... 3383182645

Versions tested:
- clang 12.0.1
- clang 13.0.1
- clang 14.0.6
- clang 15.0.4

[linuxyne]

I added jobs to the CI to test with clang 13,14 and 15. I was expecting the builds to fail as you reported. But to my surprise, they all passed without me having to change anything in the CMakeLists.txt.

See https://github.com/kiznit/rainbow-os/ac ... 5618850596

Versions tested:
- clang 12.0.1
- clang 13.0.1
- clang 14.0.6
- clang 15.0.4

Thanks.

This means that my setup differs somewhere. I will see if I can find out the difference.

Edit: Found the difference.

My host machine runs ArchLinux. In order to compile rainbow-os, I had installed clang and lld packages, assuming that these, and other dependencies they pull, should be sufficient.

But with this setup, the problem occurs. If I additionally install the llvm package, the problem goes away.

The ArchLinux clang package lists the llvm package as optional, and so it doesn't automatically install llvm when installing clang.

Thus, the problem occurs on such an incomplete environment when trying to link EFI binaries.

When I used the version 12.0.1, I had it downloaded from llvm.org. I suspect that using 14.0.6 from llvm.org, instead of installing it from Arch packages, should also work without any problems.

I do not know enough about Arch packages, LLVM components, and EFI binaries, to say what it is that was missing. LLVM/Clang should have complained about its missing components, instead of refusing to find symbols. But it is more likely that the Arch packaging is at fault - llvm package may not be as optional as it thinks it is, especially when dealing with EFI/Windows binaries.

Apologies for the inconvenience.

[kzinti]

Apologies for the inconvenience.

There was no inconvenience and there is no need to apologize. There could have been an issue with my build setup. You helped me a lot here and I appreciate it.