Qemu on Haiku (SDL issue?)

Software Native
1

I’ve installed SDL and SDL_image, so that qemu could theoretically have a proper GUI instead of using VNC. It compiles just fine. Using it is problematic.

First, these message appears:

Unlocking BLocker with sem 453597 from wrong thread 23285, current holder 23287 (see issue #6400).
GalliumContext: CreateScreen: Using llvmpipe (LLVM 7.0, 256 bits) driver.
Unlocking BLocker with sem 453653 from wrong thread 23305, current holder 23307 (see issue #6400).

Issue 6400 is marked as closed, but is it resolved? That issue references 11860, which it says is the place to discuss OpenGL issues, but it too is marked as closed.

Should I open a new issue?

Second issue: The qemu binary opens a few windows, presumably with SDL. One to show the screen, one for console, and others. The OS never loads, best I can tell. The screen says “Guest has not initialized the display (yet)”. However, these qemu windows aren’t closeable and qemu can’t be quit. The only thing to do is to force poweroff my laptop. Ctrl-C doesn’t work, ProcessController is useless, and trying a reboot/shutdown says “Application ‘qemu-system-x86_64’ has aborted the shutdown process”. Is there a way to force-quit the application, or is this related to the BLocker issue above?

Edit: This is on hrev55207, bare metal, latest libsdl 1.2 from HaikuDepot.

2

BLocker wouldn’t do that. It looks like something is stuck in a system call waiting for it to return. Your problem is probably not in SDL then.

The BLocker warning is only a warning. It turns out this way of using BLocker is explicitly allowed in the Be Book, and we implement it correctly. Personally, knowing this, I think we should remove this warning message, but other developers didn’t agree with that.

With SDL 1.2 it is not possible to open multiple windows. It is purely single-window. Are you sure you are using SDL 1.2 and not SDL 2.0 or the native Haiku backend of QEMU?

Also, did you look at the patches at Haikuports for qemu?

There are various patches needed to get it working:

1 Like
3

Thank you, I missed that patch file. I thought it was SDL 1.2, but a quick check of the configure script shows checking pkg-config for SDL2. I didn’t know there was a native backend for Haiku, so I’ll look in to that.

It does seem this patchset might fix some mips-specific issues, so thanks again.

4

You can use following options to hide additional windows:

-serial stdio -parallel none -monitor none.

Are you sure that you disable PIE when configuring build?

5

I’ve been meaning to ask about this. I saw your issue on HaikuPorts regarding this. I tried to disable it, but qemu throws an error with the configure script about not having pthreads. I did a quick test with a dummy program, and gcc won’t link against the pthreads library when -fno-pie is used, which qemu’s configure script uses when --disable-pie is given.

> gcc -o test test.c -lpthread -fno-pie
/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld: /tmp//ccdBm2rd.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status

I suppose pthread could be disabled with qemu, but I wonder if that would be a loss in functionality.

6

I edited configure script a bit in my build. Explicit -fno-pie is not needed, -fpic should be used by default if no other arguments are specified.

7

What then is the difference? Best I can tell, pie is position independent code for executables, and pic is position independent code for shared libraries. How did you handle this in your configure script? I can work on upstreaming it into qemu.

8

Haiku have no executables in Linux meaning, only shared libraries. Haiku executable is shared library with non-null entry point. The only “real” executable is runtime_loader that is started by kernel for each process and it loads executables and shared libraries in the same way.

Both -fpie and -fno-pie should be not used.
My current patch (hack):

diff --git a/configure b/configure
index 4f374b4..88e6758 100755
--- a/configure
+++ b/configure
@@ -1631,8 +1631,7 @@ case "$cpu" in
            QEMU_LDFLAGS="-m64 $QEMU_LDFLAGS"
            ;;
     i386)
-           CPU_CFLAGS="-m32"
-           QEMU_LDFLAGS="-m32 $QEMU_LDFLAGS"
+           CPU_CFLAGS=""
            ;;
     x86_64)
            # ??? Only extremely old AMD cpus do not have cmpxchg16b.
@@ -2223,9 +2222,9 @@ fi
 
 # Detect support for PT_GNU_RELRO + DT_BIND_NOW.
 # The combination is known as "full relro", because .got.plt is read-only too.
-if compile_prog "" "-Wl,-z,relro -Wl,-z,now" ; then
-  QEMU_LDFLAGS="-Wl,-z,relro -Wl,-z,now $QEMU_LDFLAGS"
-fi
+#if compile_prog "" "-Wl,-z,relro -Wl,-z,now" ; then
+#  QEMU_LDFLAGS="-Wl,-z,relro -Wl,-z,now $QEMU_LDFLAGS"
+#fi
 
 ##########################################
 # __sync_fetch_and_and requires at least -march=i486. Many toolchains
3 Likes
9

As I understand it all executables in haiku are shared libraries, and PIE cannot be used. This was also what caused the webkit build to fail, it should probably be patched in gcc that the PIE flag has no effect.

2 Likes
10

Probably a good idea to sidestep this issue.

11

Looking more at qemu, I see that TPM support is disabled in the recipe. Trying to push the change to the qemu configure script to disable TPM for Haiku was met with resistance on the qemu-developers mailing list. Their thinking is that the configure script would test for TPM support (it doesn’t) and enable it appropriately (it enables TPM if not explicitly disabled).

Compiling with TPM support works fine, but running it causes an assertion failure: util/async.c:669:qemu_set_current_aio_context(). @X512 have you encountered this?

12

I didn’t explicitly disable TPM and it work fine.

Can you get stack trace?

static __thread AioContext *my_aiocontext;

This is TLS variable that works correctly only when PIE is not used. Are you sure that PIE problem is solved?

13

No, I haven’t yet addressed it. I’ll work on it next. Thanks!