diff options
author | rwatson <rwatson@FreeBSD.org> | 2007-12-26 11:32:33 +0000 |
---|---|---|
committer | rwatson <rwatson@FreeBSD.org> | 2007-12-26 11:32:33 +0000 |
commit | 956e2983bab12b8a6ee25b06ca978419483ff488 (patch) | |
tree | a187b11df8e49734230bd533f4a9b7b1ba04d6ff /sys/ddb/ddb.h | |
parent | 26435e9b8db00f61f14db439ebe23a6bf26e2817 (diff) | |
download | FreeBSD-src-956e2983bab12b8a6ee25b06ca978419483ff488.zip FreeBSD-src-956e2983bab12b8a6ee25b06ca978419483ff488.tar.gz |
Add textdump(4) facility, which provides an alternative form of kernel
dump using mechanically generated/extracted debugging output rather than
a simple memory dump. Current sources of debugging output are:
- DDB output capture buffer, if there is captured output to save
- Kernel message buffer
- Kernel configuration, if included in kernel
- Kernel version string
- Panic message
Textdumps are stored in swap/dump partitions as with regular dumps, but
are laid out as ustar files in order to allow multiple parts to be stored
as a stream of sequentially written blocks. Blocks are written out in
reverse order, as the size of a textdump isn't known a priori. As with
regular dumps, they will be extracted using savecore(8).
One new DDB(4) command is added, "textdump", which accepts "set",
"unset", and "status" arguments. By default, normal kernel dumps are
generated unless "textdump set" is run in order to schedule a textdump.
It can be canceled using "textdump unset" to restore generation of a
normal kernel dump.
Several sysctls exist to configure aspects of textdumps;
debug.ddb.textdump.pending can be set to check whether a textdump is
pending, or set/unset in order to control whether the next kernel dump
will be a textdump from userspace.
While textdumps don't have to be generated as a result of a DDB script
run automatically as part of a kernel panic, this is a particular useful
way to use them, as instead of generating a complete memory dump, a
simple transcript of an automated DDB session can be captured using the
DDB output capture and textdump facilities. This can be used to
generate quite brief kernel bug reports rich in debugging information
but not dependent on kernel symbol tables or precisely synchronized
source code. Most textdumps I generate are less than 100k including
the full message buffer. Using textdumps with an interactive debugging
session is also useful, with capture being enabled/disabled in order to
record some but not all of the DDB session.
MFC after: 3 months
Diffstat (limited to 'sys/ddb/ddb.h')
-rw-r--r-- | sys/ddb/ddb.h | 23 |
1 files changed, 23 insertions, 0 deletions
diff --git a/sys/ddb/ddb.h b/sys/ddb/ddb.h index ebec60a..d559978 100644 --- a/sys/ddb/ddb.h +++ b/sys/ddb/ddb.h @@ -169,6 +169,7 @@ db_cmdfcn_t db_set_thread; db_cmdfcn_t db_show_regs; db_cmdfcn_t db_show_threads; db_cmdfcn_t db_single_step_cmd; +db_cmdfcn_t db_textdump_cmd; db_cmdfcn_t db_trace_until_call_cmd; db_cmdfcn_t db_trace_until_matching_cmd; db_cmdfcn_t db_unscript_cmd; @@ -212,4 +213,26 @@ void db_capture_writech(char ch); */ void db_script_kdbenter(const char *eventname); /* KDB enter event. */ +/* + * Interface between DDB and the textdump facility. + * + * Text dump blocks are of a fixed size; textdump_block_buffer is a + * statically allocated buffer that code interacting with textdumps can use + * to prepare and hold a pending block in when calling writenextblock(). + */ +#define TEXTDUMP_BLOCKSIZE 512 +extern char textdump_block_buffer[TEXTDUMP_BLOCKSIZE]; + +void textdump_mkustar(char *block_buffer, const char *filename, + u_int size); +void textdump_restoreoff(off_t offset); +void textdump_saveoff(off_t *offsetp); +int textdump_writenextblock(struct dumperinfo *di, char *buffer); + +/* + * Interface between the kernel and textdumps. + */ +extern int textdump_pending; /* Call textdump_dumpsys() instead. */ +void textdump_dumpsys(struct dumperinfo *di); + #endif /* !_DDB_DDB_H_ */ |