Correct backtrace was made more complex when the new signal trampoline
was introduced to support more than 32 signals, while keeping a modified
version of the old signal trampoline.
The 'where' command will now show:
#2 <signal handler called>
where appropiate.
Submitted by: Tor.Egge@fast.no
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.
Correct translations would have been null. However, kstack was
the top of the kernel stack instead of the base of the kernel stack
like it was when the kernel exported it, so the area above the
kernel stack was mistranslated and the kernel stack was not
translated. This bug was depended on to compensate for the wrong
value of kstack - to read the pcb, instead of just using the address
of the pcb, we used the mistranslated address of kstack, which
happened to be the same (curpcb = kstack - 0x2000).
This area is simpler than it used to be now that the kernel stack
address is per-process. The code still seems to be more complicated
than necessary - the `found_pcb == 0' case seems to be unused.
gdb was cloned from the buggy version of kvm_uread() in libkvm and
had the same bugs. It looped endlessly on EOF and checked errno
without setting it in the lseek() error check. The first bug caused
gdb to loop endlessly for reads from addresses between the end of
the user area and the start of the kernel text. kvm_uread() should
not be used for addresses beyond the end of the user area, but is
due to bugs elsewhere.
the previous frame is in the usual place even for traps, interrupts
and syscalls in the kernel, because the assembly language stubs
don't change the frame pointer. The previous frame is just not for
the calling function. We may as well depend on this as on magic to
determine the trap frame address. The magic is in FRAME_SAVED_PC()
which elides the correct number of stubs (1) to go back to a pc that
matches the previous frame.
Removing fbsd_kern_frame_chain() fixes bugs in it. Xsyscall was
misspelled as _Xsyscall (gdb removes one leading underscore), so
the tf_syscall frame type was never found. This was harmless
because tf_normal works in all cases in fbsd_kern_frame_chain()
and Xsyscall is spelled correctly in fbsd_kern_frame_saved_pc()
where it matters. There were style bugs on almost every line,
starting with a primary indent of 7.
following "panic:" or "Fatal trap". `panicstr' is still printed,
although it is redundant if there is a valid message buffer and
incomplete if it contains `%'s. I think the awk command belongs
here and not in a script since a standard format with complete
messages is good for bug reports.
Implemented reading of %fs and %gs from core files.
Print weird floating point values better. We have to convert long
doubles to doubles here because of limitations and bugs in printf()
and floatformat_to_double() (long doubles aren't really supported
and naive converion to double causes exceptions). Conversion loses
information about weird formats (everything becomes a quiet NaN),
and printf() doesn't know about different types of NaNs anyway.
because 2 references to _initialize_kcorelow (the other one
from kvm-fbsd.c) resulted. This prevented gdb from working correectly.
delete kcorelow.c from XSRCS in the Makefile.
punning the pcb to an array of ints and using magic indices to
access values in it. This should prevent silent breakage from
changes in the pcb.
Supply 0 for unavailable registers instead of punning the tss to
an array of ints and using magic indices to access garbage values
in it. (The registers are in the pcb; there is nothing interesting
in the tss. This should change someday. At least for dumps, all
the registers should be saved, and common_tss is a good place to
put them.)
Removed ancient wrong (disabled) method for reading eip.
UPAGES layout.. it was entirely too comfortable with reading and writing
the U area before. I've changed it to use PT_GETREGS/PT_PUTREGS
ptrace ops instead of READ_U etc. The code to read the registers from
core dumps is a bandaid at best. It seems to have problems reading
core dumps from dynamic linked executables still, but at least static
dumps work.
I desperately need help from a gdb/bfd expert. :-) HELP!!
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
1) add Garrett Wollman's trap frame resolving mods
2) make the `proc' command (kernel debugging) really work
3) allow use of a pid with the `proc' command (previously you had to
provide the address of the proc structure)
Unfortunately, the `proc' command won't work while doing remote debugging.
alias `pcb_cr3' instead. That is still one alias too many, but is convenient
for me since I've replaced the tss in the pcb by a few scalar variables in
the pcb.
