Commit graph

14 commits

Author SHA1 Message Date
Will Andrews
5cabf7777e KGDB: Accept KLD symbol files with the ".symbols" extension.
Submitted by:	gibbs
Approved by:	ken (mentor)
Sponsored by:	Spectra Logic
MFC after:	1 month
2013-03-28 17:07:02 +00:00
Will Andrews
c89d0ca50b KGDB: Allow modules to be loaded from the specified kernel's directory.
When looking up the absolute path for a kld, call find_kld_path() first.
This enables locating the module in a different directory than the one
stored in kernel memory.

With this change, kgdb can now be run on a kernel & vmcore whose associated
modules are located in the same directory as the kernel.  This makes
independent triaging of problems much easier.

This change also does not break the normal kgdb use case where no arguments
are specified; in that case kgdb loads the running kernel and its modules.

Reviewed by:	adrian
Approved by:	ken (mentor)
Sponsored by:	Spectra Logic
MFC after:	1 month
2013-03-28 17:04:59 +00:00
Andriy Gapon
7996bf419b kgdb: correctly map sections to addresses in elf object modules (amd64)
Unlike for modules with dso type, in elf object modules all the sections
have virtual address of zero.  So, it is insufficient to add module base
address to section virtual address (as recorded in section header) to
get section address in kernel memory.
Instead, we should apply the same calculations that are performed by
kernel loaders (in boot code and in kernel) when they lay out sections
in memory.

Discussed with:	jhb, np
MFC after:	3 weeks
2010-07-23 17:21:23 +00:00
John Baldwin
27f38446be Oops, initialize sections and sections_end to NULL.
Submitted by:	Navdeep Parhar
MFC after:	1 week
2008-10-02 20:42:10 +00:00
John Baldwin
59c47d99be Use existing GDB routines for parsing the section table of klds in
the 'add-kld' command instead of doing it more by hand.

MFC after:	1 week
2008-09-25 19:32:03 +00:00
John Baldwin
3461a0f244 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
2008-04-29 20:32:45 +00:00
John Baldwin
064e8b005f Remove the 'add_kld_command' arg from load_kld(). It is always true since
the auto-loading of kld's switched to hooking into gdb's shared library
support.

MFC after:	1 week
2008-04-28 15:26:11 +00:00
John Baldwin
ec922be302 Initialize the head pointer in kld_current_sos() to NULL to avoid returning
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
2008-03-29 03:48:06 +00:00
John Baldwin
2369087a60 - Rework the kld support to hook into GDB's shared library support.
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.
2008-01-29 23:44:34 +00:00
John Baldwin
c989eb07bb Use target_read_memory() and extract_unsigned_integer() instead of direct
KVM access to read kernel pointers.
2008-01-29 23:36:42 +00:00
John Baldwin
a4d5f8a2b7 Don't look for "foo.ko.symbols" files. GDB is smart enough to open the
".symbols" file automatically when you tell it to load "foo.ko" because of
the debug link.
2008-01-29 23:36:10 +00:00
John Baldwin
9f24dd4d32 Use a for loop in find_kld_address() as in kgdb_auto_load_klds() and
replace the remaining goto's with continues as a result.
2008-01-28 21:45:09 +00:00
John Baldwin
5ca09def5b Add support for automatically loading symbols for kld's on startup:
- 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
2008-01-28 21:40:10 +00:00
John Baldwin
4496b3577d Move the code for working with kld's out into its own file. 2008-01-24 19:11:13 +00:00