a junk pointer and possibly causing a seg fault if we don't have any
non-kernel klds (or are unable to walk the list due to core / kernel
mismatch).
MFC after: 1 week
kgdb(8) now treats kld's as shared libraries relative to the kernel
"binary". Thus, you can use 'info sharedlibrary' to list the kld's
along with 'sharedlibrary' and 'nosharedlibrary' to manage symbol
loading and unloading. Note that there isn't an easy way to force GDB
to use a specific path for a shared library. However, you can use
'nosharedlibrary' to unload all the klds and then use 'sharedlibrary'
to load specific klds where it gets the kld correct and use
'add-kld' for the kld's where the default open behavior doesn't work.
klds opened via 'sharedlibrary' (and during startup) do have their
sections listed in 'info files'.
- Change the 'add-kld' command to use filename completion to complete its
argument.
and build a section table from the kernel file so that 'info files' output
for kgdb now matches the usage of gdb on a regular file with the exception
that we don't list sections for memory in the crash dump.
- Add a new 'kgdb_auto_load_klds()' routine which is invoked during
startup that walks the list of linker files and tries to find a matching
kld on disk for each non-kernel kld. If a kld file is found, then it
is added as if the 'add-kld' command is invoked. One change from
'add-kld' is that this method attempts to use the 'pathname' from the
linker_file structure first to try to load the file. If that fails
it then looks in the kernel directory followed by the directories in
the module path.
- Move the kld file suffix handling into a separate routine so that it
can be called standalone and to reduce duplicate code in find_kld_path().
- Cache the offsets of members of 'struct linker_file' during startup
instead of computing them for each 'add-kld'.
- Use GDB's target_read_string() instead of direct KVM access.
- Add all resident sections from a kld by using bfd_map_over_sections() to
build the section list rather than just adding symbols for ".text",
".data", ".bss", and ".rodata".
- Change the 'add-kld' command to do a y/n prompt before adding the
symbols when run interactively to match 'add-symbol-file'.
MFC after: 1 week
optional symbols that are missing (e.g. kgdb complains about _stoppcbs and
_stopped_cpus on UP kernels). Instead, callers that really want their
symbols to be present now do explicitly warnx() about the missing symbol.
crash dumps with kernel modules. The command is basically a wrapper
around add-symbol-file except that it uses the kernel linker data
structures and the ELF section headers of the kld to calculate the
section addresses add-symbol-file needs.
The 'kld' parameter may either be an absolute path or a relative path.
kgdb looks for the kld in several locations checking for variants with
".symbols" or ".debug" suffixes in each location. The first location it
tries is just opening the specified path (this handles absolute paths and
looks for the kld relative to the current directory otherwise). Next
it tries to find the module in the same directory of the kernel image
being used. If that fails it extracts the kern.module_path from the
kernel being debugged and looks in each of those paths.
The upshot is that for the common cases of debugging /boot/kernel/kernel
where the module is in either /boot/kernel or /boot/modules one can merely
do 'add-kld foo.ko'.
MFC after: 1 week
- Save td_oncpu in 'struct kthr' so the i386 target code can see which CPU
a thread is running on.
- Add a new frame unwinder for double fault frames. This unwinder is used
when "dblfault_handler" is encountered in the stack. It uses the CPU of
the current thread to lookup the base address of the TSS used for the
double fault from the GDT. It then fetches the various registers out
of the TSS similar to how the current trapframe unwinder fetches
registers out of the trapframe.
MFC after: 3 days
first getting the current state with td_thr_getxmmregs_p. Without this,
debugging a threaded app that uses libthr resulted in kernel panics or
spurious SIGFPEs for me.
(As of revision 1.6, sys/i386/i386/ptrace_machdep.c masks off the
reserved bits in the mxcsr register, which prevents the kernel panics.)
Architectures without PT_GETXMMREGS are not affected.
MFC after: 1 week
least on i386)... fbsd-* changes started out as s/linux/fbsd/g and then
additional changes to handle different ptrace defines among other things..
(use vfork to eliminate a race for progress group creation)
reg-i386.c is generated by regdat.sh..
mode. This allows one to use kgdb on /dev/mem and be able to patch memory
on a live system. This is identical to what -wcore used to do in previous
gdb versions for FreeBSD.
Requested by: wpaul
list of frame sniffers so that trapframes can be detected. The kluge
is needed because this version of gdb only supports appending a
sniffer to the list of sniffers and the moment kgdb gets a chance to
add its own frame sniffer, the target's default frame sniffer is
already in the list. Since the default frame sniffer claims any
frame thrown at it, kgdb's frame sniffer never gets to smell (a
process much akin to tasting, but with lesser chance of hurling :-)
This commit adds dummy frame sniffers that never claim a frame and
as such don't fix anything yet. However, we now have frame sniffers
and they are being called, so it's just a matter of adding meat to
the bones and we'll be able to properly unwind across trapframes.
MFC after: 1 week
command does, but worse.
o Remove the obscure proc command, because it does what the thread
command does, but not unambigously.
o Move the PID to the extra thread info, where it makes sense and
where it doesn't confuse users. The extra thread info holds some
process information, to which the PID belongs.
o Implement the to_find_new_threads target method by having it call
the target beneath us if we're not using KVM. This makes sure that
new threads are found when using the remote target.
o Fix various core dump scenarios:
- Implement the to_files_info target method. Previously the
'info target' command would cause a NULL pointer dereference.
- Don't assume there's a current thread. We're not initialized
in all cases. This prevents a NULL pointer dereference.
- When we're not ussing KVM, have the to_xfer_memory target
method call the target beneath us. This avoids calling into
KVM with a NULL pointer.
MFC after: 1 week
static.
o Register a function with atexit(3) to close the KVM object if
we have one open.
o Show the unread portion of the kernel's message buffer before
presenting the prompt. It's bound to provide some useful info.
o Don't call kgdb_target() twice. It results in having all threads
listed twice.
MFC after: 1 week
in future calls, so we can't free it here. The right place to free the
buffer would be to be after kvm_close(), but we don't do that yet. A
static buffer would work too.
Reviewed by: marcel (who has other plans for this anyway)
Approved by: re
it to recognise what ABI to use on amd64 (and possibly others) platform.
Display PID and process name as a part of the 'info threads' output, TIDs
alone are too confusing. Introduce new commmands 'tid <tid>' and 'proc <pid>'
to accompany gdb's default 'thread <thread num>' to make the task of switching
between different contexts easier.
lwp ID before invoking the underlying target operation.
For corefiles, we rely on gdb internals to do this, and it uses the
pid as an index, rather than the lwpid, so previously, backtraces
for multithreaded core files wasn't working correctly. For processes,
we currently use ptrace directly, so fixup that code to also use
the pid directly.
Discussed With: marcel, davidxu
MFC After: 4 days
solib-svr4.c to the MD makefiles because they are native files for
alpha and sparc64, but target files for amd64, i386 and ia64.
Note that kgdb(1) does not yet build as a cross-debugger due to
libkvm.
Document all options and general usage.
Implement the -a option to bump the annotation_level. This improves
the Emacs gud behaviour. You can now supply the following function
(defun gud-gdb-massage-args (file args) (cons "-a" args))
(e.g. by evaluating it from the *scratch* buffer) and get the normal
jump to the source window when browsing the stack.
We should probably eventually supply our own kgdb submode to gud.el.
Implement the -a option to bump the annotation_level. This improves
the Emacs gud behaviour. You can now supply the following function
(defun gud-gdb-massage-args (file args) (cons "-a" args))
(e.g. by evaluating it from the *scratch* buffer) and get the normal
jump to the source window when browsing the stack.
We should probably eventually supply our own kgdb submode to gud.el.
changes, start on a new line. Insertion of a filename will keep the
diff limited to the block of filenames that have the same first letter
instead of creating a huge diff. While here, move remote.c after the
remote-*.c files and move tui.c after the tui-*.c files. This matches
the order of ls(1) and makes it easier to compare object files created
by a stock gdb(1) build with the list of files we have here.
This is a non-functional change only.
make sure it is a device. GDB special cases these prefixes and treats
:#### as a tcp port on localhost and executes what ever follows '|'.
This allows kgdb to debug via dconschat.
Discussed with: marcel
with the currently running kernel image. Otherwise, one of -c, -n or
-r is expected for working on a particular core file (-c), working
on a saved dump (-n) or working remotely (-r). When working on a
saved dump, a kernel may be omitted.
For a remote debugging session (-r), kgdb(1) will use the specified
device.
is basicly a shell on top of libgdb that knows about kernel threads,
kernel modules and kvm(3). As the word "beginnings" implies, not
all of the features have been implemented yet. The tool is useful
and I'd like feedback on the taken route.
The simplest way to debug a kernel core file is:
kgdb -n 0
This opens /var/crash/vmcore.0 with the corresponding kernel in
the object directory (kernel.debug is used if it exists).
Typical things that need to be added are:
o Auto loading of kernel modules,
o Handling of trapframes so that backtraces can be taken across
them,
o Some fancy commands to extract useful information out of a core
file,
o Various (probably many) other things.
that have been added to <sys/procfs.h>. This change has no effect
because the source file that would be affected is not compiled on
FreeBSD. Hence, this is for completeness only.
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.
bsd.man.mk doesn't include ${.CURDIR}/../Makefile.inc.
Removed GDBDIR-redefinition-prevention ifdef. It hasn't done anothing
for a long time, if ever. The directory is defined to the same value in
each subdir and had the same value because all subdirs are at the same
level. Keep defining it in the subdirs since that is more flexible and
no more verbose.
Prepare to inherit BINDIR by including ../Makefile.inc.
requires the new file.
Fixed stale near-copy of contrib/libreadline/doc/hsuser.texinfo. Patch
it at build ntime, and only keep the patch for it here.
Don't keep a copy of contrib/gdb/gdb/doc/all-cfg.texi here. Link to it
at build time.
Fixed stale near-copy of contrib/libreadline/doc/hsuser.texinfo. Patch
it at build ntime, and only keep the patch for it here.
Don't keep a copy of contrib/gdb/gdb/doc/all-cfg.texi here. Link to it
at build time.
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.
reference to the programming manual. Use this near-copy of the version
of hsuser.texinfo in contrib/libreadline instead of the stale near-copy
in contrib/gdb.
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!!
"%%" in format strings and tends to dump core for "%%st". I needed
"%%st" to fix the new gdb ...
Don't use the private version of strerror() either.
Use INTERNALLIB and INTERNALSTATICLIB instead of a private install
rules NOPROFILE and NOPIC. This is only slightly cleaner.
INTERNALLIB was previously only used in compatibility libraries
(libgnumalloc etc.) and INTERNALSTATICLIB was previously unused.
INTERNAL*LIB probably should be replaced by something like NOSTATICO
together with NO{STATICO,PROFILE,PIC}INSTALL.
by the -DNO_MMALLOC flag in gdb/Makefile.
The one thing we lose by doing this, AFAIK, is the possibility of using
mmap. Does anyone use that feature at all ?
2.2 candidate ?
files using the texi sources in /usr/src/contrib/gdb/gdb/doc.
I put a pointer to /usr/src/contrib/libreadline/doc into
Makefile.inc in the hope that the appropriate files would be
picked up.
This is based on /usr/ports/devel/gdb.
2.2 candidate ?
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.
> * the gdb-4.13 of current (compiled and used under 2.0R) can not attach to my
> own processes (it works only then i'm root - else i get open failed - for my
> own processes)
how embarassing ! This turns out to be a bug in infptrace.c. Below
is a patch. Could some kind soul apply it ?
Submitted by: "Gary J." <garyj@rks32.pcs.dec.com>
of the linker to enforce linking of modules in command line order it is
not possible to link gdb shared with -lcompat.
*HACK ALERT*
Removed -lcompat from LDADD and bring in the necessary functions out of
libcompat as a source module until the linker can be fixed.
