doc: FATAL: kernel too old failure in userland simulation improve a bit

This commit is contained in:
Ciro Santilli
2022-05-13 09:38:54 +01:00
parent ed3bd763af
commit 3accfcda21

View File

@@ -4178,7 +4178,7 @@ At 125d14805f769104f93c510bedaa685a52ec025d we <<libc-choice,moved Buildroot fro
glibc has a check for kernel version, likely obtained from the `uname` syscall, and if the kernel is not new enough, it quits.
Both gem5 and QEMU however allow setting the reported `uname` version from the command line, which we do to always match our toolchain.
Both gem5 and QEMU however allow setting the reported `uname` version from the command line for <<user-mode-simulation>>, which we do to always match our toolchain.
QEMU by default copies the host `uname` value, but we always override it in our scripts.
@@ -4190,7 +4190,7 @@ Determining the right number to use for the kernel version is of course highly n
Source: link:userland/posix/uname.c[].
The QEMU source that does this is at: https://github.com/qemu/qemu/blob/v3.1.0/linux-user/syscall.c#L8931
The QEMU source that does this is at: https://github.com/qemu/qemu/blob/v3.1.0/linux-user/syscall.c#L8931 The default ID is just hardcoded on the source.
Bibliography:
@@ -4198,8 +4198,6 @@ Bibliography:
* https://stackoverflow.com/questions/53085048/how-to-compile-and-run-an-executable-in-gem5-syscall-emulation-mode-with-se-py/53085049#53085049
* https://gem5-review.googlesource.com/c/public/gem5/+/15855
The ID is just hardcoded on the source:
==== stack smashing detected when using glibc
For some reason QEMU / glibc x86_64 picks up the host libc, which breaks things.