2020-05-15 23:13:02 +01:00
|
|
|
// Copyright (c) Facebook, Inc. and its affiliates.
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
// SPDX-License-Identifier: GPL-3.0+
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @file
|
|
|
|
*
|
|
|
|
* Program internals.
|
|
|
|
*
|
|
|
|
* See @ref ProgramInternals.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef DRGN_PROGRAM_H
|
|
|
|
#define DRGN_PROGRAM_H
|
|
|
|
|
libdrgn: use libdwfl
libdwfl is the elfutils "DWARF frontend library". It has high-level
functionality for looking up symbols, walking stack traces, etc. In
order to use this functionality, we need to report our debugging
information through libdwfl. For userspace programs, libdwfl has a much
better implementation than drgn for automatically finding debug
information from a core dump or PID. However, for the kernel, libdwfl
has a few issues:
- It only supports finding debug information for the running kernel, not
vmcores.
- It determines the vmlinux address range by reading /proc/kallsyms,
which is slow (~70ms on my machine).
- If separate debug information isn't available for a kernel module, it
finds it by walking /lib/modules/$(uname -r)/kernel; this is repeated
for every module.
- It doesn't find kernel modules with names containing both dashes and
underscores (e.g., aes-x86_64).
Luckily, drgn already solved all of these problems, and with some
effort, we can keep doing it ourselves and report it to libdwfl.
The conversion replaces a bunch of code for dealing with userspace core
dump notes, /proc/$pid/maps, and relocations.
2019-07-15 08:51:30 +01:00
|
|
|
#include <elfutils/libdwfl.h>
|
2019-08-02 08:00:59 +01:00
|
|
|
#ifdef WITH_LIBKDUMPFILE
|
|
|
|
#include <libkdumpfile/kdumpfile.h>
|
|
|
|
#endif
|
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
|
|
|
|
2019-10-24 22:26:45 +01:00
|
|
|
#include "hash_table.h"
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
#include "memory_reader.h"
|
2019-07-24 00:26:29 +01:00
|
|
|
#include "object_index.h"
|
2019-07-29 08:57:28 +01:00
|
|
|
#include "platform.h"
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
#include "type_index.h"
|
2020-05-20 19:30:00 +01:00
|
|
|
#include "vector.h"
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @ingroup Internals
|
|
|
|
*
|
|
|
|
* @defgroup ProgramInternals Programs
|
|
|
|
*
|
|
|
|
* Program internals.
|
|
|
|
*
|
|
|
|
* @{
|
|
|
|
*/
|
|
|
|
|
|
|
|
/** The important parts of the VMCOREINFO note of a Linux kernel core. */
|
|
|
|
struct vmcoreinfo {
|
|
|
|
/** <tt>uname -r</tt> */
|
|
|
|
char osrelease[128];
|
2019-05-29 00:39:11 +01:00
|
|
|
/** PAGE_SIZE of the kernel. */
|
|
|
|
uint64_t page_size;
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
/**
|
|
|
|
* The offset from the compiled address of the kernel image to its
|
|
|
|
* actual address in memory.
|
|
|
|
*
|
|
|
|
* This is non-zero if kernel address space layout randomization (KASLR)
|
|
|
|
* is enabled.
|
|
|
|
*/
|
|
|
|
uint64_t kaslr_offset;
|
2020-05-01 09:00:27 +01:00
|
|
|
/** Kernel page table. */
|
|
|
|
uint64_t swapper_pg_dir;
|
|
|
|
/** Whether 5-level paging was enabled. */
|
2020-04-09 22:29:47 +01:00
|
|
|
bool pgtable_l5_enabled;
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
};
|
|
|
|
|
2020-05-20 19:30:00 +01:00
|
|
|
DEFINE_VECTOR_TYPE(drgn_prstatus_vector, struct string)
|
2019-10-24 22:26:45 +01:00
|
|
|
DEFINE_HASH_MAP_TYPE(drgn_prstatus_map, uint32_t, struct string)
|
|
|
|
|
2019-05-10 07:53:16 +01:00
|
|
|
struct drgn_dwarf_info_cache;
|
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_dwarf_index;
|
2019-05-10 07:53:16 +01:00
|
|
|
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
struct drgn_program {
|
|
|
|
/** @privatesection */
|
2019-05-01 19:22:59 +01:00
|
|
|
struct drgn_memory_reader reader;
|
|
|
|
struct drgn_type_index tindex;
|
2019-07-24 00:26:29 +01:00
|
|
|
struct drgn_object_index oindex;
|
2019-05-10 07:53:16 +01:00
|
|
|
struct drgn_memory_file_segment *file_segments;
|
2020-02-26 22:32:35 +00:00
|
|
|
/* Default language of the program. */
|
|
|
|
const struct drgn_language *lang;
|
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
|
|
|
/*
|
|
|
|
* Valid iff <tt>flags & DRGN_PROGRAM_IS_LINUX_KERNEL</tt>.
|
|
|
|
*/
|
2019-05-01 19:22:59 +01:00
|
|
|
struct vmcoreinfo vmcoreinfo;
|
2020-04-09 22:59:42 +01:00
|
|
|
/* Cached PAGE_OFFSET. */
|
|
|
|
uint64_t page_offset;
|
2020-04-09 23:37:46 +01:00
|
|
|
/* Cached vmemmap. */
|
|
|
|
uint64_t vmemmap;
|
2020-05-20 01:09:00 +01:00
|
|
|
/* Cached THREAD_SIZE. */
|
|
|
|
uint64_t thread_size;
|
2019-10-24 21:13:01 +01:00
|
|
|
#ifdef WITH_LIBKDUMPFILE
|
|
|
|
kdump_ctx_t *kdump_ctx;
|
|
|
|
#endif
|
|
|
|
/*
|
|
|
|
* Valid iff <tt>!(flags & DRGN_PROGRAM_IS_LIVE)</tt>, unless the file
|
|
|
|
* was a kdump file.
|
|
|
|
*/
|
|
|
|
Elf *core;
|
|
|
|
int core_fd;
|
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
|
|
|
/*
|
|
|
|
* Valid iff
|
|
|
|
* <tt>(flags & (DRGN_PROGRAM_IS_LINUX_KERNEL | DRGN_PROGRAM_IS_LIVE)) ==
|
|
|
|
* DRGN_PROGRAM_IS_LIVE</tt>.
|
|
|
|
*/
|
|
|
|
pid_t pid;
|
2019-07-17 22:16:38 +01:00
|
|
|
struct drgn_dwarf_info_cache *_dicache;
|
2020-05-20 19:30:00 +01:00
|
|
|
union {
|
|
|
|
/*
|
|
|
|
* For the Linux kernel, PRSTATUS notes indexed by CPU. See @ref
|
|
|
|
* drgn_architecture_info::linux_kernel_set_initial_registers
|
|
|
|
* for why we don't use the PID map.
|
|
|
|
*/
|
|
|
|
struct drgn_prstatus_vector prstatus_vector;
|
|
|
|
/* For userspace programs, PRSTATUS notes indexed by PID. */
|
|
|
|
struct drgn_prstatus_map prstatus_map;
|
|
|
|
};
|
2019-07-29 22:41:33 +01:00
|
|
|
/* See @ref drgn_object_stack_trace(). */
|
|
|
|
struct drgn_error *stack_trace_err;
|
2019-10-26 00:11:14 +01:00
|
|
|
/* See @ref drgn_object_stack_trace_next_thread(). */
|
|
|
|
const struct drgn_object *stack_trace_obj;
|
|
|
|
uint32_t stack_trace_tid;
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
enum drgn_program_flags flags;
|
2019-07-29 08:57:28 +01:00
|
|
|
struct drgn_platform platform;
|
|
|
|
bool has_platform;
|
2019-07-29 22:41:33 +01:00
|
|
|
bool attached_dwfl_state;
|
2019-10-24 22:26:45 +01:00
|
|
|
bool prstatus_cached;
|
2020-05-06 08:35:29 +01:00
|
|
|
/*
|
|
|
|
* Whether @ref drgn_program::pgtable_it is currently being used. Used
|
|
|
|
* to prevent address translation from recursing.
|
|
|
|
*/
|
|
|
|
bool pgtable_it_in_use;
|
2019-10-28 09:38:51 +00:00
|
|
|
|
2020-05-06 02:02:52 +01:00
|
|
|
/* Page table iterator for linux_helper_read_vm(). */
|
|
|
|
struct pgtable_iterator *pgtable_it;
|
2019-10-28 09:38:51 +00:00
|
|
|
/* Cache for @ref linux_helper_task_state_to_char(). */
|
|
|
|
char *task_state_chars;
|
|
|
|
uint64_t task_report;
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
};
|
|
|
|
|
2019-05-01 19:22:59 +01:00
|
|
|
/** Initialize a @ref drgn_program. */
|
2019-05-10 07:53:16 +01:00
|
|
|
void drgn_program_init(struct drgn_program *prog,
|
2019-07-29 08:57:28 +01:00
|
|
|
const struct drgn_platform *platform);
|
2019-04-23 09:46:24 +01:00
|
|
|
|
2019-05-01 19:22:59 +01:00
|
|
|
/** Deinitialize a @ref drgn_program. */
|
2019-04-23 09:46:24 +01:00
|
|
|
void drgn_program_deinit(struct drgn_program *prog);
|
|
|
|
|
2019-08-02 08:00:59 +01:00
|
|
|
/**
|
|
|
|
* Set the @ref drgn_platform of a @ref drgn_program if it hasn't been set
|
|
|
|
* yet.
|
|
|
|
*/
|
|
|
|
void drgn_program_set_platform(struct drgn_program *prog,
|
|
|
|
const struct drgn_platform *platform);
|
|
|
|
|
2019-04-23 09:46:24 +01:00
|
|
|
/**
|
2019-05-10 07:53:16 +01:00
|
|
|
* Implement @ref drgn_program_from_core_dump() on an initialized @ref
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
* drgn_program.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_program_init_core_dump(struct drgn_program *prog,
|
2019-05-10 07:53:16 +01:00
|
|
|
const char *path);
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
|
|
|
|
/**
|
2019-05-10 07:53:16 +01:00
|
|
|
* Implement @ref drgn_program_from_kernel() on an initialized @ref
|
|
|
|
* drgn_program.
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
*/
|
2019-05-10 07:53:16 +01:00
|
|
|
struct drgn_error *drgn_program_init_kernel(struct drgn_program *prog);
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
|
|
|
|
/**
|
2019-05-10 07:53:16 +01:00
|
|
|
* Implement @ref drgn_program_from_pid() on an initialized @ref drgn_program.
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_program_init_pid(struct drgn_program *prog, pid_t pid);
|
|
|
|
|
2020-08-25 02:01:25 +01:00
|
|
|
static inline struct drgn_error *
|
|
|
|
drgn_program_is_little_endian(struct drgn_program *prog, bool *ret)
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
{
|
2020-08-25 02:01:25 +01:00
|
|
|
if (!prog->has_platform) {
|
|
|
|
return drgn_error_create(DRGN_ERROR_INVALID_ARGUMENT,
|
|
|
|
"program byte order is not known");
|
|
|
|
}
|
|
|
|
*ret = prog->platform.flags & DRGN_PLATFORM_IS_LITTLE_ENDIAN;
|
|
|
|
return NULL;
|
2019-07-29 08:57:28 +01:00
|
|
|
}
|
|
|
|
|
2020-04-26 23:29:00 +01:00
|
|
|
/**
|
|
|
|
* Return whether a @ref drgn_program has a different endianness than the host
|
|
|
|
* system.
|
|
|
|
*/
|
2020-08-25 02:01:25 +01:00
|
|
|
static inline struct drgn_error *
|
|
|
|
drgn_program_bswap(struct drgn_program *prog, bool *ret)
|
2020-04-26 23:29:00 +01:00
|
|
|
{
|
2020-08-25 02:01:25 +01:00
|
|
|
bool is_little_endian;
|
|
|
|
struct drgn_error *err = drgn_program_is_little_endian(prog,
|
|
|
|
&is_little_endian);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
*ret = is_little_endian != (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__);
|
|
|
|
return NULL;
|
2020-04-26 23:29:00 +01:00
|
|
|
}
|
|
|
|
|
2020-08-25 02:01:25 +01:00
|
|
|
static inline struct drgn_error *
|
|
|
|
drgn_program_is_64_bit(struct drgn_program *prog, bool *ret)
|
2019-07-29 08:57:28 +01:00
|
|
|
{
|
2020-08-25 02:01:25 +01:00
|
|
|
if (!prog->has_platform) {
|
|
|
|
return drgn_error_create(DRGN_ERROR_INVALID_ARGUMENT,
|
|
|
|
"program word size is not known");
|
|
|
|
}
|
|
|
|
*ret = prog->platform.flags & DRGN_PLATFORM_IS_64_BIT;
|
|
|
|
return NULL;
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
}
|
|
|
|
|
2019-07-17 22:16:38 +01:00
|
|
|
struct drgn_error *drgn_program_get_dwfl(struct drgn_program *prog, Dwfl **ret);
|
|
|
|
|
2020-05-20 19:30:00 +01:00
|
|
|
/**
|
|
|
|
* Find the @c NT_PRSTATUS note for the given CPU.
|
|
|
|
*
|
|
|
|
* This is only valid for the Linux kernel.
|
|
|
|
*
|
|
|
|
* @param[out] ret Returned note data. If not found, <tt>ret->str</tt> is set to
|
|
|
|
* @c NULL and <tt>ret->len</tt> is set to zero.
|
2020-07-09 01:50:33 +01:00
|
|
|
* @param[out] tid_ret Returned thread ID of note.
|
2020-05-20 19:30:00 +01:00
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_program_find_prstatus_by_cpu(struct drgn_program *prog,
|
|
|
|
uint32_t cpu,
|
2020-07-09 01:50:33 +01:00
|
|
|
struct string *ret,
|
|
|
|
uint32_t *tid_ret);
|
2020-05-20 19:30:00 +01:00
|
|
|
|
2019-10-24 22:26:45 +01:00
|
|
|
/**
|
|
|
|
* Find the @c NT_PRSTATUS note for the given thread ID.
|
|
|
|
*
|
2020-05-20 19:30:00 +01:00
|
|
|
* This is only valid for userspace programs.
|
2019-10-24 22:26:45 +01:00
|
|
|
*
|
|
|
|
* @param[out] ret Returned note data. If not found, <tt>ret->str</tt> is set to
|
|
|
|
* @c NULL and <tt>ret->len</tt> is set to zero.
|
|
|
|
*/
|
2020-05-20 19:30:00 +01:00
|
|
|
struct drgn_error *drgn_program_find_prstatus_by_tid(struct drgn_program *prog,
|
|
|
|
uint32_t tid,
|
|
|
|
struct string *ret);
|
2019-10-24 22:26:45 +01:00
|
|
|
|
2020-02-11 22:54:09 +00:00
|
|
|
/**
|
|
|
|
* Cache the @c NT_PRSTATUS note provided by @p data in @p prog.
|
|
|
|
*
|
|
|
|
* @param[in] data The pointer to the note data.
|
|
|
|
* @param[in] size Size of data in note.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_program_cache_prstatus_entry(struct drgn_program *prog,
|
2020-07-09 01:50:33 +01:00
|
|
|
const char *data,
|
|
|
|
size_t size);
|
2020-02-11 22:54:09 +00:00
|
|
|
|
2019-07-25 08:47:13 +01:00
|
|
|
/*
|
2020-02-07 16:42:25 +00:00
|
|
|
* Like @ref drgn_program_find_symbol_by_address(), but @p ret is already
|
|
|
|
* allocated, we may already know the module, and doesn't return a @ref
|
|
|
|
* drgn_error.
|
2019-12-10 19:02:55 +00:00
|
|
|
*
|
|
|
|
* @param[in] module Module containing the address. May be @c NULL, in which
|
|
|
|
* case this will look it up.
|
|
|
|
* @return Whether the symbol was found.
|
2019-07-25 08:47:13 +01:00
|
|
|
*/
|
2020-02-07 16:42:25 +00:00
|
|
|
bool drgn_program_find_symbol_by_address_internal(struct drgn_program *prog,
|
|
|
|
uint64_t address,
|
|
|
|
Dwfl_Module *module,
|
|
|
|
struct drgn_symbol *ret);
|
2019-07-25 08:47:13 +01:00
|
|
|
|
Rewrite drgn core in C
The current mixed Python/C implementation works well, but it has a
couple of important limitations:
- It's too slow for some common use cases, like iterating over large
data structures.
- It can't be reused in utilities written in other languages.
This replaces the internals with a new library written in C, libdrgn. It
includes Python bindings with mostly the same public interface as
before, with some important improvements:
- Types are now represented by a single Type class rather than the messy
polymorphism in the Python implementation.
- Qualifiers are a bitmask instead of a set of strings.
- Bit fields are not considered a separate type.
- The lvalue/rvalue terminology is replaced with reference/value.
- Structure, union, and array values are better supported.
- Function objects are supported.
- Program distinguishes between lookups of variables, constants, and
functions.
The C rewrite is about 6x as fast as the original Python when using the
Python bindings, and about 8x when using the C API directly.
Currently, the exposed API in C is fairly conservative. In the future,
the memory reader, type index, and object index APIs will probably be
exposed for more flexibility.
2019-03-22 23:27:46 +00:00
|
|
|
/** @} */
|
|
|
|
|
|
|
|
#endif /* DRGN_PROGRAM_H */
|