Cross Compiling QEMU for RISCV

[sadulla...@gmail.com]

Hi RISC-V community,

I am trying to cross-compile RISCV-qemu to be able to use on RISC-V architecture. I am planning to cross compile qemu on my intel machine, OS: linux-ubuntu and targets will be riscv64-linux-user and riscv32-linux-user. I disabled as much library as possible for now to minimize the errors. This is my configuration setting:

 ./configure --cross-prefix=riscv64-unknown-linux-gnu- --target-list=riscv64-linux-user,riscv32-linux-user  --static --disable-zlib-test --prefix=configure-folder/ --disable-werror --disable-debug-info --disable-debug-tcg --enable-docs --disable-tcg-interpreter --enable-attr --disable-brlapi --disable-linux-aio ... ( more disables )

Unfortunately, this returned me:

ERROR: pkg-config binary 'riscv64-unknown-linux-gnu-pkg-config' not found

I do not now why riscv64 does not have this tool while intel has, i.e. there is x86_64-linux-gnu-pkg-config on my machine.

If I set c++ and c flags instead of providing a cross-prefix, I am getting this error:

ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.

       You probably need to set PKG_CONFIG_LIBDIR

       to point to the right pkg-config files for your

       build target

This seems normal, most probably it is looking for the default pkg-config which is x86_64 and giving this error.

Last thing that I tried is to set PKG_CONFIG_LIBDIR env. variable to point of riscv pkg-config file. However I am not able to find the path of it.

I will be appreciated to hear your feedbacks about these errors. Also, I am welcome to hear any other suggestions to cross compile qemu for risc-v architecture. As far as I see, there is no support for backend side of qemu for riscv, I am planning to try --enable-tcg-interpreter option and see if it works or not.

Thanks,

Sadullah

[Liviu Ionescu]

> On 15 Jul 2017, at 01:28, sadulla...@gmail.com wrote:
>
> Hi RISC-V community,
>
> I am trying to cross-compile RISCV-qemu to be able to use on RISC-V architecture.

just curious on your use case: what platforms do you plan to emulate while running qemu on risc-v?


regards,

Liviu

[Stefan O'Rear]

I did this last year with a non-cross compilation environment (since
cross-compilation is very fiddly as you've discovered); it compiles
fine but fails to link due to atomic_char requiring -latomic on
riscv64 but not on x86_64, and the qemu build system not knowing about
-latomic. I didn't try to go further than that.

-s

[sadulla...@gmail.com]

For now, I am planning to emulate risc-v binary on RISC-V architecture. It may sound weird, but it is required for my research at this point.

[sadulla...@gmail.com]

By non-cross compilation environment, do you mean that you try to compile it on RISC-V architecture? Can you elaborate it ? I was also planning to use riscv-debian to compile qemu. However, it does not include gcc and it is too missing as far as I see. Documentation does not exist so that it is not useful for me at this point.

[Michael Clark]

It’s not weird at all. It’s a great idea.

I’d be curious about comparing the resulting codegen emitted by TCG i.e. RISC-V -> TCG IR -> RISC-V

Fabrice has a copy of RISCVEMU embedded in the RISCVEMU image.

It would be particularly interesting to have a BPF style language for matching and rewriting machine code instead of packets. The BPF engine already uses a JIT.

- substitute loads and stores ala valgrind

- aspect oriented system programming e.g.

audit shared library calls by rewriting PLT stubs. strace/dtrace but for dynamic functions.

Valgrind is a memory debugger, but with a probe language that has access to ELF dynamic symbols, and was aware of PLTs and what not would be quite powerful. dtrace for userspace.

A lot of this stuff can be done with Intel PIN on x86 however Intel PIN is proprietary. The xed decoder is now open.

[1] http://www.tcpdump.org/papers/bpf-usenix93.pdf

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/7bd2229d-08be-4db4-915f-22decb3dc16d%40groups.riscv.org.

[Stefan O'Rear]

On Fri, Jul 14, 2017 at 7:31 PM, <sadulla...@gmail.com> wrote:
> By non-cross compilation environment, do you mean that you try to compile it
> on RISC-V architecture? Can you elaborate it ? I was also planning to use
> riscv-debian to compile qemu. However, it does not include gcc and it is too
> missing as far as I see. Documentation does not exist so that it is not
> useful for me at this point.

riscv-fedora does.

I set up a little thing for architecture emulation containers:
https://hub.docker.com/r/sorear/fedora-riscv-wip/

Be advised this has a gcc older than the released 7.1 and as such it
is not ABI-compatible with the 7.1 gcc.

-s

[sadulla...@gmail.com]

Hi Stefan,

I made some progress to compile qemu for RISCV. Currently, the problem is that  compiling user-level model qemu is not supported if the arch is RISCV. It is clear in configure file, 

# For user-mode emulation the host arch has to be one we explicitly

# support, even if we're using TCI.

if [ "$ARCH" = "unknown" ]; then

  bsd_user="no"

  linux_user="no"

fi

Unfortunately, RISCV is also unknown in this case. I set linux_user variable to 'yes' to see what will happen and noticed that I am getting error while compiling user-exec.c

:error host CPU specific signal handler needed

As far as I see I should define a cpu_signal_handler for RISCV but not sure. In your e-mail, you stated that you were able to compile successfully. Do you remember how you solved this problem or did you face with this problem before?

Best, 

Sadullah