#
259065 |
|
07-Dec-2013 |
gjb |
- Copy stable/10 (r259064) to releng/10.0 as part of the 10.0-RELEASE cycle. - Update __FreeBSD_version [1] - Set branch name to -RC1
[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so start releng/10.0 at '100' so the branch is started with a value ending in zero.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
246893 |
|
17-Feb-2013 |
marcel |
In kthr.c, obtain the address of the PCB for threads that were running on a core, when the core was stopped, by calling kgdb_trgt_core_pcb(). This has 2 advantages: 1. We don't need to include a machine-specific header anymore and as such kthr.c is truly machine independent. This allows the code to be used in a cross-debugger. 2. We don't need to lookup stoppcbs in generic code when it's an inherently target-spicific symbol. It does not exist for ia64.
Implement kgdb_trgt_core_pcb() for all architectures, except ia64, by calling a common function called kgdb_trgt_stop_pcb(). This function differs from kgdb_trgt_core_pcb() in that it gets the size of the PCB structure as an argument and as such remains machine independent.
On ia64 the PCB for stopped cores is in the PCPU structure itself. This for better scaling. The implementation of kgdb_trgt_core_pcb() for ia64 uses the cpuid_to_pcpu[] array to to obtain the address of the PCB structure.
|
#
225017 |
|
19-Aug-2011 |
jhb |
Walk the zombproc list as well as the allproc list when enumerating threads and processes in a kernel image. This allows examination of threads that have exited or are in the late stages of exiting.
Tested by: avg Approved by: re (kib) MFC after: 1 week
|
#
222813 |
|
07-Jun-2011 |
attilio |
etire the cpumask_t type and replace it with cpuset_t usage.
This is intended to fix the bug where cpu mask objects are capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever value. Anyway, as long as several structures in the kernel are statically allocated and sized as MAXCPU, it is suggested to keep it as low as possible for the time being.
Technical notes on this commit itself: - More functions to handle with cpuset_t objects are introduced. The most notable are cpusetobj_ffs() (which calculates a ffs(3) for a cpuset_t object), cpusetobj_strprint() (which prepares a string representing a cpuset_t object) and cpusetobj_strscan() (which creates a valid cpuset_t starting from a string representation). - pc_cpumask and pc_other_cpus are target to be removed soon. With the moving from cpumask_t to cpuset_t they are now inefficient and not really useful. Anyway, for the time being, please note that access to pcpu datas is protected by sched_pin() in order to avoid migrating the CPU while reading more than one (possible) word - Please note that size of cpuset_t objects may differ between kernel and userland. While this is not directly related to the patch itself, it is good to understand that concept and possibly use the patch as a reference on how to deal with cpuset_t objects in userland, when accessing kernland members. - KTR_CPUMASK is changed and now is represented through a string, to be set as the example reported in NOTES.
Please additively note that no MAXCPU is bumped in this patch, but private testing has been done until to MAXCPU=128 on a real 8x8x2(htt) machine (amd64).
Please note that the FreeBSD version is not yet bumped because of the upcoming pcpu changes. However, note that this patch is not targeted for MFC.
People to thank for the time spent on this patch: - sbruno, pluknet and Nicholas Esborn (nick AT desert DOT net) tested several revision of the patches and really helped in improving stability of this work. - marius fixed several bugs in the sparc64 implementation and reviewed patches related to ktr. - jeff and jhb discussed the basic approach followed. - kib and marcel made targeted review on some specific part of the patch. - marius, art, nwhitehorn and andreast reviewed MD specific part of the patch. - marius, andreast, gonzo, nwhitehorn and jceel tested MD specific implementations of the patch. - Other people have made contributions on other patches that have been already committed and have been listed separately.
Companies that should be mentioned for having participated at several degrees: - Yahoo! for having offered the machines used for testing on big count of CPUs. - The FreeBSD Foundation for having sponsored my devsummit attendance, which has been instrumental. - Sandvine for having offered offices and infrastructure during development.
(I really hope I didn't forget anyone, if it happened I apologize in advance).
|
#
210852 |
|
04-Aug-2010 |
jhb |
Change kgdb_lookup() to resolve symbols via GDB instead of via libkvm(3).
|
#
203823 |
|
13-Feb-2010 |
avg |
kgdb: initialize n_type field of nlist entry for kvm_nlist call
kvm_nlist skips lookup for entries that have n_type != N_UNDF. N_UNDF happens to be zero, so n_type typically has a correct value by accident, but not always. Note: jhb has a patch that replaces kvm_nlist use with direct gdb parsing.
MFC after: 5 days X-MFC-Note: unless jhb commits kvm_nlist => kgdb_parse change
|
#
178713 |
|
01-May-2008 |
jhb |
- Change how the vmcore target maps FreeBSD thread IDs to GDB ptids. We now only use the TID and ignore the PID and use pid_to_ptid() to build a ptid treating the TID as a PID. The benefit of this is that the vmcore target now uses the same scheme as GDB's remote targets. As a result, the 'tid' command now works for remote targets (however, it only accepts TIDs and not addresses of 'struct thread' objects). - Use gdb_thread_select() to do the actual thread switch for the 'tid' and 'proc' commands. This now gives the same UI feedback when switching threads as the GDB 'thread' command rather than providing no visual output at all.
MFC after: 1 week
|
#
178670 |
|
29-Apr-2008 |
jhb |
Rework how kgdb manages kernel and vmcore files to be a bit more gdb-ish so that kgdb can be used more like a normal gdb: - Load the kernel via the standard 'exec' target and allow it to be changed via the 'file' command. - Instead of explicitly loading the kernel file as the mail symbol file during startup, just pass it to gdb_main() as the executable file. - Change the kld support (via shared libraries) to cache the address of the linker_files and linker_kernel_file variables in addition to the offsets of various members in 'struct linker_file'. - When a new symbol file is loaded, recompute the addresses and offsets used by the kld support code. - When a new symbol file is loaded, recalculate the ofs_fix variable to account for the different ways a trapframe can be passed to trap frame handlers in i386. This is done by adding a MD kgdb_trgt_new_objfile() hook that is empty on all but i386. - Don't use the directory name of the kernel specified on the command line to find kernel modules in the kld support code. Instead, extract the filename of the current executable via exec_bfd. Now the 'kernel' variable is private to main.c again. - Make the 'add-kld' command explicitly fail if no executable is loaded. - Make the support for vmcores a real core-dump target that opens the kernel and vmcore on open and closes the kvm connection when closed, etc. - The 'core' command can now be used to select a vmcore to use, either a crash dump file or /dev/mem for live debugging. - The 'detach' command can be used to detach from a vmcore w/o attaching to a new one. - kgdb no longer explicitly opens a core dump during startup and no longer has to use an atexit() hook to close the kvm connection on shutdown. - Symbols for kld's are automatically loaded anytime a core is opened. Also, the unread portion of dmesg is dumped just as it was done on kgdb startup previously. - Don't require either a remote target or core dump if a kernel is specified. You can now just run 'kgdb kernel' similar to running gdb on an executable and later connect to a remote target or core dump. - Use a more relaxed way to verify remote targets specified via -r. Instead of explicitly allowing a few non-file target specifications, just assume that if stat() on the arg and on "/dev/" + arg both fail that is some non-file target and pass it to gdb. - Don't use a custom interpreter. The existing kgdb_init() hook and the target_new_objfile() hook give us sufficient hooks during startup to setup kgdb-specific behavior now. - Always add the 'proc', 'tid', and 'add-kld' commands on startup and not just if we have a core dump. Currently the 'proc' and 'tid' commands do not work for remote targets (I will fix at least 'tid' in the next round of changes though). However, the 'add-kld' command works fine for loading symbols for a kernel module on a remote target. - Always setup the 'kld' shared library target operations instead of just if we have a core dump. Although symbols for kernel modules are not automatically loaded when connecting to a remote target, you can do 'info sharedlibrary' after connecting to the remote target and kgdb will find all the modules. You can then use the 'sharedlibrary' command to load symbols from the module files. - Change kthr_init() to free the existing list of kthr objects before generating a new one. This allows it to be invoked multiple times w/o leaking memory.
MFC after: 1 week
|
#
175771 |
|
28-Jan-2008 |
jhb |
Remove the warnx() from kgdb_lookup() so that we don't emit a warning about 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.
|
#
175452 |
|
18-Jan-2008 |
emaste |
Include the thread name (in addition to the proc name) in "info threads."
|
#
173681 |
|
16-Nov-2007 |
jhb |
Teach kgdb how to handle double fault frames on i386: - 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
|
#
167142 |
|
01-Mar-2007 |
kib |
Rename lookup() to kgdb_lookup() and make it global (for use in trgt_i386.c).
No objections from: marcel
|
#
166214 |
|
25-Jan-2007 |
rodrigc |
Try to avoid a possible infinite loop when parsing an invalid kernel dump file.
PR: 108229 Submitted by: Jessica Han <jessicah juniper net> Reviewed by: marcel MFC after: 1 week
|
#
163440 |
|
16-Oct-2006 |
jhb |
Trim trailing whitespace.
|
#
161621 |
|
25-Aug-2006 |
jhb |
Use the pcb in stoppcbs[] if it is present for threads that were running on other CPUs in system when a dump is written.
Submitted by: ups Reviewed by: marcel MFC after: 3 days
|
#
149954 |
|
10-Sep-2005 |
marcel |
Add a kluge to allow kgdb(1) to inject its own frame sniffer in the 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
|
#
142151 |
|
20-Feb-2005 |
kan |
Attempt to make kgdb little more useful and easy to use. Properly initialize 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.
|
#
132624 |
|
25-Jul-2004 |
marcel |
Add the beginnings of kernel debugging support. the kgdb(1) tool 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.
|