qemu SMP support #85
Comments
|
If you do a git log in the freedom-u-sdk/riscv-qemu you will see that it is from April 2018, i.e. it is old. Also, if you do a git log in the linux tree, you will see that it is also old, it is a circa 2017 pre-upstream copy with various patches backported. freedom-u-sdk is a useful tutorial for how to get started with RISC-V linux, but it isn't for real work. You should get up-to-date copies of both the linux kernel and qemu. You can use either the upstream trees where the master sources live, or the riscv/riscv-* trees which are still maintained for now. Yes, smp works. I do "make -j4" builds all of the time on fedora running on qemu, and I see the CPU utilitization for qemu go over 300% in top, which means all 4 threads are doing work. |
|
Hi Wilson, Thanks! I will try this. BR, |
|
If you want a real linux distro, Debian, Fedora, and OpenSuse have working ports that can boot on qemu. Also there is a OpenEmbedded/Yocto port in riscv/meta-riscv if you want something that you can configure and build yourself. There are also other linux ports, and *BSD ports, and RTOS ports, etc. |
|
Sorry, should I call you Jim instead of Wilson? |
|
An American would call me Jim, but Wilson works too. I'm not an OS level programmer. I don't know how that kind of stuff works. |
|
Thanks Jim! |
|
You need a gdb with XML register set support, and a qemu with XML register set support, I've posted patches for qemu both upstream and to riscv-qemu. I need to ping the upstream patches. I'm not sure about the riscv-qemu patches, they may or may not have gone in. XML register set support was added to FSF gdb in November I think, and then riscv-gnu-toolchain was modified to use the FSF gdb port. If you check out riscv-gnu-toolchain you should get the right gdb. binutils and gdb share a common development tree, but have separate release branches. if you check out riscv-binutils-gdb you get the binutils release branch, which probably has a broken gdb. You need the fsf-gdb-with-sim branch for gdb. The fact that we need two different release branches checked out is why riscv-gnu-toolchain has riscv-binutils and riscv-gdb trees that are both from riscv-binutils-gdb. |
|
I had checkout fsf-gdb-with-sim branch from riscv/riscv-binutils-gdb. Any mistake steps? Thanks! |
|
Did you try using the file command like the error message suggests? |
|
Yes, it works fine. But it doesn't support "target remote" commands. |
|
You can use file with target remote. You must provide a file to gdb, otherwise it has no idea what program you are debugging on the remote target. Normally you would provide the file to gdb on the gdb command line. |
|
I don't really understand you, let me explain more.
With the freedom-u-sdk built gdb, I can use the below commands to connect: Add symbol-file only makes me to see the source file. |
|
I am having trouble understanding you also. If I don't have enough info to reproduce your problem, then I may not be able to help you. Usually when you get the error message saying that there is no program, it is user error not specifying a program and the fix is to use the file command as the error message says. You need a gdb with XML register set support, and a qemu with XML register set support. You apparently have the right gdb. Do you have the right qemu? I've submitted patches for riscv-qemu and upstream qemu, but don't know the status of them. See for instance |
You doesn't need to add file or symbols in this method, because gdb are used to connect to the remote gdb server which is provided by qemu.
|
|
Hi Jim,
For help, type "help". The new gdb doesn't connect to qemu successfully. I think this is the issue. |
|
You have the wrong qemu. You need a qemu with gdb-xml/riscv* files. Please keep in mind that the RISC-V architecture is new, and not all toolchain development work is done yet. The gdb xml support was added in Oct/Nov, and then in Nov/Dec I did the qemu xml support, but my qemu patches have not been accepted yet. So you either need to check out my riscv-qemu github branch that has the qemu xml support. Or you need to check out upstream qemu and add my 5 patch set to it. I gave pointers to both in a previous message. |
|
Hi Jim, |
|
By the way, with new tools,my SMP are OK now! Thanks, Jim! |
|
@jim-wilson |
|
Just tested this with upstream riscv32-none-elf-gdb and upstream qemu-system-riscv32, I get the same error as mentioned above: GNU gdb (GDB) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=riscv32-none-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from qemu_compiled_files/lui_qemu.elf...
(No debugging symbols found in qemu_compiled_files/lui_qemu.elf)
Remote debugging using localhost:1234
Remote 'g' packet reply is too long (expected 132 bytes, got 388 bytes): 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
end pos 541065324
No registers.$> qemu-system-riscv32 --version
QEMU emulator version 4.1.50 (v4.1.0-1571-g69b81893bc-dirty)
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers$> riscv32-none-elf-gdb --version
GNU gdb (GDB) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.I built qemu and the riscv32 toolchain from scratch. Anything I missed here? |
|
This looks like an arch disagreement between gdb and qemu. The 388 is 32 * 4 + 32 * 8 + 4, which means you have 32-bit integer registers and 64-bit FP registers. The 132 is 32 * 4 + 4 which means you have 32-bit integer registers and no FP registers. So qemu and gdb have different architecture defaults. Gdb defaults from the binary you are trying to run. If you loaded an elf file, it should get arch defaults from there. I don't know what qemu does offhand, but if you are feeding it a raw file with no ELF headers, then it is probably falling back on some default that may be incorrect for your use case. There is probably some way to pass arch info to qemu, but I don't know it off hand. I mostly use the user-mode qemu which has ELF headers to read. Maybe if you specify a target board that has the right CPU arch on it? The disagreement seems curious though as both gdb and qemu should be using xml register file descriptions so they should be negotiating the number and size of registers when gdb connects to the target. You can see this if you use "set debug remote 1" before the "target remote:1234" command. You didn't provide enough info for me to reproduce. You didn't give the gdb command, the qemu command, or the example binary. This appears to work for me when I try it. |
|
I've rebuilt it with debian buster and now it works. With the new build I also got this message in gdb: However gdb worked regardless of the warning. I've now also built it with libexpat and now the warning is gone. Anyway, thanks for your help. |
Hi Mr/Ms,
There are five machine supported by riscv qemu.
sifive_e
sifive_u
spike_v1.10
spike_v1.9.1
virt
And I found that only virt support cpu number larger than 1 which is SMP. But I met some strange issues when using SMP cpu=4 of virt mahine mode.
For example:
One hart send software interrupt to another hart, the other hart can not receive the interrupt.
But when I ctrl+c to stop the gdb which is attached to the qemu, then just continue by typing "c" command and made no any modification. Then it can receive the software interrupt.
It is weird! Seem ctrl+c trigger the other hart to receive the interrupt.
Yet I don't know whether this is caused by my codes.
And I see the Makefile, seems linux doesn't boot with SMP, only with one hart.
I only want to confirm first, whether the SMP with virt machine mode is supported?
Thanks!
BR,
Peng
The text was updated successfully, but these errors were encountered: