9bb4a86cf0
0xefbfe000) and kernel_start (normally 0xf0100000). Things are unnecessarily (?) difficult because procfs is used to access user addresses in the live-kernel case although we must have access to /dev/mem to work at all, and whatever works for the dead-kernel case should work in all cases (modulo volatility of live kernel variables). We used the wrong range [0, kernel_start) for user addresses. Procfs should only work up to VM_MAXUSER_ADDRESS, but it bogusly works for reads up to the address 2 pages higher (the user area, including the kernel stack, is mapped to where the user area used to be (WTUAUTB)). Procfs can not work at all for addresses between WTUAUTB and kernel_start. Now we use procfs only to access addresses up to VM_MAXUSER_ADDRESS. Higher addresses are translated normally using kvtophys(), so the user ptd is used for addresses below the real kernel start (0xf0000000; see INKERNEL()) and nothing is found WTUAUTB. Strange accesses that cross the user-kernel boundary are now handled, but such ranges are currently always errors because they necessarily overlap the hole WTUAUTB. Short reads are still not handled. |
||
|---|---|---|
| .. | ||
| gdb | ||
| gdbreplay | ||
| gdbserver | ||