JakeHillion/drgn
1
0
Fork 0
mirror of https://github.com/JakeHillion/drgn.git synced 2024-12-23 01:33:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
32c0ce9f0d
drgn/libdrgn/linux_kernel.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1805 lines
47 KiB
C
Raw Normal View History

Update copyright headers to Meta Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-11-21 23:59:44 +00:00
// Copyright (c) Meta Platforms, Inc. and affiliates.
Relicense drgn from GPLv3+ to LGPLv2.1+ drgn is currently licensed as GPLv3+. Part of the long term vision for drgn is that other projects can use it as a library providing programmatic interfaces for debugger functionality. A more permissive license is better suited to this goal. We decided on LGPLv2.1+ as a good balance between software freedom and permissiveness. All contributors not employed by Meta were contacted via email and consented to the license change. The only exception was the author of commit c4fbf7e5896c ("libdrgn: fix for compilation error"), who did not respond. That commit reverted a single line of code to one originally written by me in commit 640b1c011df8 ("libdrgn: embed DWARF index in DWARF info cache"). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-11-02 00:05:16 +00:00
// SPDX-License-Identifier: LGPL-2.1-or-later
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: fix include-what-you-use warnings It's been awhile since I've run this. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-08-26 19:32:10 +01:00
#include <byteswap.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 <dirent.h>
Clean up #includes with include-what-you-use I recently hit a couple of CI failures caused by relying on transitive includes that weren't always present. include-what-you-use is a Clang-based tool that helps with this. It's a bit finicky and noisy, so this adds scripts/iwyu.py to make running it more convenient (but not reliable enough to automate it in Travis). This cleans up all reasonable include-what-you-use warnings and reorganizes a few header files. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-24 00:02:02 +01:00
#include <elf.h>
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
#include <elfutils/libdwelf.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 <errno.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 <fcntl.h>
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
#include <gelf.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 <inttypes.h>
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
#include <libelf.h>
#include <stdio.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 <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/stat.h>
libdrgn: fix include-what-you-use warnings It's been awhile since I've run this. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-08-26 19:32:10 +01:00
#include <unistd.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
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
#include "binary_buffer.h"
libdrgn: add _cleanup_free_ scope guard, no_cleanup_ptr(), and return_ptr() Kevin Svetlitski suggested making use of __attribute__((__cleanup__)) a long time ago, and now that the kernel is doing it, I don't have a good excuse not to. There are surprisingly only a handful of places that it was straightforward to apply it to. A lot of potential uses are thwarted by our policy that out parameters can be clobbered on failure, so that may be something to revisit. Other cleanup guards will probably be more useful, but this is just laying the groundwork for the future. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-07-20 21:58:28 +01:00
#include "cleanup.h"
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
#include "debug_info.h"
Clean up #includes with include-what-you-use I recently hit a couple of CI failures caused by relying on transitive includes that weren't always present. include-what-you-use is a Clang-based tool that helps with this. It's a bit finicky and noisy, so this adds scripts/iwyu.py to make running it more convenient (but not reliable enough to automate it in Travis). This cleans up all reasonable include-what-you-use warnings and reorganizes a few header files. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-24 00:02:02 +01:00
#include "drgn.h"
#include "error.h"
#include "hash_table.h"
libdrgn: add page table walker kernel memory reader Now that we can walk page tables, we can use it in a memory reader that reads kernel memory via the kernel page table. This means that we don't need libkdumpfile for ELF vmcores anymore (although I'll keep the functionality around until this code has been validated more).
2020-05-06 08:35:29 +01:00
#include "helpers.h"
libdrgn: add read(2) and pread(2) wrappers that don't return short reads We have a couple of loops that deal with short reads/EINTR from read(2) and pread(2), and upcoming changes would need to add more. Add some wrappers to abstract this away. drgn_read_memory_file() still needs the loop so it can fault on the exact offset that returns EIO. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-08-26 18:10:47 +01:00
#include "io.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 "linux_kernel.h"
libdrgn: use new include-what-you-use exported declarations and fix warnings include-what-you-use/include-what-you-use#1164 fixed include-what-you-use/include-what-you-use#971 so that we can export forward declarations instead of hacking around it. I can't reproduce the issue with BINARY_OP_SIGNED_2C anymore either, so we can remove that hack, too. Also fix any other warnings. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-05-23 22:45:03 +01:00
#include "platform.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 "program.h"
Clean up #includes with include-what-you-use I recently hit a couple of CI failures caused by relying on transitive includes that weren't always present. include-what-you-use is a Clang-based tool that helps with this. It's a bit finicky and noisy, so this adds scripts/iwyu.py to make running it more convenient (but not reliable enough to automate it in Travis). This cleans up all reasonable include-what-you-use warnings and reorganizes a few header files. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-24 00:02:02 +01:00
#include "type.h"
#include "util.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
libdrgn: linux_kernel: use memswitch for drgn_program_parse_vmcoreinfo() We currently have 5 names that we match against, and there are more on the way, so we might as well use a memswitch. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-20 01:21:28 +01:00
#include "drgn_program_parse_vmcoreinfo.inc"
libdrgn: add page table walker kernel memory reader Now that we can walk page tables, we can use it in a memory reader that reads kernel memory via the kernel page table. This means that we don't need libkdumpfile for ELF vmcores anymore (although I'll keep the functionality around until this code has been validated more).
2020-05-06 08:35:29 +01:00
struct drgn_error *read_memory_via_pgtable(void *buf, uint64_t address,
size_t count, uint64_t offset,
void *arg, bool physical)
{
struct drgn_program *prog = arg;
return linux_helper_read_vm(prog, prog->vmcoreinfo.swapper_pg_dir,
address, buf, count);
}
libdrgn: add /proc/kcore physical segments on old kernels Before Linux v4.11, /proc/kcore didn't have valid physical addresses, so it's currently not possible to read from physical memory on old kernels. However, if we can figure out the address of the direct mapping, then we can determine the corresponding physical addresses for the segments and add them.
2020-05-04 08:44:44 +01:00
struct drgn_error *proc_kallsyms_symbol_addr(const char *name,
unsigned long *ret)
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
{
struct drgn_error *err;
FILE *file;
char *line = NULL;
size_t n = 0;
file = fopen("/proc/kallsyms", "r");
if (!file)
libdrgn: reorder drgn_error_create_os() arguments To make it more consistent with the upcoming drgn_error_format_os().
2019-07-11 23:58:23 +01:00
return drgn_error_create_os("fopen", errno, "/proc/kallsyms");
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
for (;;) {
char *addr_str, *sym_str, *saveptr, *end;
errno = 0;
if (getline(&line, &n, file) == -1) {
if (errno) {
libdrgn: reorder drgn_error_create_os() arguments To make it more consistent with the upcoming drgn_error_format_os().
2019-07-11 23:58:23 +01:00
err = drgn_error_create_os("getline", errno,
"/proc/kallsyms");
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
} else {
libdrgn: add /proc/kcore physical segments on old kernels Before Linux v4.11, /proc/kcore didn't have valid physical addresses, so it's currently not possible to read from physical memory on old kernels. However, if we can figure out the address of the direct mapping, then we can determine the corresponding physical addresses for the segments and add them.
2020-05-04 08:44:44 +01:00
err = &drgn_not_found;
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
}
break;
}
addr_str = strtok_r(line, "\t ", &saveptr);
if (!addr_str || !*addr_str)
goto invalid;
if (!strtok_r(NULL, "\t ", &saveptr))
goto invalid;
sym_str = strtok_r(NULL, "\t\n ", &saveptr);
if (!sym_str)
goto invalid;
if (strcmp(sym_str, name) != 0)
continue;
errno = 0;
*ret = strtoul(line, &end, 16);
if (errno || *end) {
invalid:
err = drgn_error_create(DRGN_ERROR_OTHER,
"could not parse /proc/kallsyms");
break;
}
err = NULL;
break;
}
free(line);
fclose(file);
return err;
}
/*
* Before Linux kernel commit 23c85094fe18 ("proc/kcore: add vmcoreinfo note to
libdrgn: add /proc/kcore physical segments on old kernels Before Linux v4.11, /proc/kcore didn't have valid physical addresses, so it's currently not possible to read from physical memory on old kernels. However, if we can figure out the address of the direct mapping, then we can determine the corresponding physical addresses for the segments and add them.
2020-05-04 08:44:44 +01:00
* /proc/kcore") (in v4.19), /proc/kcore didn't have a VMCOREINFO note. Instead,
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
* we can read from the physical address of the vmcoreinfo note exported in
libdrgn: add /proc/kcore physical segments on old kernels Before Linux v4.11, /proc/kcore didn't have valid physical addresses, so it's currently not possible to read from physical memory on old kernels. However, if we can figure out the address of the direct mapping, then we can determine the corresponding physical addresses for the segments and add them.
2020-05-04 08:44:44 +01:00
* sysfs.
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: make addresses wrap around when reading memory Define that addresses for memory reads wrap around after the maximum address rather than the current unpredictable behavior. This is done by: 1. Reworking drgn_memory_reader to work with an inclusive address range so that a segment can contain UINT64_MAX. drgn_memory_reader remains agnostic to the maximum address and requires that address ranges do not overflow a uint64_t. 2. Adding the overflow/wrap-around logic to drgn_program_add_memory_segment() and drgn_program_read_memory(). 3. Changing direct uses of drgn_memory_reader_reader() to drgn_program_read_memory() now that they are no longer equivalent. (For some platforms, a fault might be more appropriate than wrapping around, but this is a step in the right direction.) Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-06-04 01:43:27 +01:00
struct drgn_error *read_vmcoreinfo_fallback(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
{
struct drgn_error *err;
FILE *file;
libdrgn: read vmcoreinfo physical address as uint64_t Even on 32-bit architectures, physical addresses can be 64 bits (e.g., x86 with PAE). It's unlikely that the vmcoreinfo note would be in such an address, but let's always parse it as a uint64_t just to be safe.
2020-05-04 18:23:32 +01:00
uint64_t address;
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
size_t size;
Elf64_Nhdr *nhdr;
file = fopen("/sys/kernel/vmcoreinfo", "r");
if (!file) {
libdrgn: reorder drgn_error_create_os() arguments To make it more consistent with the upcoming drgn_error_format_os().
2019-07-11 23:58:23 +01:00
return drgn_error_create_os("fopen", errno,
"/sys/kernel/vmcoreinfo");
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: read vmcoreinfo physical address as uint64_t Even on 32-bit architectures, physical addresses can be 64 bits (e.g., x86 with PAE). It's unlikely that the vmcoreinfo note would be in such an address, but let's always parse it as a uint64_t just to be safe.
2020-05-04 18:23:32 +01:00
if (fscanf(file, "%" SCNx64 "%zx", &address, &size) != 2) {
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
fclose(file);
return drgn_error_create(DRGN_ERROR_OTHER,
"could not parse /sys/kernel/vmcoreinfo");
}
fclose(file);
libdrgn: add _cleanup_free_ scope guard, no_cleanup_ptr(), and return_ptr() Kevin Svetlitski suggested making use of __attribute__((__cleanup__)) a long time ago, and now that the kernel is doing it, I don't have a good excuse not to. There are surprisingly only a handful of places that it was straightforward to apply it to. A lot of potential uses are thwarted by our policy that out parameters can be clobbered on failure, so that may be something to revisit. Other cleanup guards will probably be more useful, but this is just laying the groundwork for the future. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-07-20 21:58:28 +01:00
_cleanup_free_ char *buf = malloc(size);
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
if (!buf)
return &drgn_enomem;
libdrgn: make addresses wrap around when reading memory Define that addresses for memory reads wrap around after the maximum address rather than the current unpredictable behavior. This is done by: 1. Reworking drgn_memory_reader to work with an inclusive address range so that a segment can contain UINT64_MAX. drgn_memory_reader remains agnostic to the maximum address and requires that address ranges do not overflow a uint64_t. 2. Adding the overflow/wrap-around logic to drgn_program_add_memory_segment() and drgn_program_read_memory(). 3. Changing direct uses of drgn_memory_reader_reader() to drgn_program_read_memory() now that they are no longer equivalent. (For some platforms, a fault might be more appropriate than wrapping around, but this is a step in the right direction.) Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-06-04 01:43:27 +01:00
err = drgn_program_read_memory(prog, buf, address, size, true);
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
if (err)
libdrgn: add _cleanup_free_ scope guard, no_cleanup_ptr(), and return_ptr() Kevin Svetlitski suggested making use of __attribute__((__cleanup__)) a long time ago, and now that the kernel is doing it, I don't have a good excuse not to. There are surprisingly only a handful of places that it was straightforward to apply it to. A lot of potential uses are thwarted by our policy that out parameters can be clobbered on failure, so that may be something to revisit. Other cleanup guards will probably be more useful, but this is just laying the groundwork for the future. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-07-20 21:58:28 +01:00
return err;
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
/*
* The first 12 bytes are the Elf{32,64}_Nhdr (it's the same in both
* formats). The name is padded up to 4 bytes, so the descriptor starts
* at byte 24.
*/
nhdr = (Elf64_Nhdr *)buf;
if (size < 24 || nhdr->n_namesz != 11 ||
memcmp(buf + sizeof(*nhdr), "VMCOREINFO", 10) != 0 ||
nhdr->n_descsz > size - 24) {
err = drgn_error_create(DRGN_ERROR_OTHER,
"VMCOREINFO is invalid");
libdrgn: add _cleanup_free_ scope guard, no_cleanup_ptr(), and return_ptr() Kevin Svetlitski suggested making use of __attribute__((__cleanup__)) a long time ago, and now that the kernel is doing it, I don't have a good excuse not to. There are surprisingly only a handful of places that it was straightforward to apply it to. A lot of potential uses are thwarted by our policy that out parameters can be clobbered on failure, so that may be something to revisit. Other cleanup guards will probably be more useful, but this is just laying the groundwork for the future. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-07-20 21:58:28 +01:00
return err;
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: add _cleanup_free_ scope guard, no_cleanup_ptr(), and return_ptr() Kevin Svetlitski suggested making use of __attribute__((__cleanup__)) a long time ago, and now that the kernel is doing it, I don't have a good excuse not to. There are surprisingly only a handful of places that it was straightforward to apply it to. A lot of potential uses are thwarted by our policy that out parameters can be clobbered on failure, so that may be something to revisit. Other cleanup guards will probably be more useful, but this is just laying the groundwork for the future. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-07-20 21:58:28 +01:00
return drgn_program_parse_vmcoreinfo(prog, buf + 24, nhdr->n_descsz);
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 memswitch for linux_kernel_object_find Replace the hand-written if-else ladder of memcmp() calls with a memswitch. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-02-08 09:32:28 +00:00
static struct drgn_error *linux_kernel_get_page_shift(struct drgn_program *prog,
struct drgn_object *ret)
{
struct drgn_error *err;
struct drgn_qualified_type qualified_type;
err = drgn_program_find_primitive_type(prog, DRGN_C_TYPE_INT,
&qualified_type.type);
if (err)
return err;
qualified_type.qualifiers = 0;
return drgn_object_set_signed(ret, qualified_type,
libdrgn: linux_kernel: cache PAGE_SHIFT derived from PAGE_SIZE Rather than computing it every time we need it, compute it once when we parse PAGE_SIZE from VMCOREINFO (and validate that PAGE_SIZE is a power of two). This will be more important for AArch64 page table walking. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-07-08 22:23:09 +01:00
prog->vmcoreinfo.page_shift, 0);
libdrgn: use memswitch for linux_kernel_object_find Replace the hand-written if-else ladder of memcmp() calls with a memswitch. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-02-08 09:32:28 +00:00
}
static struct drgn_error *linux_kernel_get_page_size(struct drgn_program *prog,
struct drgn_object *ret)
{
struct drgn_error *err;
struct drgn_qualified_type qualified_type;
err = drgn_program_find_primitive_type(prog, DRGN_C_TYPE_UNSIGNED_LONG,
&qualified_type.type);
if (err)
return err;
qualified_type.qualifiers = 0;
return drgn_object_set_unsigned(ret, qualified_type,
prog->vmcoreinfo.page_size, 0);
}
static struct drgn_error *linux_kernel_get_page_mask(struct drgn_program *prog,
struct drgn_object *ret)
{
struct drgn_error *err;
struct drgn_qualified_type qualified_type;
err = drgn_program_find_primitive_type(prog, DRGN_C_TYPE_UNSIGNED_LONG,
&qualified_type.type);
if (err)
return err;
qualified_type.qualifiers = 0;
return drgn_object_set_unsigned(ret, qualified_type,
~(prog->vmcoreinfo.page_size - 1), 0);
}
static struct drgn_error *
linux_kernel_get_uts_release(struct drgn_program *prog, struct drgn_object *ret)
{
struct drgn_error *err;
struct drgn_qualified_type qualified_type;
err = drgn_program_find_primitive_type(prog,
DRGN_C_TYPE_CHAR,
&qualified_type.type);
if (err)
return err;
qualified_type.qualifiers = DRGN_QUALIFIER_CONST;
size_t len = strlen(prog->vmcoreinfo.osrelease);
err = drgn_array_type_create(prog, qualified_type, len + 1,
&drgn_language_c, &qualified_type.type);
if (err)
return err;
qualified_type.qualifiers = 0;
return drgn_object_set_from_buffer(ret, qualified_type,
prog->vmcoreinfo.osrelease, len + 1,
0, 0);
}
libdrgn: linux_kernel: add object finder for jiffies We have a lot of examples that use jiffies, but they stopped working long ago on x86-64 (since Linux kernel commit d8ad6d39c35d ("x86_64: Fix jiffies ODR violation") (in v5.8 and backported to stable releases)) and never worked on other architectures. This is because jiffies is defined in the Linux kernel's linker script. #277 proposed updating the examples to use jiffies_64, but I would guess that most kernel developers are familiar with jiffies and many have never seen jiffies_64. jiffies is also a nicer name to type in live demos. Let's add a case to the Linux kernel object finder to get the jiffies variable. Reported-by: Martin Liska <mliska@suse.cz> Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-02-22 18:30:58 +00:00
// jiffies is defined as an alias of jiffies_64 via the Linux kernel linker
// script, so it is not included in debug info.
static struct drgn_error *linux_kernel_get_jiffies(struct drgn_program *prog,
struct drgn_object *ret)
{
struct drgn_error *err;
struct drgn_object jiffies_64;
drgn_object_init(&jiffies_64, prog);
err = drgn_program_find_object(prog, "jiffies_64", NULL,
DRGN_FIND_OBJECT_VARIABLE, &jiffies_64);
if (err) {
if (err->code == DRGN_ERROR_LOOKUP) {
drgn_error_destroy(err);
err = &drgn_not_found;
}
goto out;
}
if (jiffies_64.kind != DRGN_OBJECT_REFERENCE) {
err = &drgn_not_found;
goto out;
}
uint64_t address = jiffies_64.address;
struct drgn_qualified_type qualified_type;
err = drgn_program_find_primitive_type(prog, DRGN_C_TYPE_UNSIGNED_LONG,
&qualified_type.type);
if (err)
return err;
qualified_type.qualifiers = DRGN_QUALIFIER_VOLATILE;
if (drgn_type_size(qualified_type.type) == 4 &&
!drgn_type_little_endian(qualified_type.type))
address += 4;
err = drgn_object_set_reference(ret, qualified_type, address, 0, 0);
out:
drgn_object_deinit(&jiffies_64);
return err;
}
Add VMCOREINFO to special Linux Kernel objects For Python-based object, type, and symbol finders, the vmcoreinfo is a critical source of information. It can contain addresses necessary for loading certain information (such as kallsyms). Expose this information as a special object. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
2023-06-30 00:28:12 +01:00
static struct drgn_error *
linux_kernel_get_vmcoreinfo(struct drgn_program *prog, struct drgn_object *ret)
{
struct drgn_error *err;
struct drgn_qualified_type qualified_type;
err = drgn_program_find_primitive_type(prog,
DRGN_C_TYPE_CHAR,
&qualified_type.type);
if (err)
return err;
qualified_type.qualifiers = DRGN_QUALIFIER_CONST;
err = drgn_array_type_create(prog, qualified_type, prog->vmcoreinfo.raw_size,
&drgn_language_c, &qualified_type.type);
if (err)
return err;
qualified_type.qualifiers = 0;
return drgn_object_set_from_buffer(ret, qualified_type, prog->vmcoreinfo.raw,
prog->vmcoreinfo.raw_size, 0, 0);
}
libdrgn: linux_kernel: get vmemmap generically AArch64 has changed the location of vmemmap multiple times, and not all of these can be easily distinguished. Rather than restorting to kernel version checks, this replaces the vmemmap architecture callback with a generic approach that gets the vmemmap address directly from the mem_section table. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-07-12 21:37:12 +01:00
// The vmemmap address can vary depending on architecture, kernel version,
// configuration options, and KASLR. However, we can get it generically from the
// section_mem_map of any valid mem_section.
static struct drgn_error *
linux_kernel_get_vmemmap_address(struct drgn_program *prog, uint64_t *ret)
{
static const uint64_t SECTION_HAS_MEM_MAP = 0x2;
static const uint64_t SECTION_MAP_MASK = ~((UINT64_C(1) << 6) - 1);
struct drgn_error *err;
struct drgn_object mem_section, root, section;
drgn_object_init(&mem_section, prog);
drgn_object_init(&root, prog);
drgn_object_init(&section, prog);
err = drgn_program_find_object(prog, "vmemmap_populate", NULL,
DRGN_FIND_OBJECT_FUNCTION, &mem_section);
if (err) {
if (err->code == DRGN_ERROR_LOOKUP) {
// !CONFIG_SPARSEMEM_VMEMMAP
drgn_error_destroy(err);
err = &drgn_not_found;
}
goto out;
}
err = drgn_program_find_object(prog, "mem_section", NULL,
DRGN_FIND_OBJECT_VARIABLE, &mem_section);
if (err)
goto out;
const uint64_t nr_section_roots = prog->vmcoreinfo.mem_section_length;
uint64_t sections_per_root;
if (drgn_type_kind(mem_section.type) == DRGN_TYPE_ARRAY) {
// If !CONFIG_SPARSEMEM_EXTREME, mem_section is
// struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT],
// and SECTIONS_PER_ROOT is 1.
sections_per_root = 1;
} else {
// If CONFIG_SPARSEMEM_EXTREME, mem_section is
// struct mem_section **mem_section, and SECTIONS_PER_ROOT is
// PAGE_SIZE / sizeof(struct mem_section).
struct drgn_type *mem_section_type = mem_section.type;
for (int i = 0; i < 2; i++) {
if (drgn_type_kind(mem_section_type) != DRGN_TYPE_POINTER) {
unrecognized_mem_section_type:
err = drgn_type_error("mem_section has unrecognized type '%s'",
mem_section.type);
goto out;
}
mem_section_type = drgn_type_type(mem_section_type).type;
}
if (drgn_type_kind(mem_section_type) != DRGN_TYPE_STRUCT)
goto unrecognized_mem_section_type;
uint64_t sizeof_mem_section = drgn_type_size(mem_section_type);
if (sizeof_mem_section == 0)
goto unrecognized_mem_section_type;
sections_per_root =
prog->vmcoreinfo.page_size / sizeof_mem_section;
}
// Find a valid section.
for (uint64_t i = 0; i < nr_section_roots; i++) {
err = drgn_object_subscript(&root, &mem_section, i);
if (err)
goto out;
bool truthy;
err = drgn_object_bool(&root, &truthy);
if (err)
goto out;
if (!truthy)
continue;
for (uint64_t j = 0; j < sections_per_root; j++) {
err = drgn_object_subscript(&section, &root, j);
if (err)
goto out;
err = drgn_object_member(&section, &section,
"section_mem_map");
if (err)
goto out;
uint64_t section_mem_map;
err = drgn_object_read_unsigned(&section,
&section_mem_map);
if (err)
goto out;
if (section_mem_map & SECTION_HAS_MEM_MAP) {
*ret = section_mem_map & SECTION_MAP_MASK;
err = NULL;
goto out;
}
}
}
err = &drgn_not_found;
out:
drgn_object_deinit(&section);
drgn_object_deinit(&root);
drgn_object_deinit(&mem_section);
return err;
}
libdrgn: use memswitch for linux_kernel_object_find Replace the hand-written if-else ladder of memcmp() calls with a memswitch. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-02-08 09:32:28 +00:00
static struct drgn_error *linux_kernel_get_vmemmap(struct drgn_program *prog,
struct drgn_object *ret)
{
struct drgn_error *err;
if (prog->vmemmap.kind == DRGN_OBJECT_ABSENT) {
libdrgn: linux_kernel: Fix compiler warning With GCC 13.1.1 and the recommended build setup (CONFIGURE_FLAGS="--enable-compiler-warnings=error"), I get the following failure: In function 'linux_kernel_get_vmemmap', inlined from 'linux_kernel_object_find' at ../../libdrgn/linux_kernel_object_find.inc.strswitch:34:12: ../../libdrgn/linux_kernel.c:370:23: error: 'address' may be used uninitialized [-Werror=maybe-uninitialized] 370 | err = drgn_object_set_unsigned(&prog->vmemmap, qualified_type, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 371 | address, 0); | ~~~~~~~~~~~ ../../libdrgn/linux_kernel.c: In function 'linux_kernel_object_find': ../../libdrgn/linux_kernel.c:361:26: note: 'address' was declared here 361 | uint64_t address; | ^~~~~~~ cc1: all warnings being treated as errors While linux_kernel_get_vmemmap_address should always update address in a non-error case, the compiler seems to disagree. It's easy enough to shut up the compiler by initializing address to 0. What's more, if there is an actual issue where the linux_kernel_get_vmemmap_address does NOT update the address variable, a 0 value will be easier to debug than garbage from an uninitialized variable. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
2023-06-01 21:58:23 +01:00
// Silence -Wmaybe-uninitialized false positive last seen with
// GCC 13 by initializing to zero.
uint64_t address = 0;
libdrgn: linux_kernel: get vmemmap generically AArch64 has changed the location of vmemmap multiple times, and not all of these can be easily distinguished. Rather than restorting to kernel version checks, this replaces the vmemmap architecture callback with a generic approach that gets the vmemmap address directly from the mem_section table. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-07-12 21:37:12 +01:00
err = linux_kernel_get_vmemmap_address(prog, &address);
if (err)
return err;
struct drgn_qualified_type qualified_type;
err = drgn_program_find_type(prog, "struct page *", NULL,
&qualified_type);
if (err)
return err;
err = drgn_object_set_unsigned(&prog->vmemmap, qualified_type,
address, 0);
libdrgn: use memswitch for linux_kernel_object_find Replace the hand-written if-else ladder of memcmp() calls with a memswitch. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-02-08 09:32:28 +00:00
if (err)
return err;
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
}
libdrgn: use memswitch for linux_kernel_object_find Replace the hand-written if-else ladder of memcmp() calls with a memswitch. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-02-08 09:32:28 +00:00
return drgn_object_copy(ret, &prog->vmemmap);
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
}
libdrgn: fix include-what-you-use warnings It's been awhile since I've run this. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-08-26 19:32:10 +01:00
#include "linux_kernel_object_find.inc" // IWYU pragma: keep
libdrgn: use memswitch for linux_kernel_object_find Replace the hand-written if-else ladder of memcmp() calls with a memswitch. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-02-08 09:32:28 +00:00
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
struct kernel_module_iterator {
char *name;
libdrgn: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
uint64_t start, end;
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
void *build_id_buf;
size_t build_id_buf_capacity;
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
/* `struct module` type. */
struct drgn_qualified_type module_type;
/* Current `struct module` (not a pointer). */
struct drgn_object mod;
/* `struct list_head *` in next module to return. */
struct drgn_object node;
/* Temporary objects reused for various purposes. */
struct drgn_object tmp1, tmp2, tmp3;
/* Address of `struct list_head modules`. */
uint64_t head;
bool use_sys_module;
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
};
static void kernel_module_iterator_deinit(struct kernel_module_iterator *it)
{
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
drgn_object_deinit(&it->tmp3);
drgn_object_deinit(&it->tmp2);
drgn_object_deinit(&it->tmp1);
drgn_object_deinit(&it->node);
drgn_object_deinit(&it->mod);
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
free(it->build_id_buf);
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
free(it->name);
}
static struct drgn_error *
kernel_module_iterator_init(struct kernel_module_iterator *it,
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
struct drgn_program *prog, bool use_sys_module)
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
{
struct drgn_error *err;
it->name = NULL;
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
it->build_id_buf = NULL;
it->build_id_buf_capacity = 0;
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
it->use_sys_module = use_sys_module;
err = drgn_program_find_type(prog, "struct module", NULL,
&it->module_type);
if (err)
return err;
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: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
drgn_object_init(&it->mod, prog);
drgn_object_init(&it->node, prog);
drgn_object_init(&it->tmp1, prog);
drgn_object_init(&it->tmp2, prog);
drgn_object_init(&it->tmp3, 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
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
err = drgn_program_find_object(prog, "modules", NULL,
DRGN_FIND_OBJECT_VARIABLE, &it->node);
if (err)
goto err;
if (it->node.kind != DRGN_OBJECT_REFERENCE) {
err = drgn_error_create(DRGN_ERROR_OTHER,
"can't get address of modules list");
goto err;
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: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
it->head = it->node.address;
err = drgn_object_member(&it->node, &it->node, "next");
if (err)
goto err;
err = drgn_object_read(&it->node, &it->node);
if (err)
goto err;
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
return NULL;
err:
kernel_module_iterator_deinit(it);
return err;
}
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
/**
* Get the the next loaded kernel module.
*
* After this is called, @c it->name is set to the name of the kernel module,
* and @c it->start and @c it->end are set to the address range of the kernel
* module. These are valid until the next time this is called or the iterator is
* destroyed.
*
* @return @c NULL on success, non-@c NULL on error. In particular, when there
libdrgn: clean up usage of drgn_stop Use drgn_not_found where it's more appropriate, and check explicitly against drgn_stop instead of err->code == DRGN_ERROR_STOP. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-03-05 20:46:06 +00:00
* are no more modules, returns &@ref drgn_stop.
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
*/
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
static struct drgn_error *
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
kernel_module_iterator_next(struct kernel_module_iterator *it)
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
{
struct drgn_error *err;
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
uint64_t addr;
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
err = drgn_object_read_unsigned(&it->node, &addr);
if (err)
return err;
if (addr == it->head)
return &drgn_stop;
err = drgn_object_container_of(&it->mod, &it->node, it->module_type,
"list");
if (err)
return err;
libdrgn: linux_kernel: optimize reading module list An upcoming fix requires us to always use the module list from the core dump rather than /proc/modules. However, with the existing code, this would cause a major startup time regression for the live kernel, mainly because reading from /proc/kcore is stupidly slow. We currently do 3 + strlen(module->name) reads for every module. We can reduce this to 1 read per module by reading the entire struct module at once. The size of struct module is ~700-900 bytes depending on the kernel configuration, which is still much faster to read than only reading what we need. In some benchmarks that I did with DRGN_USE_PROC_AND_SYS_MODULES=0, this reduced the time spent in the kernel module iterator from ~2.5ms per module to ~0.4ms per module. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:07:20 +01:00
err = drgn_object_dereference(&it->mod, &it->mod);
if (err)
return err;
// We need several fields from the `struct module`. Especially for
// /proc/kcore, it is faster to read the entire structure (which is <1kB
// as of Linux 6.0) from the core dump all at once than it is to read
// each field individually.
err = drgn_object_read(&it->mod, &it->mod);
if (err)
return err;
err = drgn_object_member(&it->node, &it->mod, "list");
if (err)
return err;
err = drgn_object_member(&it->node, &it->node, "next");
if (err)
return err;
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: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
// Set tmp1 to the module base address and tmp2 to the size.
libdrgn: linux_kernel: Fix module detection on kernel v6.4 Kernel commit ac3b43283923 ("module: replace module_layout with module_memory") in v6.4 changed the layout of `struct module`, resulting in the following drgn error [1]. Fix this by first trying to determine the base address and size of each kernel module via the `struct module_memory mem[MOD_TEXT]` member, before falling back to previous methods that work on older kernels. Tested on v6.4-rc2 and v6.3 which does not include the above mentioned commit. Note that kernel commit b4aff7513df3 ("scripts/gdb: use mem instead of core_layout to get the module address") performs a similar fix in Python GDB scripts. Closes #296. [1] ``` # drgn drgn 0.0.22 (using Python 3.11.3, elfutils 0.189, with libkdumpfile) For help, type help(drgn). >>> import drgn >>> from drgn import NULL, Object, cast, container_of, execscript, offsetof, reinterpret, sizeof >>> from drgn.helpers.common import * >>> from drgn.helpers.linux import * warning: could not get debugging information for: kernel modules (could not find loaded kernel modules: 'struct module' has no member 'core_size') ``` Signed-off-by: Ido Schimmel <idosch@nvidia.com>
2023-05-26 16:22:07 +01:00
err = drgn_object_member(&it->tmp1, &it->mod, "mem");
libdrgn: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
if (!err) {
libdrgn: linux_kernel: Fix module detection on kernel v6.4 Kernel commit ac3b43283923 ("module: replace module_layout with module_memory") in v6.4 changed the layout of `struct module`, resulting in the following drgn error [1]. Fix this by first trying to determine the base address and size of each kernel module via the `struct module_memory mem[MOD_TEXT]` member, before falling back to previous methods that work on older kernels. Tested on v6.4-rc2 and v6.3 which does not include the above mentioned commit. Note that kernel commit b4aff7513df3 ("scripts/gdb: use mem instead of core_layout to get the module address") performs a similar fix in Python GDB scripts. Closes #296. [1] ``` # drgn drgn 0.0.22 (using Python 3.11.3, elfutils 0.189, with libkdumpfile) For help, type help(drgn). >>> import drgn >>> from drgn import NULL, Object, cast, container_of, execscript, offsetof, reinterpret, sizeof >>> from drgn.helpers.common import * >>> from drgn.helpers.linux import * warning: could not get debugging information for: kernel modules (could not find loaded kernel modules: 'struct module' has no member 'core_size') ``` Signed-off-by: Ido Schimmel <idosch@nvidia.com>
2023-05-26 16:22:07 +01:00
union drgn_value mod_mem_type;
// Since Linux kernel commit ac3b43283923 ("module: replace
// module_layout with module_memory") (in v6.4), the base and
// size are in the `struct module_memory mem[MOD_TEXT]` member
// of `struct module`.
err = drgn_program_find_object(drgn_object_program(&it->mod),
"MOD_TEXT", NULL,
DRGN_FIND_OBJECT_CONSTANT,
libdrgn: linux_kernel: get slightly smaller code for kernel_module_iterator_next() By using the same temporary objects in the Linux 6.4 branch as the pre-6.4 branch, we get slightly better code generation. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-06-22 23:25:18 +01:00
&it->tmp2);
libdrgn: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
if (err)
return err;
libdrgn: linux_kernel: get slightly smaller code for kernel_module_iterator_next() By using the same temporary objects in the Linux 6.4 branch as the pre-6.4 branch, we get slightly better code generation. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-06-22 23:25:18 +01:00
err = drgn_object_read_integer(&it->tmp2, &mod_mem_type);
libdrgn: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
if (err)
return err;
libdrgn: linux_kernel: get slightly smaller code for kernel_module_iterator_next() By using the same temporary objects in the Linux 6.4 branch as the pre-6.4 branch, we get slightly better code generation. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-06-22 23:25:18 +01:00
err = drgn_object_subscript(&it->tmp1, &it->tmp1,
libdrgn: linux_kernel: Fix module detection on kernel v6.4 Kernel commit ac3b43283923 ("module: replace module_layout with module_memory") in v6.4 changed the layout of `struct module`, resulting in the following drgn error [1]. Fix this by first trying to determine the base address and size of each kernel module via the `struct module_memory mem[MOD_TEXT]` member, before falling back to previous methods that work on older kernels. Tested on v6.4-rc2 and v6.3 which does not include the above mentioned commit. Note that kernel commit b4aff7513df3 ("scripts/gdb: use mem instead of core_layout to get the module address") performs a similar fix in Python GDB scripts. Closes #296. [1] ``` # drgn drgn 0.0.22 (using Python 3.11.3, elfutils 0.189, with libkdumpfile) For help, type help(drgn). >>> import drgn >>> from drgn import NULL, Object, cast, container_of, execscript, offsetof, reinterpret, sizeof >>> from drgn.helpers.common import * >>> from drgn.helpers.linux import * warning: could not get debugging information for: kernel modules (could not find loaded kernel modules: 'struct module' has no member 'core_size') ``` Signed-off-by: Ido Schimmel <idosch@nvidia.com>
2023-05-26 16:22:07 +01:00
mod_mem_type.uvalue);
libdrgn: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
if (err)
return err;
libdrgn: linux_kernel: get slightly smaller code for kernel_module_iterator_next() By using the same temporary objects in the Linux 6.4 branch as the pre-6.4 branch, we get slightly better code generation. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-06-22 23:25:18 +01:00
err = drgn_object_member(&it->tmp2, &it->tmp1, "size");
libdrgn: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
if (err)
return err;
libdrgn: linux_kernel: get slightly smaller code for kernel_module_iterator_next() By using the same temporary objects in the Linux 6.4 branch as the pre-6.4 branch, we get slightly better code generation. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-06-22 23:25:18 +01:00
err = drgn_object_member(&it->tmp1, &it->tmp1, "base");
libdrgn: linux_kernel: Fix module detection on kernel v6.4 Kernel commit ac3b43283923 ("module: replace module_layout with module_memory") in v6.4 changed the layout of `struct module`, resulting in the following drgn error [1]. Fix this by first trying to determine the base address and size of each kernel module via the `struct module_memory mem[MOD_TEXT]` member, before falling back to previous methods that work on older kernels. Tested on v6.4-rc2 and v6.3 which does not include the above mentioned commit. Note that kernel commit b4aff7513df3 ("scripts/gdb: use mem instead of core_layout to get the module address") performs a similar fix in Python GDB scripts. Closes #296. [1] ``` # drgn drgn 0.0.22 (using Python 3.11.3, elfutils 0.189, with libkdumpfile) For help, type help(drgn). >>> import drgn >>> from drgn import NULL, Object, cast, container_of, execscript, offsetof, reinterpret, sizeof >>> from drgn.helpers.common import * >>> from drgn.helpers.linux import * warning: could not get debugging information for: kernel modules (could not find loaded kernel modules: 'struct module' has no member 'core_size') ``` Signed-off-by: Ido Schimmel <idosch@nvidia.com>
2023-05-26 16:22:07 +01:00
if (err)
return err;
} else if (err->code == DRGN_ERROR_LOOKUP) {
// Since Linux kernel commit 7523e4dc5057 ("module: use a
// structure to encapsulate layout.") (in v4.5), the base and
// size are in the `struct module_layout core_layout` member of
// `struct module`.
drgn_error_destroy(err);
err = drgn_object_member(&it->tmp1, &it->mod, "core_layout");
if (!err) {
err = drgn_object_member(&it->tmp2, &it->tmp1, "size");
if (err)
return err;
err = drgn_object_member(&it->tmp1, &it->tmp1, "base");
if (err)
return err;
} else if (err->code == DRGN_ERROR_LOOKUP) {
// Before that, they are directly in the `struct
// module`.
drgn_error_destroy(err);
err = drgn_object_member(&it->tmp2, &it->mod,
"core_size");
if (err)
return err;
err = drgn_object_member(&it->tmp1, &it->mod,
"module_core");
if (err)
return err;
} else {
return err;
}
libdrgn: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
} else {
return err;
}
err = drgn_object_read_unsigned(&it->tmp1, &it->start);
if (err)
return err;
err = drgn_object_read_unsigned(&it->tmp2, &it->end);
if (err)
return err;
it->end += it->start;
libdrgn: linux_kernel: optimize reading module list An upcoming fix requires us to always use the module list from the core dump rather than /proc/modules. However, with the existing code, this would cause a major startup time regression for the live kernel, mainly because reading from /proc/kcore is stupidly slow. We currently do 3 + strlen(module->name) reads for every module. We can reduce this to 1 read per module by reading the entire struct module at once. The size of struct module is ~700-900 bytes depending on the kernel configuration, which is still much faster to read than only reading what we need. In some benchmarks that I did with DRGN_USE_PROC_AND_SYS_MODULES=0, this reduced the time spent in the kernel module iterator from ~2.5ms per module to ~0.4ms per module. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:07:20 +01:00
err = drgn_object_member(&it->tmp2, &it->mod, "name");
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
if (err)
return err;
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
char *name;
libdrgn: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
err = drgn_object_read_c_string(&it->tmp2, &name);
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
if (err)
return err;
free(it->name);
it->name = name;
return NULL;
}
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
static size_t parse_gnu_build_id_from_note(const void *note, size_t note_size,
bool bswap, const void **ret)
{
const char *p = note;
const char *end = p + note_size;
// Elf64_Nhdr is the same as Elf32_Nhdr.
Elf32_Nhdr nhdr;
while (end - p >= sizeof(nhdr)) {
#define ALIGN_NOTE() do { \
size_t to_align = (size_t)-(p - (char *)note) % 4; \
if (to_align > end - p) \
break; \
p += to_align; \
} while (0)
memcpy(&nhdr, p, sizeof(nhdr));
if (bswap) {
nhdr.n_namesz = bswap_32(nhdr.n_namesz);
nhdr.n_descsz = bswap_32(nhdr.n_descsz);
nhdr.n_type = bswap_32(nhdr.n_type);
}
p += sizeof(nhdr);
if (nhdr.n_namesz > end - p)
break;
const char *name = p;
p += nhdr.n_namesz;
ALIGN_NOTE();
if (nhdr.n_namesz == sizeof("GNU") &&
memcmp(name, "GNU", sizeof("GNU")) == 0 &&
nhdr.n_type == NT_GNU_BUILD_ID &&
nhdr.n_descsz > 0) {
if (nhdr.n_descsz > end - p)
break;
*ret = p;
return nhdr.n_descsz;
}
p += nhdr.n_descsz;
ALIGN_NOTE();
#undef ALIGN_NOTE
}
*ret = NULL;
return 0;
}
static struct drgn_error *
kernel_module_iterator_gnu_build_id_live(struct kernel_module_iterator *it,
const void **build_id_ret,
size_t *build_id_len_ret)
{
struct drgn_error *err;
char *path;
if (asprintf(&path, "/sys/module/%s/notes", it->name) == -1)
return &drgn_enomem;
DIR *dir = opendir(path);
if (!dir) {
err = drgn_error_create_os("opendir", errno, path);
goto out_path;
}
struct dirent *ent;
while ((errno = 0, ent = readdir(dir))) {
if (ent->d_type == DT_DIR)
continue;
int fd = openat(dirfd(dir), ent->d_name, O_RDONLY);
if (fd == -1) {
err = drgn_error_format_os("openat", errno, "%s/%s",
path, ent->d_name);
goto out;
}
struct stat st;
if (fstat(fd, &st) < 0) {
err = drgn_error_format_os("fstat", errno, "%s/%s",
path, ent->d_name);
close(fd);
goto out;
}
if (st.st_size > SIZE_MAX ||
!alloc_or_reuse(&it->build_id_buf,
&it->build_id_buf_capacity, st.st_size)) {
err = &drgn_enomem;
close(fd);
goto out;
}
libdrgn: add read(2) and pread(2) wrappers that don't return short reads We have a couple of loops that deal with short reads/EINTR from read(2) and pread(2), and upcoming changes would need to add more. Add some wrappers to abstract this away. drgn_read_memory_file() still needs the loop so it can fault on the exact offset that returns EIO. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-08-26 18:10:47 +01:00
ssize_t r = read_all(fd, it->build_id_buf, st.st_size);
if (r < 0) {
err = drgn_error_format_os("read", errno, "%s/%s", path,
ent->d_name);
close(fd);
goto out;
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
}
close(fd);
libdrgn: add read(2) and pread(2) wrappers that don't return short reads We have a couple of loops that deal with short reads/EINTR from read(2) and pread(2), and upcoming changes would need to add more. Add some wrappers to abstract this away. drgn_read_memory_file() still needs the loop so it can fault on the exact offset that returns EIO. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-08-26 18:10:47 +01:00
*build_id_len_ret =
parse_gnu_build_id_from_note(it->build_id_buf, r, false,
build_id_ret);
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
if (*build_id_len_ret) {
err = NULL;
goto out;
}
}
if (errno) {
err = drgn_error_create_os("readdir", errno, path);
} else {
*build_id_ret = NULL;
*build_id_len_ret = 0;
err = NULL;
}
out:
closedir(dir);
out_path:
free(path);
return err;
}
static struct drgn_error *
kernel_module_iterator_gnu_build_id(struct kernel_module_iterator *it,
const void **build_id_ret,
size_t *build_id_len_ret)
{
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
if (it->use_sys_module) {
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
return kernel_module_iterator_gnu_build_id_live(it,
build_id_ret,
build_id_len_ret);
}
struct drgn_error *err;
struct drgn_program *prog = drgn_object_program(&it->mod);
libdrgn: linux_kernel: optimize reading module list An upcoming fix requires us to always use the module list from the core dump rather than /proc/modules. However, with the existing code, this would cause a major startup time regression for the live kernel, mainly because reading from /proc/kcore is stupidly slow. We currently do 3 + strlen(module->name) reads for every module. We can reduce this to 1 read per module by reading the entire struct module at once. The size of struct module is ~700-900 bytes depending on the kernel configuration, which is still much faster to read than only reading what we need. In some benchmarks that I did with DRGN_USE_PROC_AND_SYS_MODULES=0, this reduced the time spent in the kernel module iterator from ~2.5ms per module to ~0.4ms per module. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:07:20 +01:00
const bool bswap = drgn_platform_bswap(&prog->platform);
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
struct drgn_object attrs, attr, tmp;
drgn_object_init(&attrs, prog);
drgn_object_init(&attr, prog);
drgn_object_init(&tmp, prog);
// n = mod->notes_attrs->notes
uint64_t n;
libdrgn: linux_kernel: optimize reading module list An upcoming fix requires us to always use the module list from the core dump rather than /proc/modules. However, with the existing code, this would cause a major startup time regression for the live kernel, mainly because reading from /proc/kcore is stupidly slow. We currently do 3 + strlen(module->name) reads for every module. We can reduce this to 1 read per module by reading the entire struct module at once. The size of struct module is ~700-900 bytes depending on the kernel configuration, which is still much faster to read than only reading what we need. In some benchmarks that I did with DRGN_USE_PROC_AND_SYS_MODULES=0, this reduced the time spent in the kernel module iterator from ~2.5ms per module to ~0.4ms per module. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:07:20 +01:00
err = drgn_object_member(&attrs, &it->mod, "notes_attrs");
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
if (err)
goto out;
err = drgn_object_member_dereference(&tmp, &attrs, "notes");
if (err)
goto out;
err = drgn_object_read_unsigned(&tmp, &n);
if (err)
goto out;
// attrs = mod->notes_attrs->attrs
err = drgn_object_member_dereference(&attrs, &attrs, "attrs");
if (err)
goto out;
for (uint64_t i = 0; i < n; i++) {
// attr = attrs[i]
err = drgn_object_subscript(&attr, &attrs, i);
if (err)
goto out;
// address = attr.private
err = drgn_object_member(&tmp, &attr, "private");
if (err)
goto out;
uint64_t address;
err = drgn_object_read_unsigned(&tmp, &address);
if (err)
goto out;
// size = attr.size
err = drgn_object_member(&tmp, &attr, "size");
if (err)
goto out;
uint64_t size;
err = drgn_object_read_unsigned(&tmp, &size);
if (err)
goto out;
if (size > SIZE_MAX ||
!alloc_or_reuse(&it->build_id_buf,
&it->build_id_buf_capacity, size)) {
err = &drgn_enomem;
goto out;
}
err = drgn_program_read_memory(prog, it->build_id_buf, address,
size, false);
if (err)
goto out;
*build_id_len_ret =
parse_gnu_build_id_from_note(it->build_id_buf, size,
bswap, build_id_ret);
if (*build_id_len_ret) {
err = NULL;
goto out;
}
}
*build_id_ret = NULL;
*build_id_len_ret = 0;
err = NULL;
out:
drgn_object_deinit(&tmp);
drgn_object_deinit(&attr);
drgn_object_deinit(&attrs);
return err;
}
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 kernel_module_section_iterator {
struct kernel_module_iterator *kmod_it;
libdrgn: linux_kernel: fix global per-CPU variables in kernel modules The .data..percpu section is excluded from /sys/module and struct module::sect_attrs, which means that we default its address to 0. This results in global per-CPU variables in kernel modules being relocated starting from 0 rather than the offset of the per-CPU allocation made for the module, which in turn causes those variables to appear to contain the wrong data. Fix it by manually getting the per-CPU address from struct module. Closes #185. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 23:19:16 +01:00
bool yielded_percpu;
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
/* /sys/module/$module/sections directory or NULL. */
DIR *sections_dir;
/* If not using /sys/module/$module/sections. */
uint64_t i;
uint64_t nsections;
char *name;
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
};
static struct drgn_error *
kernel_module_section_iterator_init(struct kernel_module_section_iterator *it,
struct kernel_module_iterator *kmod_it)
{
struct drgn_error *err;
it->kmod_it = kmod_it;
libdrgn: linux_kernel: fix global per-CPU variables in kernel modules The .data..percpu section is excluded from /sys/module and struct module::sect_attrs, which means that we default its address to 0. This results in global per-CPU variables in kernel modules being relocated starting from 0 rather than the offset of the per-CPU allocation made for the module, which in turn causes those variables to appear to contain the wrong data. Fix it by manually getting the per-CPU address from struct module. Closes #185. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 23:19:16 +01:00
it->yielded_percpu = false;
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
if (kmod_it->use_sys_module) {
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
char *path;
if (asprintf(&path, "/sys/module/%s/sections",
kmod_it->name) == -1)
return &drgn_enomem;
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
it->sections_dir = opendir(path);
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
free(path);
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
if (!it->sections_dir) {
return drgn_error_format_os("opendir", errno,
"/sys/module/%s/sections",
kmod_it->name);
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
}
return NULL;
} else {
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
it->sections_dir = NULL;
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
it->i = 0;
it->name = NULL;
/* it->nsections = mod->sect_attrs->nsections */
libdrgn: linux_kernel: optimize reading module list An upcoming fix requires us to always use the module list from the core dump rather than /proc/modules. However, with the existing code, this would cause a major startup time regression for the live kernel, mainly because reading from /proc/kcore is stupidly slow. We currently do 3 + strlen(module->name) reads for every module. We can reduce this to 1 read per module by reading the entire struct module at once. The size of struct module is ~700-900 bytes depending on the kernel configuration, which is still much faster to read than only reading what we need. In some benchmarks that I did with DRGN_USE_PROC_AND_SYS_MODULES=0, this reduced the time spent in the kernel module iterator from ~2.5ms per module to ~0.4ms per module. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:07:20 +01:00
err = drgn_object_member(&kmod_it->tmp1, &kmod_it->mod,
"sect_attrs");
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
if (err)
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
return err;
err = drgn_object_member_dereference(&kmod_it->tmp2,
&kmod_it->tmp1,
"nsections");
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
if (err)
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
return err;
err = drgn_object_read_unsigned(&kmod_it->tmp2,
&it->nsections);
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
if (err)
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
return err;
/* kmod_it->tmp1 = mod->sect_attrs->attrs */
return drgn_object_member_dereference(&kmod_it->tmp1,
&kmod_it->tmp1, "attrs");
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
}
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
static void
kernel_module_section_iterator_deinit(struct kernel_module_section_iterator *it)
{
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
if (it->sections_dir)
closedir(it->sections_dir);
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
else
free(it->name);
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
}
static struct drgn_error *
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
kernel_module_section_iterator_next_live(struct kernel_module_section_iterator *it,
const char **name_ret,
uint64_t *address_ret)
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 dirent *ent;
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
while ((errno = 0, ent = readdir(it->sections_dir))) {
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
if (ent->d_type == DT_DIR)
continue;
if (ent->d_type == DT_UNKNOWN) {
struct stat st;
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
if (fstatat(dirfd(it->sections_dir), ent->d_name, &st,
0) == -1) {
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
return drgn_error_format_os("fstatat", errno,
"/sys/module/%s/sections/%s",
it->kmod_it->name,
ent->d_name);
}
if (S_ISDIR(st.st_mode))
continue;
}
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
int fd = openat(dirfd(it->sections_dir), ent->d_name, O_RDONLY);
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
if (fd == -1) {
return drgn_error_format_os("openat", errno,
"/sys/module/%s/sections/%s",
it->kmod_it->name,
ent->d_name);
}
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
FILE *file = fdopen(fd, "r");
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
if (!file) {
close(fd);
return drgn_error_create_os("fdopen", errno, NULL);
}
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
int ret = fscanf(file, "%" SCNx64, address_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
fclose(file);
if (ret != 1) {
return drgn_error_format(DRGN_ERROR_OTHER,
"could not parse /sys/module/%s/sections/%s",
it->kmod_it->name,
ent->d_name);
}
*name_ret = ent->d_name;
return NULL;
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
if (errno) {
return drgn_error_format_os("readdir", errno,
"/sys/module/%s/sections",
it->kmod_it->name);
} else {
return &drgn_stop;
}
}
static struct drgn_error *
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
kernel_module_section_iterator_next(struct kernel_module_section_iterator *it,
const char **name_ret,
uint64_t *address_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
{
libdrgn: linux_kernel: fix global per-CPU variables in kernel modules The .data..percpu section is excluded from /sys/module and struct module::sect_attrs, which means that we default its address to 0. This results in global per-CPU variables in kernel modules being relocated starting from 0 rather than the offset of the per-CPU allocation made for the module, which in turn causes those variables to appear to contain the wrong data. Fix it by manually getting the per-CPU address from struct module. Closes #185. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 23:19:16 +01:00
struct drgn_error *err;
struct kernel_module_iterator *kmod_it = it->kmod_it;
// As of Linux 6.0, the .data..percpu section is not included in the
// section attributes. (kernel/module/sysfs.c:add_sect_attrs() only
// creates attributes for sections with the SHF_ALLOC flag set, but
// kernel/module/main.c:layout_and_allocate() clears the SHF_ALLOC flag
// for the .data..percpu section.) However, we need this address so that
// global per-CPU variables will be relocated correctly. Get it from
// `struct module`.
if (!it->yielded_percpu) {
it->yielded_percpu = true;
err = drgn_object_member(&kmod_it->tmp2, &kmod_it->mod,
"percpu");
if (!err) {
err = drgn_object_read_unsigned(&kmod_it->tmp2, address_ret);
if (err)
return err;
// struct module::percpu is NULL if the module doesn't
// have any per-CPU data.
if (*address_ret) {
*name_ret = ".data..percpu";
return NULL;
}
} else if (err->code == DRGN_ERROR_LOOKUP) {
// struct module::percpu doesn't exist if !SMP.
drgn_error_destroy(err);
} else {
return err;
}
}
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
if (it->sections_dir) {
return kernel_module_section_iterator_next_live(it, name_ret,
address_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
if (it->i >= it->nsections)
return &drgn_stop;
err = drgn_object_subscript(&kmod_it->tmp2, &kmod_it->tmp1, it->i++);
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
if (err)
return err;
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
err = drgn_object_member(&kmod_it->tmp3, &kmod_it->tmp2, "address");
if (err)
return err;
err = drgn_object_read_unsigned(&kmod_it->tmp3, address_ret);
if (err)
return err;
libdrgn: update module section iterator for Linux v5.8 Linux v5.8 changed the module section structure, so we need to get the section name differently. Closes #73. Reported-by: Serapheim Dimitropoulos <serapheim@delphix.com> Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 20:41:24 +01:00
/*
* Since Linux kernel commit ed66f991bb19 ("module: Refactor section
* attr into bin attribute") (in v5.8), the section name is
* module_sect_attr.battr.attr.name. Before that, it is simply
* module_sect_attr.name.
*/
err = drgn_object_member(&kmod_it->tmp2, &kmod_it->tmp2, "battr");
if (!err) {
err = drgn_object_member(&kmod_it->tmp2, &kmod_it->tmp2,
"attr");
if (err)
return err;
} else {
if (err->code != DRGN_ERROR_LOOKUP)
return err;
drgn_error_destroy(err);
}
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
err = drgn_object_member(&kmod_it->tmp3, &kmod_it->tmp2, "name");
if (err)
return err;
libdrgn: refactor kernel module iterator The next commit will allow using the offline path for the live kernel, so the offline naming won't make much sense. Fold the offline path into the top-level functions, and make the live path an escape hatch. Also add some comments and improve naming for the file and directory handles and update the coding style. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 07:22:01 +01:00
char *name;
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
err = drgn_object_read_c_string(&kmod_it->tmp3, &name);
if (err)
return err;
free(it->name);
*name_ret = it->name = name;
return NULL;
}
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
/*
* /lib/modules/$(uname -r)/modules.dep.bin maps all installed kernel modules to
* their filesystem path (and dependencies, which we don't care about). It is
* generated by depmod; the format is a fairly simple serialized radix tree.
*
* modules.dep(5) contains a warning: "These files are not intended for editing
* or use by any additional utilities as their format is subject to change in
* the future." But, the format hasn't changed since 2009, and pulling in
* libkmod is overkill since we only need a very small subset of its
* functionality (plus our minimal parser is more efficient). If the format
* changes in the future, we can reevaluate this.
*/
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
struct depmod_index {
void *addr;
size_t len;
char path[256];
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: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
static void depmod_index_deinit(struct depmod_index *depmod)
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: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
munmap(depmod->addr, depmod->len);
}
struct depmod_index_buffer {
struct binary_buffer bb;
struct depmod_index *depmod;
};
static struct drgn_error *depmod_index_buffer_error(struct binary_buffer *bb,
const char *pos,
const char *message)
{
struct depmod_index_buffer *buffer =
container_of(bb, struct depmod_index_buffer, bb);
return drgn_error_format(DRGN_ERROR_OTHER, "%s: %#tx: %s",
buffer->depmod->path,
pos - (const char *)buffer->depmod->addr,
message);
}
static void depmod_index_buffer_init(struct depmod_index_buffer *buffer,
struct depmod_index *depmod)
{
binary_buffer_init(&buffer->bb, depmod->addr, depmod->len, false,
depmod_index_buffer_error);
buffer->depmod = depmod;
}
static struct drgn_error *depmod_index_validate(struct depmod_index *depmod)
{
struct drgn_error *err;
struct depmod_index_buffer buffer;
depmod_index_buffer_init(&buffer, depmod);
uint32_t magic;
if ((err = binary_buffer_next_u32(&buffer.bb, &magic)))
return err;
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
if (magic != 0xb007f457) {
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
return binary_buffer_error(&buffer.bb,
"invalid magic 0x%" PRIx32, magic);
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: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
uint32_t version;
if ((err = binary_buffer_next_u32(&buffer.bb, &version)))
return err;
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
if (version != 0x00020001) {
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
return binary_buffer_error(&buffer.bb,
"unknown version 0x%" PRIx32,
version);
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
}
return NULL;
}
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
static struct drgn_error *depmod_index_init(struct depmod_index *depmod,
const char *osrelease)
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
{
struct drgn_error *err;
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
snprintf(depmod->path, sizeof(depmod->path),
"/lib/modules/%s/modules.dep.bin", osrelease);
int fd = open(depmod->path, O_RDONLY);
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
if (fd == -1)
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
return drgn_error_create_os("open", errno, depmod->path);
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: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
struct stat st;
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
if (fstat(fd, &st) == -1) {
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
err = drgn_error_create_os("fstat", errno, depmod->path);
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
goto out;
}
if (st.st_size < 0 || st.st_size > SIZE_MAX) {
err = &drgn_enomem;
goto out;
}
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
void *addr = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
if (addr == MAP_FAILED) {
err = drgn_error_create_os("mmap", errno, depmod->path);
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
goto out;
}
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
depmod->addr = addr;
depmod->len = st.st_size;
err = depmod_index_validate(depmod);
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
if (err)
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
depmod_index_deinit(depmod);
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
out:
close(fd);
return err;
}
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
/*
* Look up the path of the kernel module with the given name.
*
* @param[in] name Name of the kernel module.
* @param[out] path_ret Returned path of the kernel module, relative to
* /lib/modules/$(uname -r). This is @em not null-terminated. @c NULL if not
* found.
* @param[out] len_ret Returned length of @p path_ret.
*/
static struct drgn_error *depmod_index_find(struct depmod_index *depmod,
const char *name,
const char **path_ret,
size_t *len_ret)
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: linux_kernel: use names for kmod index constants This makes it much easier to follow along with the code and understand the format.
2020-06-25 21:53:46 +01:00
static const uint32_t INDEX_NODE_MASK = UINT32_C(0x0fffffff);
static const uint32_t INDEX_NODE_CHILDS = UINT32_C(0x20000000);
static const uint32_t INDEX_NODE_VALUES = UINT32_C(0x40000000);
static const uint32_t INDEX_NODE_PREFIX = UINT32_C(0x80000000);
libdrgn: clean up read.h helpers and avoid undefined pointer behavior There are a couple of related ways that we can cause undefined behavior when parsing a malformed DWARF or depmod index file: 1. There are several places where we increment the cursor to skip past some data. It is undefined behavior if the result points out of bounds of the data, even if we don't attempt to dereference it. 2. read_in_bounds() checks that ptr <= end. This pointer comparison is only defined if ptr and end both point to elements of the same array object or one past the last element. If ptr has gone past end, then this comparison is likely undefined anyways. Fix it by adding a helper to skip past data with bounds checking. Then, all of the helpers can assume that ptr <= end and maintain that invariant. while we're here and auditing all of the call sites, let's clean up the API and rename it from read_foo() to the less generic mread_foo(). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-07-07 01:44:39 +01:00
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
struct drgn_error *err;
struct depmod_index_buffer buffer;
depmod_index_buffer_init(&buffer, depmod);
/* depmod_index_validate() already checked that this is within bounds. */
buffer.bb.pos += 8;
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
uint32_t offset;
for (;;) {
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
if ((err = binary_buffer_next_u32(&buffer.bb, &offset)))
return err;
if ((offset & INDEX_NODE_MASK) > depmod->len) {
return binary_buffer_error(&buffer.bb,
"offset is out of bounds");
}
buffer.bb.pos = (const char *)depmod->addr + (offset & INDEX_NODE_MASK);
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: linux_kernel: use names for kmod index constants This makes it much easier to follow along with the code and understand the format.
2020-06-25 21:53:46 +01:00
if (offset & INDEX_NODE_PREFIX) {
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
const char *prefix;
size_t prefix_len;
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
if ((err = binary_buffer_next_string(&buffer.bb,
&prefix,
&prefix_len)))
return err;
if (strncmp(name, prefix, prefix_len) != 0)
goto not_found;
name += prefix_len;
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: linux_kernel: use names for kmod index constants This makes it much easier to follow along with the code and understand the format.
2020-06-25 21:53:46 +01:00
if (offset & INDEX_NODE_CHILDS) {
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
uint8_t first, last;
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
if ((err = binary_buffer_next_u8(&buffer.bb, &first)) ||
(err = binary_buffer_next_u8(&buffer.bb, &last)))
return err;
if (*name) {
uint8_t cur = *name;
if (cur < first || cur > last)
goto not_found;
if ((err = binary_buffer_skip(&buffer.bb,
4 * (cur - first))))
return err;
name++;
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
continue;
} else {
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
if ((err = binary_buffer_skip(&buffer.bb,
4 * (last - first + 1))))
return err;
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
break;
}
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
} else if (*name) {
goto not_found;
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
} else {
break;
}
}
libdrgn: linux_kernel: use names for kmod index constants This makes it much easier to follow along with the code and understand the format.
2020-06-25 21:53:46 +01:00
if (!(offset & INDEX_NODE_VALUES))
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
goto not_found;
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: clean up read.h helpers and avoid undefined pointer behavior There are a couple of related ways that we can cause undefined behavior when parsing a malformed DWARF or depmod index file: 1. There are several places where we increment the cursor to skip past some data. It is undefined behavior if the result points out of bounds of the data, even if we don't attempt to dereference it. 2. read_in_bounds() checks that ptr <= end. This pointer comparison is only defined if ptr and end both point to elements of the same array object or one past the last element. If ptr has gone past end, then this comparison is likely undefined anyways. Fix it by adding a helper to skip past data with bounds checking. Then, all of the helpers can assume that ptr <= end and maintain that invariant. while we're here and auditing all of the call sites, let's clean up the API and rename it from read_foo() to the less generic mread_foo(). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-07-07 01:44:39 +01:00
uint32_t value_count;
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
if ((err = binary_buffer_next_u32(&buffer.bb, &value_count)))
return err;
if (!value_count)
goto not_found; /* Or is this malformed? */
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
/* Skip over priority. */
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
if ((err = binary_buffer_skip(&buffer.bb, 4)))
return err;
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: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
const char *colon = memchr(buffer.bb.pos, ':',
buffer.bb.end - buffer.bb.pos);
if (!colon) {
return binary_buffer_error(&buffer.bb,
"expected string containing ':'");
}
*path_ret = buffer.bb.pos;
*len_ret = colon - buffer.bb.pos;
return NULL;
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: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
not_found:
*path_ret = NULL;
return NULL;
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
/*
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
* Identify an ELF file as a kernel module, vmlinux, or neither. We classify a
* file as a kernel module if it has a section named .gnu.linkonce.this_module.
* If it doesn't, but it does have a section named .init.text, we classify it as
* vmlinux.
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
*/
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
static struct drgn_error *identify_kernel_elf(Elf *elf,
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
bool *is_vmlinux_ret,
bool *is_module_ret)
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
{
size_t shstrndx;
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
if (elf_getshdrstrndx(elf, &shstrndx))
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
return drgn_error_libelf();
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
Elf_Scn *scn = NULL;
bool have_init_text = false;
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
while ((scn = elf_nextscn(elf, scn))) {
GElf_Shdr *shdr, shdr_mem;
const char *scnname;
shdr = gelf_getshdr(scn, &shdr_mem);
if (!shdr)
continue;
scnname = elf_strptr(elf, shstrndx, shdr->sh_name);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (!scnname)
libdrgn: handle errors from elf_strptr() For some reason, we consistently ignore errors from elf_strptr(), but we shouldn't. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-03-26 21:28:16 +00:00
return drgn_error_libelf();
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
if (strcmp(scnname, ".gnu.linkonce.this_module") == 0) {
*is_vmlinux_ret = false;
*is_module_ret = true;
return NULL;
} else if (strcmp(scnname, ".init.text") == 0) {
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
have_init_text = true;
}
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
}
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
*is_vmlinux_ret = have_init_text;
*is_module_ret = false;
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
return NULL;
}
libdrgn: clean up hash function APIs and improve documentation Use *_hash_pair() for hash functions that do the full double hashing and return a struct hash_pair and hash_*() for other hashing utility functions. Also change some of the equality function names to be more symmetric and improve the documentation. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 00:06:23 +01:00
DEFINE_HASH_MAP(elf_scn_name_map, const char *, Elf_Scn *,
libdrgn: require semicolon after DEFINE_{HASH,VECTOR,BINARY_SEARCH_TREE}* The lack of a semicolon after these macros has always confused tooling like cscope. We could add semicolons everywhere now, but let's enforce it for the future, too. Let's add a dummy struct forward declaration at the end of each macro that enforces this requirement and also provides a useful error message. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-08-02 22:54:59 +01:00
c_string_key_hash_pair, c_string_key_eq);
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
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
static struct drgn_error *
libdrgn: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
cache_kernel_module_sections(struct kernel_module_iterator *kmod_it, Elf *elf)
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
{
struct drgn_error *err;
libdrgn: add vector/hash table initializers and update coding style Declaring a local vector or hash table and separately initializing it with vector_init()/hash_table_init() is annoying. Add macros that can be used as initializers. This exposes several places where the C89 style of placing all declarations at the beginning of a block is awkward. I adopted this style from the Linux kernel, which uses C89 and thus requires this style. I'm now convinced that it's usually nicer to declare variables where they're used. So let's officially adopt the style of mixing declarations and code (and ditch the blank line after declarations) and update the functions touched by this change.
2020-07-01 20:37:16 +01:00
size_t shstrndx;
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (elf_getshdrstrndx(elf, &shstrndx))
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
return drgn_error_libelf();
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: add vector/hash table initializers and update coding style Declaring a local vector or hash table and separately initializing it with vector_init()/hash_table_init() is annoying. Add macros that can be used as initializers. This exposes several places where the C89 style of placing all declarations at the beginning of a block is awkward. I adopted this style from the Linux kernel, which uses C89 and thus requires this style. I'm now convinced that it's usually nicer to declare variables where they're used. So let's officially adopt the style of mixing declarations and code (and ditch the blank line after declarations) and update the functions touched by this change.
2020-07-01 20:37:16 +01:00
struct elf_scn_name_map scn_map = HASH_TABLE_INIT;
Elf_Scn *scn = NULL;
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
while ((scn = elf_nextscn(elf, scn))) {
libdrgn: add vector/hash table initializers and update coding style Declaring a local vector or hash table and separately initializing it with vector_init()/hash_table_init() is annoying. Add macros that can be used as initializers. This exposes several places where the C89 style of placing all declarations at the beginning of a block is awkward. I adopted this style from the Linux kernel, which uses C89 and thus requires this style. I'm now convinced that it's usually nicer to declare variables where they're used. So let's officially adopt the style of mixing declarations and code (and ditch the blank line after declarations) and update the functions touched by this change.
2020-07-01 20:37:16 +01:00
GElf_Shdr shdr_mem;
GElf_Shdr *shdr = gelf_getshdr(scn, &shdr_mem);
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
if (!shdr) {
err = drgn_error_libelf();
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
goto out_scn_map;
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
}
libdrgn: really fix failed kernel module symbol lookups It turns out this wasn't a problem with dwfl_addrmodule() at all; the real problem is that .init sections are freed once the module is loaded but we're still considering them for the address range we pass to dwfl_report_module(). Ignore those sections entirely (by omitting them from the section name to section index map). While we're here, let's not bother inserting non-SHF_ALLOC sections in the map.
2019-12-12 21:33:52 +00:00
if (!(shdr->sh_flags & SHF_ALLOC))
continue;
libdrgn: add vector/hash table initializers and update coding style Declaring a local vector or hash table and separately initializing it with vector_init()/hash_table_init() is annoying. Add macros that can be used as initializers. This exposes several places where the C89 style of placing all declarations at the beginning of a block is awkward. I adopted this style from the Linux kernel, which uses C89 and thus requires this style. I'm now convinced that it's usually nicer to declare variables where they're used. So let's officially adopt the style of mixing declarations and code (and ditch the blank line after declarations) and update the functions touched by this change.
2020-07-01 20:37:16 +01:00
struct elf_scn_name_map_entry entry = {
.key = elf_strptr(elf, shstrndx, shdr->sh_name),
.value = scn,
};
libdrgn: handle errors from elf_strptr() For some reason, we consistently ignore errors from elf_strptr(), but we shouldn't. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-03-26 21:28:16 +00:00
if (!entry.key) {
err = drgn_error_libelf();
goto out_scn_map;
}
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
if (elf_scn_name_map_insert(&scn_map, &entry, NULL) == -1) {
err = &drgn_enomem;
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
goto out_scn_map;
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: add vector/hash table initializers and update coding style Declaring a local vector or hash table and separately initializing it with vector_init()/hash_table_init() is annoying. Add macros that can be used as initializers. This exposes several places where the C89 style of placing all declarations at the beginning of a block is awkward. I adopted this style from the Linux kernel, which uses C89 and thus requires this style. I'm now convinced that it's usually nicer to declare variables where they're used. So let's officially adopt the style of mixing declarations and code (and ditch the blank line after declarations) and update the functions touched by this change.
2020-07-01 20:37:16 +01:00
struct kernel_module_section_iterator section_it;
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
err = kernel_module_section_iterator_init(&section_it, kmod_it);
if (err)
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
goto out_scn_map;
libdrgn: add vector/hash table initializers and update coding style Declaring a local vector or hash table and separately initializing it with vector_init()/hash_table_init() is annoying. Add macros that can be used as initializers. This exposes several places where the C89 style of placing all declarations at the beginning of a block is awkward. I adopted this style from the Linux kernel, which uses C89 and thus requires this style. I'm now convinced that it's usually nicer to declare variables where they're used. So let's officially adopt the style of mixing declarations and code (and ditch the blank line after declarations) and update the functions touched by this change.
2020-07-01 20:37:16 +01:00
const char *name;
uint64_t address;
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
while (!(err = kernel_module_section_iterator_next(&section_it, &name,
&address))) {
libdrgn: add vector/hash table initializers and update coding style Declaring a local vector or hash table and separately initializing it with vector_init()/hash_table_init() is annoying. Add macros that can be used as initializers. This exposes several places where the C89 style of placing all declarations at the beginning of a block is awkward. I adopted this style from the Linux kernel, which uses C89 and thus requires this style. I'm now convinced that it's usually nicer to declare variables where they're used. So let's officially adopt the style of mixing declarations and code (and ditch the blank line after declarations) and update the functions touched by this change.
2020-07-01 20:37:16 +01:00
struct elf_scn_name_map_iterator it =
elf_scn_name_map_search(&scn_map, &name);
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
if (it.entry) {
libdrgn: add vector/hash table initializers and update coding style Declaring a local vector or hash table and separately initializing it with vector_init()/hash_table_init() is annoying. Add macros that can be used as initializers. This exposes several places where the C89 style of placing all declarations at the beginning of a block is awkward. I adopted this style from the Linux kernel, which uses C89 and thus requires this style. I'm now convinced that it's usually nicer to declare variables where they're used. So let's officially adopt the style of mixing declarations and code (and ditch the blank line after declarations) and update the functions touched by this change.
2020-07-01 20:37:16 +01:00
GElf_Shdr shdr_mem;
GElf_Shdr *shdr = gelf_getshdr(it.entry->value,
&shdr_mem);
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
if (!shdr) {
err = drgn_error_libelf();
break;
}
shdr->sh_addr = address;
if (!gelf_update_shdr(it.entry->value, shdr)) {
err = drgn_error_libelf();
break;
}
}
}
libdrgn: clean up usage of drgn_stop Use drgn_not_found where it's more appropriate, and check explicitly against drgn_stop instead of err->code == DRGN_ERROR_STOP. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-03-05 20:46:06 +00:00
if (err && err != &drgn_stop)
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
goto out_section_it;
err = NULL;
out_section_it:
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
kernel_module_section_iterator_deinit(&section_it);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
out_scn_map:
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
elf_scn_name_map_deinit(&scn_map);
return err;
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: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
struct kernel_module_file {
const char *path;
int fd;
Elf *elf;
/*
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
* Kernel module build ID. This is owned by the Elf handle. Because we
* use this as the key in the kernel_module_table, the file must always
* be removed from the table before it is reported to the DWARF index
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
* (which takes ownership of the Elf handle).
*/
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
const void *gnu_build_id;
size_t gnu_build_id_len;
/* Next file with the same build ID. */
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
struct kernel_module_file *next;
};
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
static struct nstring
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
kernel_module_table_key(struct kernel_module_file * const *entry)
{
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
return (struct nstring){
(*entry)->gnu_build_id, (*entry)->gnu_build_id_len
};
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
}
DEFINE_HASH_TABLE(kernel_module_table, struct kernel_module_file *,
libdrgn: require semicolon after DEFINE_{HASH,VECTOR,BINARY_SEARCH_TREE}* The lack of a semicolon after these macros has always confused tooling like cscope. We could add semicolons everywhere now, but let's enforce it for the future, too. Let's add a dummy struct forward declaration at the end of each macro that enforces this requirement and also provides a useful error message. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-08-02 22:54:59 +01:00
kernel_module_table_key, nstring_hash_pair, nstring_eq);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
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
static struct drgn_error *
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
report_loaded_kernel_module(struct drgn_debug_info_load_state *load,
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
struct kernel_module_iterator *kmod_it,
struct kernel_module_table *kmod_table)
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
{
struct drgn_error *err;
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
struct nstring key;
err = kernel_module_iterator_gnu_build_id(kmod_it,
(const void **)&key.str,
&key.len);
if (err || key.len == 0) {
return drgn_debug_info_report_error(load, kmod_it->name,
"could not find GNU build ID",
err);
}
struct hash_pair hp = kernel_module_table_hash(&key);
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
struct kernel_module_table_iterator it =
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
kernel_module_table_search_hashed(kmod_table, &key, hp);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (!it.entry)
return &drgn_not_found;
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
struct kernel_module_file *kmod = *it.entry;
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
kernel_module_table_delete_iterator_hashed(kmod_table, it, hp);
do {
libdrgn: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
err = cache_kernel_module_sections(kmod_it, kmod->elf);
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
if (err) {
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
err = drgn_debug_info_report_error(load, kmod->path,
"could not get section addresses",
err);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (err)
return err;
libdrgn: fix infinite loop on error caching kernel module sections If cache_kernel_module_sections() in report_loaded_kernel_module() fails, we continue to the next iteration without advancing to the next kernel module. Then, we fail on that same kernel module and repeat. Make sure that we go to the next kernel module. Fixes: 423d2cd5009e ("libdrgn: dwarf_index: rework file reporting") Reported-by: Serapheim Dimitropoulos <serapheim@delphix.com> Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 20:25:22 +01:00
goto next;
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: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
err = drgn_debug_info_report_elf(load, kmod->path, kmod->fd,
libdrgn: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
kmod->elf, kmod_it->start,
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
kmod_it->end, kmod_it->name,
libdrgn: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
NULL);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
kmod->elf = NULL;
kmod->fd = -1;
if (err)
return err;
libdrgn: fix infinite loop on error caching kernel module sections If cache_kernel_module_sections() in report_loaded_kernel_module() fails, we continue to the next iteration without advancing to the next kernel module. Then, we fail on that same kernel module and repeat. Make sure that we go to the next kernel module. Fixes: 423d2cd5009e ("libdrgn: dwarf_index: rework file reporting") Reported-by: Serapheim Dimitropoulos <serapheim@delphix.com> Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 20:25:22 +01:00
next:
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
kmod = kmod->next;
} while (kmod);
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
return NULL;
}
static struct drgn_error *
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
report_default_kernel_module(struct drgn_debug_info_load_state *load,
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 kernel_module_iterator *kmod_it,
struct depmod_index *depmod)
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: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
static const char * const module_paths[] = {
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
"/usr/lib/debug/lib/modules/%s/%.*s",
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
"/usr/lib/debug/lib/modules/%s/%.*s.debug",
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
"/lib/modules/%s/%.*s%.*s",
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
NULL,
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
};
struct drgn_error *err;
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +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
const char *depmod_path;
size_t depmod_path_len;
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
err = depmod_index_find(depmod, kmod_it->name, &depmod_path,
&depmod_path_len);
if (err) {
return drgn_debug_info_report_error(load,
"kernel modules",
"could not parse depmod",
err);
} else if (!depmod_path) {
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
return drgn_debug_info_report_error(load, kmod_it->name,
"could not find module in depmod",
NULL);
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: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
size_t extension_len;
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (depmod_path_len >= 3 &&
(memcmp(depmod_path + depmod_path_len - 3, ".gz", 3) == 0 ||
memcmp(depmod_path + depmod_path_len - 3, ".xz", 3) == 0))
extension_len = 3;
else
extension_len = 0;
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
char *path;
int fd;
Elf *elf;
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
err = find_elf_file(&path, &fd, &elf, module_paths,
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
load->dbinfo->prog->vmcoreinfo.osrelease,
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
depmod_path_len - extension_len, depmod_path,
extension_len,
depmod_path + depmod_path_len - extension_len);
if (err)
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
return drgn_debug_info_report_error(load, NULL, NULL, err);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (!elf) {
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
return drgn_debug_info_report_error(load, kmod_it->name,
"could not find .ko",
NULL);
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
}
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: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
err = cache_kernel_module_sections(kmod_it, elf);
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
if (err) {
libdrgn: fix use-after-free in kernel module reporting error case We're freeing path and then using it to report an error. This has some weird knock-on effects. Since we freed the path, the error message contains garbage. So, PyErr_SetString() can't decode it as a UTF-8 string. The end result is a MissingDebugInfoError with no message. Fix it by creating the error before freeing the path. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 19:55:06 +01:00
err = drgn_debug_info_report_error(load, path,
"could not get section addresses",
err);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
elf_end(elf);
close(fd);
free(path);
libdrgn: fix use-after-free in kernel module reporting error case We're freeing path and then using it to report an error. This has some weird knock-on effects. Since we freed the path, the error message contains garbage. So, PyErr_SetString() can't decode it as a UTF-8 string. The end result is a MissingDebugInfoError with no message. Fix it by creating the error before freeing the path. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 19:55:06 +01:00
return err;
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: linux_kernel: get module address range directly Instead of getting the address range from the sections we find, get it directly from /proc/modules or from the `struct module`. (We already had partial code to get the address range, but I can't remember why I didn't use it.) The real motivation for this is the upcoming module rework: it'll allow us to report the module and its address range before iterating through its sections. But it also means that we don't need the heuristic to ignore special sections that shouldn't be considered part of the address range (e.g., .init, .data..percpu [the latter of which we should be ignoring but get away with not because it's excluded from sysfs]). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-05-23 23:31:12 +01:00
err = drgn_debug_info_report_elf(load, path, fd, elf, kmod_it->start,
kmod_it->end, kmod_it->name, NULL);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
free(path);
return err;
}
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
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
static struct drgn_error *
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
report_loaded_kernel_modules(struct drgn_debug_info_load_state *load,
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
struct kernel_module_table *kmod_table,
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
struct depmod_index *depmod, bool use_sys_module)
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: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
struct drgn_program *prog = load->dbinfo->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
struct drgn_error *err;
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
struct kernel_module_iterator kmod_it;
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
err = kernel_module_iterator_init(&kmod_it, prog, use_sys_module);
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
if (err) {
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
kernel_module_iterator_error:
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
return drgn_debug_info_report_error(load, "kernel modules",
"could not find loaded kernel modules",
err);
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
for (;;) {
err = kernel_module_iterator_next(&kmod_it);
libdrgn: clean up usage of drgn_stop Use drgn_not_found where it's more appropriate, and check explicitly against drgn_stop instead of err->code == DRGN_ERROR_STOP. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-03-05 20:46:06 +00:00
if (err == &drgn_stop) {
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
err = NULL;
break;
} else if (err) {
kernel_module_iterator_deinit(&kmod_it);
goto kernel_module_iterator_error;
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: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
/* Look for an explicitly-reported file first. */
if (kmod_table) {
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
err = report_loaded_kernel_module(load, &kmod_it,
kmod_table);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (!err)
continue;
else if (err != &drgn_not_found)
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
break;
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
}
/*
* If it was not reported explicitly and we're also reporting the
* defaults, look for the module at the standard locations unless we've
* already indexed that module.
*/
if (depmod &&
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
!drgn_debug_info_is_indexed(load->dbinfo, kmod_it.name)) {
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
if (!depmod->addr) {
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
err = depmod_index_init(depmod,
prog->vmcoreinfo.osrelease);
if (err) {
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
depmod->addr = NULL;
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
err = drgn_debug_info_report_error(load,
"kernel modules",
"could not read depmod",
err);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (err)
break;
depmod = NULL;
continue;
}
}
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
err = report_default_kernel_module(load, &kmod_it,
depmod);
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
if (err)
break;
}
}
kernel_module_iterator_deinit(&kmod_it);
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
return err;
}
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
static struct drgn_error *
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
report_kernel_modules(struct drgn_debug_info_load_state *load,
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
struct kernel_module_file *kmods, size_t num_kmods,
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
bool vmlinux_is_pending)
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: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
struct drgn_program *prog = load->dbinfo->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
struct drgn_error *err;
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
if (!num_kmods && !load->load_default)
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
return NULL;
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
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
/*
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
* If we're debugging the running kernel, we can use
* /sys/module/$module/notes and /sys/module/$module/sections instead of
* getting the equivalent information from the core dump. This fast path
* can be disabled via an environment variable for testing.
libdrgn: add an environment variable to disable use of /proc/modules and /sys/module We use /proc/modules and /sys/module to find loaded kernel modules for the running kernel instead of walking the module list in the core dump as an optimization. To make it easier to test the core dump path, add an environment variable to disable the optimization. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 19:24:39 +01:00
*/
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
bool use_sys_module = false;
libdrgn: add an environment variable to disable use of /proc/modules and /sys/module We use /proc/modules and /sys/module to find loaded kernel modules for the running kernel instead of walking the module list in the core dump as an optimization. To make it easier to test the core dump path, add an environment variable to disable the optimization. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 19:24:39 +01:00
if (prog->flags & DRGN_PROGRAM_IS_LIVE) {
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
char *env = getenv("DRGN_USE_SYS_MODULE");
use_sys_module = !env || atoi(env);
libdrgn: add an environment variable to disable use of /proc/modules and /sys/module We use /proc/modules and /sys/module to find loaded kernel modules for the running kernel instead of walking the module list in the core dump as an optimization. To make it easier to test the core dump path, add an environment variable to disable the optimization. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 19:24:39 +01:00
}
/*
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
* We need to index vmlinux now so that we can walk the list of modules
* in the kernel.
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
*/
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
if (vmlinux_is_pending) {
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
err = drgn_debug_info_report_flush(load);
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
if (err)
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
return err;
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: add vector/hash table initializers and update coding style Declaring a local vector or hash table and separately initializing it with vector_init()/hash_table_init() is annoying. Add macros that can be used as initializers. This exposes several places where the C89 style of placing all declarations at the beginning of a block is awkward. I adopted this style from the Linux kernel, which uses C89 and thus requires this style. I'm now convinced that it's usually nicer to declare variables where they're used. So let's officially adopt the style of mixing declarations and code (and ditch the blank line after declarations) and update the functions touched by this change.
2020-07-01 20:37:16 +01:00
struct kernel_module_table kmod_table = HASH_TABLE_INIT;
struct depmod_index depmod;
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
depmod.addr = NULL;
libdrgn: add vector/hash table initializers and update coding style Declaring a local vector or hash table and separately initializing it with vector_init()/hash_table_init() is annoying. Add macros that can be used as initializers. This exposes several places where the C89 style of placing all declarations at the beginning of a block is awkward. I adopted this style from the Linux kernel, which uses C89 and thus requires this style. I'm now convinced that it's usually nicer to declare variables where they're used. So let's officially adopt the style of mixing declarations and code (and ditch the blank line after declarations) and update the functions touched by this change.
2020-07-01 20:37:16 +01:00
struct kernel_module_table_iterator it;
for (size_t i = 0; i < num_kmods; i++) {
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
struct kernel_module_file *kmod = &kmods[i];
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
ssize_t build_id_len =
dwelf_elf_gnu_build_id(kmod->elf, &kmod->gnu_build_id);
if (build_id_len < 0) {
err = drgn_debug_info_report_error(load, kmod->path,
NULL,
drgn_error_libelf());
if (err)
goto out;
continue;
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
}
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
kmod->gnu_build_id_len = build_id_len;
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: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
struct nstring key = kernel_module_table_key(&kmod);
struct hash_pair hp = kernel_module_table_hash(&key);
it = kernel_module_table_search_hashed(&kmod_table, &key, hp);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (it.entry) {
kmod->next = *it.entry;
*it.entry = kmod;
} else {
if (kernel_module_table_insert_searched(&kmod_table,
&kmod, hp,
NULL) == -1) {
err = &drgn_enomem;
goto out;
}
kmod->next = NULL;
}
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: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
err = report_loaded_kernel_modules(load, num_kmods ? &kmod_table : NULL,
libdrgn: add an environment variable to disable use of /proc/modules and /sys/module We use /proc/modules and /sys/module to find loaded kernel modules for the running kernel instead of walking the module list in the core dump as an optimization. To make it easier to test the core dump path, add an environment variable to disable the optimization. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-13 19:24:39 +01:00
load->load_default ? &depmod : NULL,
libdrgn: linux_kernel: always use module list from core For the next fix, we need the address of the .data..percpu section, which is only available directly from the struct module and not from anywhere in /proc or /sys. Get rid of the /proc/modules fast path (and update the name of the testing environment variable from DRGN_USE_PROC_AND_SYS_MODULES to DRGN_USE_SYS_MODULE). This has some small overhead (~20ms longer startup time in my benchmarks) and means that we no longer determine the loaded modules if vmlinux is missing, but fixing the per-CPU issue is more important. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-09-12 19:17:42 +01:00
use_sys_module);
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
if (err)
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
goto out;
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
/* Anything left over was not loaded. */
for (it = kernel_module_table_first(&kmod_table); it.entry; ) {
struct kernel_module_file *kmod = *it.entry;
it = kernel_module_table_delete_iterator(&kmod_table, it);
do {
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
err = drgn_debug_info_report_elf(load, kmod->path,
kmod->fd, kmod->elf, 0,
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
0, kmod->path, NULL);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
kmod->elf = NULL;
kmod->fd = -1;
if (err)
goto out;
kmod = kmod->next;
} while (kmod);
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
}
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
err = NULL;
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
out:
libdrgn: report better errors when parsing DWARF/kmod index If the DWARF index encounters any error while parsing, it returns an error saying only "debug information is truncated", which makes it hard to track down parsing errors. The kmod index parser silently swallows errors. For both, replace the mread functions with a higher-level binary_buffer interface that can include more information including the location of the error. For example: /tmp/mybinary: .debug_info+0x4: expected at least 56 bytes, have 55 Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-10-29 00:35:09 +00:00
if (depmod.addr)
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
depmod_index_deinit(&depmod);
kernel_module_table_deinit(&kmod_table);
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
return err;
}
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: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
static struct drgn_error *
report_vmlinux(struct drgn_debug_info_load_state *load,
bool *vmlinux_is_pending)
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
{
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
static const char * const vmlinux_paths[] = {
/*
* The files under /usr/lib/debug should always have debug
* information, so check for those first.
*/
"/usr/lib/debug/boot/vmlinux-%s",
"/usr/lib/debug/lib/modules/%s/vmlinux",
"/boot/vmlinux-%s",
"/lib/modules/%s/build/vmlinux",
"/lib/modules/%s/vmlinux",
NULL,
};
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
struct drgn_program *prog = load->dbinfo->prog;
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 *err;
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
char *path;
int fd;
Elf *elf;
err = find_elf_file(&path, &fd, &elf, vmlinux_paths,
prog->vmcoreinfo.osrelease);
if (err)
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
return drgn_debug_info_report_error(load, NULL, NULL, err);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (!elf) {
err = drgn_error_format(DRGN_ERROR_OTHER,
"could not find vmlinux for %s",
prog->vmcoreinfo.osrelease);
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
return drgn_debug_info_report_error(load, "kernel", NULL, err);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +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
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
uint64_t start, end;
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
err = elf_address_range(elf, prog->vmcoreinfo.kaslr_offset, &start,
&end);
if (err) {
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
err = drgn_debug_info_report_error(load, path, NULL, err);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
elf_end(elf);
close(fd);
free(path);
return err;
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: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
err = drgn_debug_info_report_elf(load, path, fd, elf, start, end,
"kernel", vmlinux_is_pending);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
free(path);
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
return err;
}
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 *
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
linux_kernel_report_debug_info(struct drgn_debug_info_load_state *load)
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
{
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
struct drgn_program *prog = load->dbinfo->prog;
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 *err;
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
struct kernel_module_file *kmods;
if (load->num_paths) {
kmods = malloc_array(load->num_paths, sizeof(*kmods));
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (!kmods)
return &drgn_enomem;
} else {
kmods = NULL;
}
/*
* We may need to index vmlinux before we can properly report kernel
* modules. So, this sets aside kernel modules and reports everything
* else.
*/
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
size_t num_kmods = 0;
bool vmlinux_is_pending = false;
for (size_t i = 0; i < load->num_paths; i++) {
const char *path = load->paths[i];
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
int fd;
Elf *elf;
err = open_elf_file(path, &fd, &elf);
if (err) {
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
err = drgn_debug_info_report_error(load, path, NULL,
err);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (err)
goto out;
continue;
}
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
bool is_vmlinux, is_module;
err = identify_kernel_elf(elf, &is_vmlinux, &is_module);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (err) {
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
err = drgn_debug_info_report_error(load, path, NULL,
err);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
elf_end(elf);
close(fd);
if (err)
goto out;
continue;
}
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
if (is_module) {
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
struct kernel_module_file *kmod = &kmods[num_kmods++];
kmod->path = path;
kmod->fd = fd;
kmod->elf = elf;
} else if (is_vmlinux) {
uint64_t start, end;
err = elf_address_range(elf,
prog->vmcoreinfo.kaslr_offset,
&start, &end);
if (err) {
elf_end(elf);
close(fd);
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
err = drgn_debug_info_report_error(load, path,
NULL, err);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (err)
goto out;
continue;
}
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
bool is_new;
err = drgn_debug_info_report_elf(load, path, fd, elf,
start, end, "kernel",
&is_new);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (err)
goto out;
if (is_new)
vmlinux_is_pending = true;
} else {
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
err = drgn_debug_info_report_elf(load, path, fd, elf, 0,
0, NULL, NULL);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (err)
goto out;
}
}
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
if (load->load_main && !vmlinux_is_pending &&
!drgn_debug_info_is_indexed(load->dbinfo, "kernel")) {
err = report_vmlinux(load, &vmlinux_is_pending);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
if (err)
goto out;
}
libdrgn: linux_kernel: match explicitly-reported kernel modules by build ID Currently, we identify explicitly-reported kernel modules by the module name that we get from the .modinfo or the .gnu.linkonce.this_module section. However, objcopy --only-keep-debug (used for some Linux distro's separate debug files) does not keep these sections. This means that passing a file processed by objcopy --only-keep-debug to, e.g., drgn -s, fails with "could not find kernel module name". Instead of using the module name as the identifier, let's use the module's GNU build ID. We can get it on a live system from /sys/module/<module>/notes/, and on a core dump from struct module::notes_attrs (which is the implementation of that sysfs directory). This was split out of my larger debug info discovery rework, which will make more use of the build ID. Closes #178. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-01 14:00:00 +01:00
err = report_kernel_modules(load, kmods, num_kmods, vmlinux_is_pending);
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
out:
libdrgn: move debugging information tracking into drgn_debug_info Debugging information tracking is currently in two places: drgn_program finds debugging information, and drgn_dwarf_index stores it. Both of these responsibilities make more sense as part of drgn_debug_info, so let's move them there. This prepares us to track extra debugging information that isn't pertinent to indexing. This also reworks a couple of details of loading debugging information: - drgn_dwarf_module and drgn_dwfl_module_userdata are consolidated into a single structure, drgn_debug_info_module. - The first pass of DWARF indexing now happens in parallel with reading compilation units (by using OpenMP tasks). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-09-16 01:42:53 +01:00
for (size_t i = 0; i < num_kmods; i++) {
libdrgn: dwarf_index: rework file reporting Currently, the interface between the DWARF index, libdwfl, and the code which finds and reports vmlinux/kernel modules is spaghetti. The DWARF index tracks Dwfl_Modules via their userdata. However, despite conceptually being owned by the DWARF index, the reporting code reports the Dwfl_Modules and sets up the userdata. These Dwfl_Modules and drgn_dwfl_module_userdatas are messy to track and pass between the layers. This reworks the architecture so that the DWARF index owns the Dwfl instance and files are reported to the DWARF index; the DWARF index takes care of reporting to libdwfl internally. In addition to making the interface for the reporter much cleaner, this improves a few things as a side-effect: - We now deduplicate on build ID in addition to path. - We now skip searching for vmlinux and/or kernel modules if they were already indexed. - We now support compressed ELF files via libdwelf. - We can now load default debug info at the same time as additional debug info.
2019-09-25 01:13:53 +01:00
elf_end(kmods[i].elf);
if (kmods[i].fd != -1)
close(kmods[i].fd);
}
free(kmods);
return err;
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
}
Reference in New Issue Copy Permalink