code in ipl.s and icu_ipl.s that used them was removed when the
interrupt thread system was committed. Debuggers also knew about
Xresume* because these labels hide the real names of the interrupt
handlers (Xintr*), and debuggers need to special-case interrupt
handlers to get the interrupt frame.
Both gdb and ddb will now use the Xintr* and Xfastintr* symbols to
detect interrupt frames. Fast interrupt frames were never identified
correctly before, so this fixes the problem of the running stack
frame getting lost in a ddb or gdb trace generated from a fast
interrupt - e.g. when debugging a simple infinite loop in the kernel
using a serial console, the frame containing the loop would never
appear in a gdb or ddb trace.
Reviewed by: jhb, bde
Note ALL MODULES MUST BE RECOMPILED
make the kernel aware that there are smaller units of scheduling than the
process. (but only allow one thread per process at this time).
This is functionally equivalent to teh previousl -current except
that there is a thread associated with each process.
Sorry john! (your next MFC will be a doosie!)
Reviewed by: peter@freebsd.org, dillon@freebsd.org
X-MFC after: ha ha ha ha
reading old a.out core files, which are totally 100% non-understandable
to the gdb floating-point reader if you have SSE turned on.
This should be the last of the world build breakers...
call and trap entry points so they're easy to find and change
- Use the cpuhead and allcpu list to locate globaldata for the current
cpu, rather than SMP_prvspace or __globaldata
- Use offsets into struct globaldata directly to find per-cpu variables,
rather than symbols in globals.o
Glanced at by: peter
when using gdb on a remote target. The fix is to restrict PT_GETDBREGS
calls to `child' and `freebsd-uthreads' targets solely.
I've been in some conversation with Brian about this, and this solution
seems to be the most appropriate one.
PR: gnu/21685
Submitted by: bsd
`wait.h' that was in contrib/binutils/, however this wait.h went away with
bintuils 2.10.0 so I `cvs rm'ed it. Now we find gdb will not build. This
binutils wait.h contained nothing we didn't already have in <sys/wait.h>.
So just hack a symlink to it.
with Brian's kernel support for i386 debug registers. This makes
watchpoints actually usable for real-life problems. Note: you can
only set watchpoints on 1-, 2- or 4-byte locations, gdb automatically
falls back to [sloooow] software watchpoints when attempting to use
them on variables which don't fit into this category. To circumvent
this, one can use the following hack:
watch *(int *)0x<some address>
David O'Brien is IMHO considering to get this fully integrated into the
official GDB, but as long as we've got the i386/* files sitting around
in our private FreeBSD tree here, the feature can now be tested more
extensively, so i'm committing this for the time being.
This work has been done in order to debug a tix toolkit problem, thus
it has been sponsored by teh Deutsche Post AG.
Reviewed by: bsd (not the operating system, but Brian :-)
libraries in LDADD so that `make checkdpadd' doesn't report non-errors.
Fixed some style bugs (the usual ones for DPADD and LDADD, and misformatting
of $FreeBSD$).
kernel's) curproc is null. This fixes endless recursion in
xfer_umem() for attempts to read from user addresses, in particular
for attempts to read %fs and %gs from the pcb for `info reg'.
worked because .ORDER prevented problems from concurrent generation
of multiple parsers (and their headers), and there were no missing
dependencies because the generated headers were not actually used.
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.
