3rd-party/linux-kernel-module-cheat
1
0
Fork 0
mirror of https://github.com/cirosantilli/linux-kernel-module-cheat.git synced 2026-01-27 12:04:27 +01:00
Code Issues Releases Wiki Activity

gem5: update to 7fa4c946386e7207ad5859e8ade0bbfc14000d91

Browse Source 
The main motivation is to fix the aarch64 GDB stub with
b5cc34d767410e98f54f2955bb274f0f8c3708e4
This commit is contained in:
Ciro Santilli 六四事件 法轮功
2019-01-22 00:00:00 +00:00
parent 3ce152f61c
commit 76b5744fee
2 changed files with 1 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
README.adoc
View File

@@ -9273,44 +9273,12 @@ When you want to break, just do a `Ctrl-C` on GDB shell, and then `continue`.
And we now see the boot messages, and then get a shell. Now try the `/count.sh` procedure described for QEMU: <<gdb-step-debug-kernel-post-boot>>. And we now see the boot messages, and then get a shell. Now try the `/count.sh` procedure described for QEMU: <<gdb-step-debug-kernel-post-boot>>.
===== gem5 GDB step debug kernel aarch64
TODO: GDB fails with:
....
Reading symbols from vmlinux...done.
Remote debugging using localhost:7000
Remote 'g' packet reply is too long: 000000000000000090a4f90fc0ffffff4875450ec0ffffff01000000000000000100000000000000000000000000000001000000000000000000000000000000ffffffffffffffff646d60616b64fffe7f7f7f7f7f7f7f7f0101010101010101300000000000000000000000ffffffff48454422207d2c2017162f21262820160100000000000000070000000000000001000000000000004075450ec0ffffffc073450ec0ffffff82080000000000004075450ec0ffffff8060f90fc0ffffffc073450ec0fffffff040900880ffffff40ab400ec0ffffff586d900880ffffff0068a20ec0ffffff903b010880ffffffc8ff210880ffffff903b010880ffffffccff210880ffffff050000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
....
See: <<remote-g-packet-reply-is-too-long>>
and gem5 says:
....
4107766500: system.remote_gdb: remote gdb attached
warn: Couldn't read data from debugger.
4107767500: system.remote_gdb: remote gdb detached
....
I've also tried the fix at: https://stackoverflow.com/questions/27411621/remote-g-packet-reply-is-too-long-aarch64-arm64 by adding to the link:run-gdb[] script:
....
-ex 'set tdesc filename out/aarch64/buildroot/build/gdb-7.11.1/./gdb/features/aarch64.xml'
....
but it did not help.
https://www.mail-archive.com/gem5-users@gem5.org/msg15383.html
==== gem5 GDB step debug userland process ==== gem5 GDB step debug userland process
We are unable to use `gdbserver` because of networking: <<gem5-host-to-guest-networking>> We are unable to use `gdbserver` because of networking: <<gem5-host-to-guest-networking>>
The alternative is to do as in <<gdb-step-debug-userland-processes>>. The alternative is to do as in <<gdb-step-debug-userland-processes>>.
First make sure that for your arch the kernel debugging on the given target works for the architecture: <<gem5-gdb>>, on which we rely. When we last tested, this was not the case for aarch64: <<gem5-gdb-step-debug-kernel-aarch64>>
Next, follow the exact same steps explained at <<gdb-step-debug-userland-non-init-without--d>>, but passing `-g` to every command as usual. Next, follow the exact same steps explained at <<gdb-step-debug-userland-non-init-without--d>>, but passing `-g` to every command as usual.
But then TODO (I'll still go crazy one of those days): for `arm`, while debugging `/myinsmod.out /hello.ko`, after then line: But then TODO (I'll still go crazy one of those days): for `arm`, while debugging `/myinsmod.out /hello.ko`, after then line:
@@ -10361,8 +10329,6 @@ This is specially interesting for the executables that don't use the bootloader
The cool thing about those examples is that you start at the very first instruction of your program, which gives more control. The cool thing about those examples is that you start at the very first instruction of your program, which gives more control.
`aarch64` gem5 GDB step debug is broken as mentioned at: <<gem5-gdb-step-debug-kernel-aarch64>>.
=== Baremetal bootloaders === Baremetal bootloaders
As can be seen from <<baremetal-gdb-step-debug>>, all examples under link:baremetal/[], with the exception of `baremetal/arch/<arch>/no_bootloader`, start from our tiny bootloaders: As can be seen from <<baremetal-gdb-step-debug>>, all examples under link:baremetal/[], with the exception of `baremetal/arch/<arch>/no_bootloader`, start from our tiny bootloaders:
@@ -11876,8 +11842,6 @@ Sources:
* link:build-test-gdb[] * link:build-test-gdb[]
* link:test-gdb[] * link:test-gdb[]
Not all of them are passing right now due to: <<gem5-gdb-step-debug-kernel-aarch64>>.
If something goes wrong, re-run the test commands manually and use `--verbose` to understand what happened: If something goes wrong, re-run the test commands manually and use `--verbose` to understand what happened:
.... ....

2
submodules/gem5

Submodule submodules/gem5 updated: a5bc229139...7fa4c94638