JakeHillion/drgn
1
0
Fork 0
mirror of https://github.com/JakeHillion/drgn.git synced 2024-12-23 09:43:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
91265c37a0
drgn/libdrgn/linux_kernel.h

43 lines
1.1 KiB
C
Raw Normal View History

libdrgn: split kernel-specific stuff out of program.c Almost half of program.c is stuff specific to the Linux kernel, so let's separate that out (and combine it with the existing kernel module code).
2019-06-04 23:20:03 +01:00
// Copyright 2018-2019 - Omar Sandoval
// SPDX-License-Identifier: GPL-3.0+
#ifndef DRGN_LINUX_KERNEL_H
#define DRGN_LINUX_KERNEL_H
libdrgn: use libdwfl libdwfl is the elfutils "DWARF frontend library". It has high-level functionality for looking up symbols, walking stack traces, etc. In order to use this functionality, we need to report our debugging information through libdwfl. For userspace programs, libdwfl has a much better implementation than drgn for automatically finding debug information from a core dump or PID. However, for the kernel, libdwfl has a few issues: - It only supports finding debug information for the running kernel, not vmcores. - It determines the vmlinux address range by reading /proc/kallsyms, which is slow (~70ms on my machine). - If separate debug information isn't available for a kernel module, it finds it by walking /lib/modules/$(uname -r)/kernel; this is repeated for every module. - It doesn't find kernel modules with names containing both dashes and underscores (e.g., aes-x86_64). Luckily, drgn already solved all of these problems, and with some effort, we can keep doing it ourselves and report it to libdwfl. The conversion replaces a bunch of code for dealing with userspace core dump notes, /proc/$pid/maps, and relocations.
2019-07-15 08:51:30 +01:00
#include <elfutils/libdwfl.h>
libdrgn: split kernel-specific stuff out of program.c Almost half of program.c is stuff specific to the Linux kernel, so let's separate that out (and combine it with the existing kernel module code).
2019-06-04 23:20:03 +01:00
#include "drgn.h"
struct drgn_memory_reader;
struct vmcoreinfo;
struct drgn_error *parse_vmcoreinfo(const char *desc, size_t descsz,
struct vmcoreinfo *ret);
struct drgn_error *read_vmcoreinfo_fallback(struct drgn_memory_reader *reader,
bool have_non_zero_phys_addr,
struct vmcoreinfo *ret);
libdrgn: use libdwfl libdwfl is the elfutils "DWARF frontend library". It has high-level functionality for looking up symbols, walking stack traces, etc. In order to use this functionality, we need to report our debugging information through libdwfl. For userspace programs, libdwfl has a much better implementation than drgn for automatically finding debug information from a core dump or PID. However, for the kernel, libdwfl has a few issues: - It only supports finding debug information for the running kernel, not vmcores. - It determines the vmlinux address range by reading /proc/kallsyms, which is slow (~70ms on my machine). - If separate debug information isn't available for a kernel module, it finds it by walking /lib/modules/$(uname -r)/kernel; this is repeated for every module. - It doesn't find kernel modules with names containing both dashes and underscores (e.g., aes-x86_64). Luckily, drgn already solved all of these problems, and with some effort, we can keep doing it ourselves and report it to libdwfl. The conversion replaces a bunch of code for dealing with userspace core dump notes, /proc/$pid/maps, and relocations.
2019-07-15 08:51:30 +01:00
struct drgn_error *
linux_kernel_load_debug_info(struct drgn_program *prog, const char **paths,
size_t n);
libdrgn: split kernel-specific stuff out of program.c Almost half of program.c is stuff specific to the Linux kernel, so let's separate that out (and combine it with the existing kernel module code).
2019-06-04 23:20:03 +01:00
libdrgn: use libdwfl libdwfl is the elfutils "DWARF frontend library". It has high-level functionality for looking up symbols, walking stack traces, etc. In order to use this functionality, we need to report our debugging information through libdwfl. For userspace programs, libdwfl has a much better implementation than drgn for automatically finding debug information from a core dump or PID. However, for the kernel, libdwfl has a few issues: - It only supports finding debug information for the running kernel, not vmcores. - It determines the vmlinux address range by reading /proc/kallsyms, which is slow (~70ms on my machine). - If separate debug information isn't available for a kernel module, it finds it by walking /lib/modules/$(uname -r)/kernel; this is repeated for every module. - It doesn't find kernel modules with names containing both dashes and underscores (e.g., aes-x86_64). Luckily, drgn already solved all of these problems, and with some effort, we can keep doing it ourselves and report it to libdwfl. The conversion replaces a bunch of code for dealing with userspace core dump notes, /proc/$pid/maps, and relocations.
2019-07-15 08:51:30 +01:00
struct drgn_error *
linux_kernel_load_default_debug_info(struct drgn_program *prog);
libdrgn: split kernel-specific stuff out of program.c Almost half of program.c is stuff specific to the Linux kernel, so let's separate that out (and combine it with the existing kernel module code).
2019-06-04 23:20:03 +01:00
Add support for kdump-compressed core dumps with libkdumpfile
2019-08-02 08:00:59 +01:00
#define KDUMP_SIGNATURE "KDUMP "
#define KDUMP_SIG_LEN (sizeof(KDUMP_SIGNATURE) - 1)
#ifdef WITH_LIBKDUMPFILE
struct drgn_error *drgn_program_set_kdump(struct drgn_program *prog);
#else
static inline struct drgn_error *
drgn_program_set_kdump(struct drgn_program *prog)
{
return drgn_error_create(DRGN_ERROR_INVALID_ARGUMENT,
"drgn was built without libkdumpfile support");
}
#endif
libdrgn: split kernel-specific stuff out of program.c Almost half of program.c is stuff specific to the Linux kernel, so let's separate that out (and combine it with the existing kernel module code).
2019-06-04 23:20:03 +01:00
#endif /* DRGN_LINUX_KERNEL_H */
Reference in New Issue Copy Permalink