2021-11-21 23:59:44 +00:00
|
|
|
// Copyright (c) Meta Platforms, Inc. and affiliates.
|
2022-11-02 00:05:16 +00:00
|
|
|
// SPDX-License-Identifier: LGPL-2.1-or-later
|
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
|
|
|
|
|
|
|
/**
|
|
|
|
* @file
|
|
|
|
*
|
|
|
|
* libdrgn public interface.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef DRGN_H
|
|
|
|
#define DRGN_H
|
|
|
|
|
2020-09-24 00:02:02 +01:00
|
|
|
// IWYU pragma: begin_exports
|
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 <stdbool.h>
|
|
|
|
#include <stddef.h>
|
|
|
|
#include <stdint.h>
|
2020-09-24 00:02:02 +01:00
|
|
|
// IWYU pragma: end_exports
|
|
|
|
|
|
|
|
#include <assert.h>
|
|
|
|
#include <limits.h>
|
2023-07-15 05:23:00 +01:00
|
|
|
#include <stdarg.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 <stdio.h>
|
2020-12-15 01:58:44 +00:00
|
|
|
#include <string.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 <sys/types.h>
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @mainpage
|
|
|
|
*
|
2023-07-16 06:36:01 +01:00
|
|
|
* libdrgn provides the functionality of the
|
|
|
|
* [drgn](https://github.com/osandov/drgn) programmable debugger as a library.
|
|
|
|
* It implements the main drgn abstractions: @ref Programs, @ref Types, @ref
|
|
|
|
* Objects, and @ref StackTraces. See [Modules](modules.html) for detailed
|
2022-08-19 09:21:32 +01:00
|
|
|
* documentation.
|
2023-07-16 06:36:01 +01:00
|
|
|
*
|
|
|
|
* @subsection ThreadSafety Thread Safety
|
|
|
|
*
|
|
|
|
* Only one thread at a time should access the same @ref drgn_program (including
|
|
|
|
* @ref drgn_object, @ref drgn_type, @ref drgn_stack_trace, etc. from that
|
|
|
|
* program). It is safe to use different @ref drgn_program%s from concurrent
|
|
|
|
* threads.
|
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
|
|
|
*/
|
|
|
|
|
|
|
|
/** Major version of drgn. */
|
2020-01-11 18:01:14 +00:00
|
|
|
#define DRGN_VERSION_MAJOR @DRGN_VERSION_MAJOR@
|
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
|
|
|
/** Minor version of drgn. */
|
2020-01-11 18:01:14 +00:00
|
|
|
#define DRGN_VERSION_MINOR @DRGN_VERSION_MINOR@
|
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
|
|
|
/** Patch level of drgn. */
|
2020-01-11 18:01:14 +00:00
|
|
|
#define DRGN_VERSION_PATCH @DRGN_VERSION_PATCH@
|
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
|
|
|
|
|
|
|
/**
|
|
|
|
* @defgroup ErrorHandling Error handling
|
|
|
|
*
|
|
|
|
* Error handling in libdrgn.
|
|
|
|
*
|
|
|
|
* Operations in libdrgn can fail for various reasons. libdrgn returns errors as
|
|
|
|
* @ref drgn_error.
|
|
|
|
*
|
|
|
|
* @{
|
|
|
|
*/
|
|
|
|
|
|
|
|
/** Error code for a @ref drgn_error. */
|
|
|
|
enum drgn_error_code {
|
|
|
|
/** Cannot allocate memory. */
|
|
|
|
DRGN_ERROR_NO_MEMORY,
|
|
|
|
/** Stop iteration. */
|
|
|
|
DRGN_ERROR_STOP,
|
|
|
|
/** Miscellaneous error. */
|
|
|
|
DRGN_ERROR_OTHER,
|
|
|
|
/** Invalid argument. */
|
|
|
|
DRGN_ERROR_INVALID_ARGUMENT,
|
|
|
|
/** Integer overflow. */
|
|
|
|
DRGN_ERROR_OVERFLOW,
|
|
|
|
/** Maximum recursion depth exceeded. */
|
|
|
|
DRGN_ERROR_RECURSION,
|
|
|
|
/** System call error. */
|
|
|
|
DRGN_ERROR_OS,
|
2019-05-10 07:53:16 +01:00
|
|
|
/** One or more files do not have debug information. */
|
|
|
|
DRGN_ERROR_MISSING_DEBUG_INFO,
|
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
|
|
|
/** Syntax error while parsing. */
|
|
|
|
DRGN_ERROR_SYNTAX,
|
|
|
|
/** Entry not found. */
|
|
|
|
DRGN_ERROR_LOOKUP,
|
|
|
|
/** Bad memory access. */
|
|
|
|
DRGN_ERROR_FAULT,
|
|
|
|
/** Type error in expression. */
|
|
|
|
DRGN_ERROR_TYPE,
|
|
|
|
/** Division by zero. */
|
|
|
|
DRGN_ERROR_ZERO_DIVISION,
|
2020-02-03 18:07:07 +00:00
|
|
|
/** Array out of bounds */
|
|
|
|
DRGN_ERROR_OUT_OF_BOUNDS,
|
2021-03-16 23:15:43 +00:00
|
|
|
/** Operation was attempted with absent object. */
|
2020-12-29 22:41:01 +00:00
|
|
|
DRGN_ERROR_OBJECT_ABSENT,
|
2022-04-28 00:55:52 +01:00
|
|
|
/** Functionality is not implemented. */
|
|
|
|
DRGN_ERROR_NOT_IMPLEMENTED,
|
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
|
|
|
/** Number of defined error codes. */
|
|
|
|
DRGN_NUM_ERROR_CODES,
|
2021-02-21 11:16:23 +00:00
|
|
|
} __attribute__((__packed__));
|
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
|
|
|
|
|
|
|
/**
|
|
|
|
* libdrgn error.
|
|
|
|
*
|
|
|
|
* All functions in libdrgn that can return an error return this type.
|
|
|
|
*/
|
|
|
|
struct drgn_error {
|
|
|
|
/** Error code. */
|
|
|
|
enum drgn_error_code code;
|
|
|
|
/**
|
|
|
|
* @private
|
|
|
|
*
|
|
|
|
* Whether this error needs to be passed to @ref drgn_error_destroy().
|
|
|
|
*
|
|
|
|
* This is @c true for the error codes returned from @ref
|
|
|
|
* drgn_error_create() and its related functions. Certain errors are
|
|
|
|
* statically allocated and do not need to be passed to @ref
|
|
|
|
* drgn_error_destroy() (but they can be).
|
|
|
|
*/
|
|
|
|
bool needs_destroy;
|
|
|
|
/**
|
|
|
|
* If @c code is @c DRGN_ERROR_OS, then the error number returned from
|
|
|
|
* the system call.
|
|
|
|
*/
|
|
|
|
int errnum;
|
2020-09-30 09:32:33 +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
|
|
|
* If @c code is @c DRGN_ERROR_OS, then the path of the file which
|
|
|
|
* encountered the error if applicable. Otherwise, @c NULL.
|
|
|
|
*/
|
|
|
|
char *path;
|
2020-09-30 09:32:33 +01:00
|
|
|
/**
|
2020-02-03 18:27:49 +00:00
|
|
|
* If @c code is @c DRGN_ERROR_FAULT, then the address of the read
|
|
|
|
* which encountered the error.
|
|
|
|
*/
|
|
|
|
uint64_t address;
|
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
|
|
|
/** Human-readable error message. */
|
|
|
|
char *message;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Out of memory @ref drgn_error.
|
|
|
|
*
|
|
|
|
* This has a code of @ref DRGN_ERROR_NO_MEMORY. It can be returned if a memory
|
|
|
|
* allocation fails in order to avoid doing another memory allocation. It does
|
2019-07-23 01:23:27 +01:00
|
|
|
* not need to be passed to @ref drgn_error_destroy() (but it can be).
|
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
|
|
|
*/
|
|
|
|
extern struct drgn_error drgn_enomem;
|
|
|
|
|
2019-07-23 23:32:26 +01:00
|
|
|
/**
|
|
|
|
* Non-fatal lookup @ref drgn_error.
|
|
|
|
*
|
2021-03-05 20:46:06 +00:00
|
|
|
* This has a code of @ref DRGN_ERROR_LOOKUP. It does not need to be passed to
|
|
|
|
* @ref drgn_error_destroy() (but it can be).
|
2019-07-23 23:32:26 +01:00
|
|
|
*/
|
|
|
|
extern struct drgn_error drgn_not_found;
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Create a @ref drgn_error.
|
|
|
|
*
|
|
|
|
* @param[in] code Error code.
|
|
|
|
* @param[in] message Human-readable error message. This string is copied.
|
|
|
|
* @return A new error with the given code and message. If there is a failure to
|
|
|
|
* allocate memory for the error or the message, @ref drgn_enomem is returned
|
|
|
|
* instead.
|
|
|
|
*/
|
2019-05-14 18:13:05 +01:00
|
|
|
struct drgn_error *drgn_error_create(enum drgn_error_code code,
|
|
|
|
const char *message)
|
2021-02-21 11:16:23 +00:00
|
|
|
__attribute__((__returns_nonnull__));
|
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
|
|
|
|
|
|
|
/**
|
|
|
|
* Create a @ref drgn_error from a printf-style format.
|
|
|
|
*
|
|
|
|
* @param[in] code Error code.
|
|
|
|
* @param[in] format printf-style format string.
|
|
|
|
* @param[in] ... Arguments for the format string.
|
|
|
|
* @return A new error with the given code and formatted message. If there is a
|
|
|
|
* failure to allocate memory for the error or the message, @ref drgn_enomem is
|
|
|
|
* returned instead.
|
|
|
|
*/
|
2019-05-14 18:13:05 +01:00
|
|
|
struct drgn_error *drgn_error_format(enum drgn_error_code code,
|
|
|
|
const char *format, ...)
|
2021-02-21 11:16:23 +00:00
|
|
|
__attribute__((__returns_nonnull__, __format__(__printf__, 2, 3)));
|
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
|
|
|
|
|
|
|
/**
|
|
|
|
* Create a @ref DRGN_ERROR_OS @ref drgn_error.
|
|
|
|
*
|
|
|
|
* @sa drgn_error_create().
|
|
|
|
*
|
|
|
|
* @param[in] errnum Error number (i.e., @c errno).
|
|
|
|
* @param[in] path If not @c NULL, the path of the file which encountered the
|
|
|
|
* error. This string is copied.
|
|
|
|
*/
|
2019-07-11 23:58:23 +01:00
|
|
|
struct drgn_error *drgn_error_create_os(const char *message, int errnum,
|
|
|
|
const char *path)
|
2021-02-21 11:16:23 +00:00
|
|
|
__attribute__((__returns_nonnull__));
|
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-12 00:16:11 +01:00
|
|
|
/**
|
|
|
|
* Create a @ref DRGN_ERROR_OS @ref drgn_error with a printf-style formatted
|
|
|
|
* path.
|
|
|
|
*
|
|
|
|
* @param[in] errnum Error number (i.e., @c errno).
|
|
|
|
* @param[in] path_format printf-style format string for path.
|
|
|
|
* @param[in] ... Arguments for the format string.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_error_format_os(const char *message, int errnum,
|
|
|
|
const char *path_format, ...)
|
2021-02-21 11:16:23 +00:00
|
|
|
__attribute__((__returns_nonnull__, __format__(__printf__, 3, 4)));
|
2019-07-12 00:16:11 +01:00
|
|
|
|
2020-02-03 18:27:49 +00:00
|
|
|
/**
|
|
|
|
* Create a @ref DRGN_ERROR_FAULT @ref drgn_error.
|
|
|
|
*
|
|
|
|
* @param[in] message Human-readable error message. This string is copied.
|
|
|
|
* @param[in] address Address where the fault happened.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_error_create_fault(const char *message, uint64_t address)
|
2021-02-21 11:16:23 +00:00
|
|
|
__attribute__((__returns_nonnull__));
|
2020-02-03 18:27:49 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
*
|
|
|
|
* Create a @ref DRGN_ERROR_FAULT @ref drgn_error with a printf-style formatted
|
|
|
|
* message.
|
|
|
|
*
|
|
|
|
* @param[in] address Address where the fault happened.
|
|
|
|
* @param[in] format printf-style format string for message.
|
|
|
|
* @param[in] ... Arguments for the format string.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_error_format_fault(uint64_t address,
|
|
|
|
const char *format, ...)
|
2021-02-21 11:16:23 +00:00
|
|
|
__attribute__((__returns_nonnull__, __format__(__printf__, 2, 3)));
|
2020-02-03 18:27:49 +00:00
|
|
|
|
2020-08-28 19:29:27 +01:00
|
|
|
/*
|
|
|
|
* Create a copy of a @ref drgn_error.
|
|
|
|
*
|
|
|
|
* The source's error message and path are copied if necessary, so the source
|
|
|
|
* error can be destroyed without affecting the new error and vice versa.
|
|
|
|
*
|
|
|
|
* @param[in] src Error to copy.
|
|
|
|
* @return A new error with the same fields. If there is a failure to allocate
|
|
|
|
* memory, @ref drgn_enomem is returned instead.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_error_copy(struct drgn_error *src)
|
2021-02-21 11:16:23 +00:00
|
|
|
__attribute__((__returns_nonnull__));
|
2020-08-28 19:29:27 +01:00
|
|
|
|
2023-07-15 05:23:00 +01:00
|
|
|
/**
|
|
|
|
* Return a string representation of a @ref drgn_error.
|
|
|
|
*
|
|
|
|
* @param[in] err Error to write.
|
|
|
|
* @return Returned string, or @c NULL if memory could not be allocated. On
|
|
|
|
* success, must be freed with @c free().
|
|
|
|
*/
|
|
|
|
char *drgn_error_string(struct drgn_error *err);
|
|
|
|
|
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
|
|
|
/**
|
2022-05-23 18:48:42 +01:00
|
|
|
* Write a @ref drgn_error followed by a newline to a @c stdio stream.
|
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
|
|
|
*
|
|
|
|
* @param[in] file File to write to (usually @c stderr).
|
|
|
|
* @param[in] err Error to write.
|
2022-05-23 18:48:42 +01:00
|
|
|
* @return Non-negative on success, negative on failure.
|
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-14 18:24:12 +01:00
|
|
|
int drgn_error_fwrite(FILE *file, struct drgn_error *err);
|
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
|
|
|
|
2022-05-23 19:08:08 +01:00
|
|
|
/**
|
|
|
|
* Write a @ref drgn_error followed by a newline to a file descriptor.
|
|
|
|
*
|
|
|
|
* @param[in] fd File descriptor to write to.
|
|
|
|
* @param[in] err Error to write.
|
|
|
|
* @return Non-negative on success, negative on failure.
|
|
|
|
*/
|
|
|
|
int drgn_error_dwrite(int fd, struct drgn_error *err);
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Free a @ref drgn_error.
|
|
|
|
*
|
|
|
|
* This must be called on any error returned from libdrgn unless otherwise
|
|
|
|
* noted.
|
|
|
|
*
|
|
|
|
* @param[in] err Error to destroy. If @c NULL, this is a no-op.
|
|
|
|
*/
|
|
|
|
void drgn_error_destroy(struct drgn_error *err);
|
|
|
|
|
|
|
|
/** @} */
|
|
|
|
|
2022-02-16 21:05:28 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @defgroup Languages Languages
|
|
|
|
*
|
|
|
|
* Programming languages.
|
|
|
|
*
|
|
|
|
* @{
|
|
|
|
*/
|
|
|
|
|
2023-05-23 22:45:03 +01:00
|
|
|
struct drgn_language; // IWYU pragma: export
|
|
|
|
|
2022-02-16 21:05:28 +00:00
|
|
|
/** C */
|
|
|
|
extern const struct drgn_language drgn_language_c;
|
|
|
|
/** C++ */
|
|
|
|
extern const struct drgn_language drgn_language_cpp;
|
|
|
|
|
|
|
|
/** Get the name of a @ref drgn_language. */
|
|
|
|
const char *drgn_language_name(const struct drgn_language *lang);
|
|
|
|
|
|
|
|
/** @} */
|
|
|
|
|
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 Types
|
|
|
|
*
|
|
|
|
* Kinds of types.
|
|
|
|
*
|
|
|
|
* Every type in a program supported by libdrgn falls into one of these
|
|
|
|
* categories.
|
|
|
|
*/
|
|
|
|
enum drgn_type_kind {
|
|
|
|
/** Void type. */
|
|
|
|
DRGN_TYPE_VOID = 1,
|
|
|
|
/** Integer type. */
|
|
|
|
DRGN_TYPE_INT,
|
|
|
|
/** Boolean type. */
|
|
|
|
DRGN_TYPE_BOOL,
|
|
|
|
/** Floating-point type. */
|
|
|
|
DRGN_TYPE_FLOAT,
|
|
|
|
/** Structure type. */
|
|
|
|
DRGN_TYPE_STRUCT,
|
|
|
|
/** Union type. */
|
|
|
|
DRGN_TYPE_UNION,
|
2019-11-15 01:12:47 +00:00
|
|
|
/** Class type. */
|
|
|
|
DRGN_TYPE_CLASS,
|
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
|
|
|
/** Enumerated type. */
|
|
|
|
DRGN_TYPE_ENUM,
|
|
|
|
/** Type definition (a.k.a.\ alias) type. */
|
|
|
|
DRGN_TYPE_TYPEDEF,
|
|
|
|
/** Pointer type. */
|
|
|
|
DRGN_TYPE_POINTER,
|
|
|
|
/** Array type. */
|
|
|
|
DRGN_TYPE_ARRAY,
|
|
|
|
/** Function type. */
|
|
|
|
DRGN_TYPE_FUNCTION,
|
2021-02-21 11:16:23 +00:00
|
|
|
} __attribute__((__packed__));
|
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-12-18 20:20:21 +00:00
|
|
|
* @ingroup Types
|
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-12-18 20:20:21 +00:00
|
|
|
* Type qualifiers.
|
|
|
|
*
|
|
|
|
* Some languages, like C, have the notion of qualifiers which add properties to
|
|
|
|
* a type. Qualifiers are represented as a bitmask; each qualifier is a bit.
|
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-12-18 20:20:21 +00:00
|
|
|
enum drgn_qualifiers {
|
|
|
|
/** Constant type. */
|
|
|
|
DRGN_QUALIFIER_CONST = (1 << 0),
|
|
|
|
/** Volatile type. */
|
|
|
|
DRGN_QUALIFIER_VOLATILE = (1 << 1),
|
|
|
|
/** Restrict type. */
|
|
|
|
DRGN_QUALIFIER_RESTRICT = (1 << 2),
|
|
|
|
/** Atomic type. */
|
|
|
|
DRGN_QUALIFIER_ATOMIC = (1 << 3),
|
|
|
|
/** Bitmask of all valid qualifiers. */
|
|
|
|
DRGN_ALL_QUALIFIERS = (1 << 4) - 1,
|
2021-02-21 11:16:23 +00:00
|
|
|
} __attribute__((__packed__));
|
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-12-18 20:20:21 +00:00
|
|
|
* @ingroup Types
|
|
|
|
*
|
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
|
|
|
* Qualified type.
|
|
|
|
*
|
|
|
|
* A type with qualifiers.
|
|
|
|
*
|
|
|
|
* @sa drgn_qualifiers
|
|
|
|
*/
|
|
|
|
struct drgn_qualified_type {
|
|
|
|
/** Unqualified type. */
|
|
|
|
struct drgn_type *type;
|
|
|
|
/** Bitmask of qualifiers on this type. */
|
|
|
|
enum drgn_qualifiers qualifiers;
|
|
|
|
};
|
|
|
|
|
2020-12-18 20:20:21 +00:00
|
|
|
static inline struct drgn_program *
|
|
|
|
drgn_type_program(struct drgn_type *type);
|
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-12-18 20:20:21 +00:00
|
|
|
static inline const struct drgn_language *
|
|
|
|
drgn_type_language(struct drgn_type *type);
|
2019-04-20 00:05:19 +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
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* @defgroup Platforms Platforms
|
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-12-18 20:20:21 +00:00
|
|
|
* Program platforms (i.e., architecture and ABI).
|
|
|
|
*
|
|
|
|
* @{
|
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-12-18 20:20:21 +00:00
|
|
|
/** An instruction set architecture. */
|
|
|
|
enum drgn_architecture {
|
|
|
|
DRGN_ARCH_UNKNOWN,
|
|
|
|
DRGN_ARCH_X86_64,
|
2021-12-03 01:12:25 +00:00
|
|
|
DRGN_ARCH_I386,
|
2021-12-02 11:13:51 +00:00
|
|
|
DRGN_ARCH_AARCH64,
|
2021-12-03 06:21:31 +00:00
|
|
|
DRGN_ARCH_ARM,
|
2020-11-27 12:06:56 +00:00
|
|
|
DRGN_ARCH_PPC64,
|
2021-12-03 09:56:19 +00:00
|
|
|
DRGN_ARCH_RISCV64,
|
|
|
|
DRGN_ARCH_RISCV32,
|
2021-12-03 10:57:34 +00:00
|
|
|
DRGN_ARCH_S390X,
|
|
|
|
DRGN_ARCH_S390,
|
2020-12-18 20:20:21 +00:00
|
|
|
};
|
Associate types with program
I originally envisioned types as dumb descriptors. This mostly works for
C because in C, types are fairly simple. However, even then the
drgn_program_member_info() API is awkward. You should be able to look up
a member directly from a type, but we need the program for caching
purposes. This has also held me back from adding offsetof() or
has_member() APIs.
Things get even messier with C++. C++ template parameters can be objects
(e.g., template <int N>). Such parameters would best be represented by a
drgn object, which we need a drgn program for. Static members are a
similar case.
So, let's reimagine types as being owned by a program. This has a few
parts:
1. In libdrgn, simple types are now created by factory functions,
drgn_foo_type_create().
2. To handle their variable length fields, compound types, enum types,
and function types are constructed with a "builder" API.
3. Simple types are deduplicated.
4. The Python type factory functions are replaced by methods of the
Program class.
5. While we're changing the API, the parameters to pointer_type() and
array_type() are reordered to be more logical (and to allow
pointer_type() to take a default size of None for the program's
default pointer size).
6. Likewise, the type factory methods take qualifiers as a keyword
argument only.
A big part of this change is updating the tests and splitting up large
test cases into smaller ones in a few places.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2020-07-16 00:34:56 +01:00
|
|
|
|
2020-12-18 20:20:21 +00:00
|
|
|
/** Flags describing a @ref drgn_platform. */
|
|
|
|
enum drgn_platform_flags {
|
|
|
|
/** Platform is 64-bit. */
|
|
|
|
DRGN_PLATFORM_IS_64_BIT = (1 << 0),
|
|
|
|
/** Platform is little-endian. */
|
|
|
|
DRGN_PLATFORM_IS_LITTLE_ENDIAN = (1 << 1),
|
|
|
|
/** All valid platform flags. */
|
|
|
|
DRGN_ALL_PLATFORM_FLAGS = (1 << 2) - 1,
|
|
|
|
/** Use the default flags for the architecture. */
|
|
|
|
DRGN_PLATFORM_DEFAULT_FLAGS = UINT_MAX,
|
|
|
|
};
|
|
|
|
|
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-12-18 20:20:21 +00:00
|
|
|
* @struct drgn_platform
|
|
|
|
*
|
|
|
|
* The environment that a program runs on.
|
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
|
|
|
*/
|
2023-05-23 22:45:03 +01:00
|
|
|
struct drgn_platform; // IWYU pragma: export
|
2020-12-18 20:20:21 +00: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
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* @struct drgn_register
|
|
|
|
*
|
|
|
|
* A processor register.
|
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
|
|
|
*/
|
2023-05-23 22:45:03 +01:00
|
|
|
struct drgn_register; // IWYU pragma: export
|
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-12-18 20:20:21 +00:00
|
|
|
* Create a @ref drgn_platform.
|
|
|
|
*
|
|
|
|
* The returned platform should be destroyed with @ref drgn_platform_destroy().
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_platform_create(enum drgn_architecture arch,
|
|
|
|
enum drgn_platform_flags flags,
|
|
|
|
struct drgn_platform **ret);
|
|
|
|
|
|
|
|
/** Destroy a @ref drgn_platform. */
|
|
|
|
void drgn_platform_destroy(struct drgn_platform *platform);
|
|
|
|
|
|
|
|
/** Get the instruction set architecture of a @ref drgn_platform. */
|
|
|
|
enum drgn_architecture drgn_platform_arch(const struct drgn_platform *platform);
|
|
|
|
|
|
|
|
/** Get the flags of a @ref drgn_platform. */
|
|
|
|
enum drgn_platform_flags
|
|
|
|
drgn_platform_flags(const struct drgn_platform *platform);
|
|
|
|
|
2021-01-28 23:49:21 +00:00
|
|
|
/** Get the number of @ref drgn_register's on a @ref drgn_platform. */
|
2020-12-18 20:20:21 +00:00
|
|
|
size_t drgn_platform_num_registers(const struct drgn_platform *platform);
|
|
|
|
|
2021-01-28 23:49:21 +00:00
|
|
|
/** Get the @p n-th @ref drgn_register of a @ref drgn_platform. */
|
2020-12-18 20:20:21 +00:00
|
|
|
const struct drgn_register *
|
|
|
|
drgn_platform_register(const struct drgn_platform *platform, size_t n);
|
|
|
|
|
2021-01-28 23:49:21 +00:00
|
|
|
/** Get a @ref drgn_register in a @ref drgn_platform by its name. */
|
|
|
|
const struct drgn_register *
|
|
|
|
drgn_platform_register_by_name(const struct drgn_platform *platform,
|
|
|
|
const char *name);
|
|
|
|
|
2020-12-18 20:20:21 +00:00
|
|
|
/** Return whether two platforms are identical. */
|
|
|
|
bool drgn_platform_eq(struct drgn_platform *a, struct drgn_platform *b);
|
|
|
|
|
|
|
|
/** Platform that drgn was compiled for. */
|
|
|
|
extern const struct drgn_platform drgn_host_platform;
|
|
|
|
|
2021-01-28 23:49:21 +00:00
|
|
|
/**
|
|
|
|
* Get the names of a @ref drgn_register.
|
|
|
|
*
|
|
|
|
* @param[out] num_names_ret Returned number of names.
|
|
|
|
* @return Array of names.
|
|
|
|
*/
|
|
|
|
const char * const *drgn_register_names(const struct drgn_register *reg,
|
|
|
|
size_t *num_names_ret);
|
2020-12-18 20:20:21 +00:00
|
|
|
|
|
|
|
/** @} */
|
|
|
|
|
|
|
|
struct drgn_object;
|
2021-11-19 00:46:59 +00:00
|
|
|
struct drgn_thread;
|
2020-12-18 20:20:21 +00: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
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* @defgroup Programs Programs
|
|
|
|
*
|
|
|
|
* Debugging programs.
|
|
|
|
*
|
|
|
|
* A program being debugged is represented by a @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
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* @struct drgn_program
|
|
|
|
*
|
|
|
|
* Program being debugged.
|
|
|
|
*
|
|
|
|
* A @ref drgn_program represents a crashed or running program. It supports
|
|
|
|
* looking up objects (@ref drgn_program_find_object()) and types (@ref
|
|
|
|
* drgn_program_find_type()) by name and reading arbitrary memory from the
|
|
|
|
* program (@ref drgn_program_read_memory()).
|
|
|
|
*
|
|
|
|
* A @ref drgn_program is created with @ref drgn_program_from_core_dump(), @ref
|
|
|
|
* drgn_program_from_kernel(), or @ref drgn_program_from_pid(). It must be freed
|
|
|
|
* with @ref drgn_program_destroy().
|
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
|
|
|
*/
|
2023-05-23 22:45:03 +01:00
|
|
|
struct drgn_program; // IWYU pragma: export
|
2020-12-18 20:20:21 +00:00
|
|
|
|
|
|
|
/** Flags which apply to a @ref drgn_program. */
|
|
|
|
enum drgn_program_flags {
|
|
|
|
/** The program is the Linux kernel. */
|
|
|
|
DRGN_PROGRAM_IS_LINUX_KERNEL = (1 << 0),
|
|
|
|
/** The program is currently running. */
|
|
|
|
DRGN_PROGRAM_IS_LIVE = (1 << 1),
|
|
|
|
};
|
|
|
|
|
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-12-18 20:20:21 +00:00
|
|
|
* Create a @ref drgn_program.
|
|
|
|
*
|
|
|
|
* Usually, @ref drgn_program_from_core_dump(), @ref drgn_program_from_kernel(),
|
|
|
|
* and @ref drgn_program_from_pid() are more convenient to use. However, this
|
|
|
|
* can be used if more flexibility is required.
|
|
|
|
*
|
|
|
|
* @param[in] platform Platform that this program runs on, or @c NULL if it
|
|
|
|
* should be determined automatically. This is copied.
|
|
|
|
* @param[out] ret Returned program.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_program_create(const struct drgn_platform *platform,
|
|
|
|
struct drgn_program **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-12-18 20:20:21 +00:00
|
|
|
* Free a @ref drgn_program.
|
|
|
|
*
|
|
|
|
* @param[in] prog Program to free.
|
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-12-18 20:20:21 +00:00
|
|
|
void drgn_program_destroy(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
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Callback implementing a memory read.
|
|
|
|
*
|
|
|
|
* @param[out] buf Buffer to read into.
|
|
|
|
* @param[in] address Address which we are reading from.
|
|
|
|
* @param[in] count Number of bytes to read.
|
|
|
|
* @param[in] offset Offset in bytes of @p address from the beginning of the
|
|
|
|
* segment.
|
|
|
|
* @param[in] arg Argument passed to @ref drgn_program_add_memory_segment().
|
|
|
|
* @param[in] physical Whether @c address is physical.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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-12-18 20:20:21 +00:00
|
|
|
typedef struct drgn_error *(*drgn_memory_read_fn)(void *buf, uint64_t address,
|
|
|
|
size_t count, uint64_t offset,
|
|
|
|
void *arg, bool physical);
|
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-12-18 20:20:21 +00:00
|
|
|
* Register a segment of memory in a @ref drgn_program.
|
|
|
|
*
|
|
|
|
* If the segment overlaps a previously registered segment, the new segment
|
2021-06-04 01:43:27 +01:00
|
|
|
* takes precedence. If any part of the segment is beyond the maximum address,
|
|
|
|
* that part is ignored.
|
2020-12-18 20:20:21 +00:00
|
|
|
*
|
|
|
|
* @param[in] address Address of the segment.
|
|
|
|
* @param[in] size Size of the segment in bytes.
|
|
|
|
* @param[in] read_fn Callback to read from segment.
|
|
|
|
* @param[in] arg Argument to pass to @p read_fn.
|
|
|
|
* @param[in] physical Whether to add a physical memory segment.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *
|
|
|
|
drgn_program_add_memory_segment(struct drgn_program *prog, uint64_t address,
|
|
|
|
uint64_t size, drgn_memory_read_fn read_fn,
|
|
|
|
void *arg, bool physical);
|
|
|
|
|
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-12-18 20:20:21 +00:00
|
|
|
* Return whether a filename containing a definition (@p haystack) matches a
|
|
|
|
* filename being searched for (@p needle).
|
|
|
|
*
|
|
|
|
* The path is matched from right to left, so a definition in
|
|
|
|
* <tt>/usr/include/stdio.h</tt> will match <tt>stdio.h</tt>,
|
|
|
|
* <tt>include/stdio.h</tt>, <tt>usr/include/stdio.h</tt>, and
|
|
|
|
* <tt>/usr/include/stdio.h</tt>. An empty or @c NULL @p needle matches any @p
|
|
|
|
* haystack.
|
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-12-18 20:20:21 +00:00
|
|
|
bool drgn_filename_matches(const char *haystack, const char *needle);
|
|
|
|
|
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-12-18 20:20:21 +00:00
|
|
|
* Callback for finding a type.
|
|
|
|
*
|
2023-08-21 21:26:28 +01:00
|
|
|
* @param[in] kinds Kinds of types to find, as a bitmask of bits shifted by @ref
|
|
|
|
* drgn_type_kind. E.g., `(1 << DRGN_TYPE_STRUCT) | (1 << DRGN_TYPE_CLASS)`
|
|
|
|
* means to find a structure or class type.
|
2020-12-18 20:20:21 +00:00
|
|
|
* @param[in] name Name of type (or tag, for structs, unions, and enums). This
|
|
|
|
* is @em not null-terminated.
|
|
|
|
* @param[in] name_len Length of @p name.
|
|
|
|
* @param[in] filename Filename containing the type definition or @c NULL. This
|
|
|
|
* should be matched with @ref drgn_filename_matches().
|
|
|
|
* @param[in] arg Argument passed to @ref drgn_program_add_type_finder().
|
|
|
|
* @param[out] ret Returned type.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error. In particular, if the type
|
|
|
|
* is not found, this should return &@ref drgn_not_found; any other errors are
|
|
|
|
* considered fatal.
|
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-12-18 20:20:21 +00:00
|
|
|
typedef struct drgn_error *
|
2023-08-21 21:26:28 +01:00
|
|
|
(*drgn_type_find_fn)(uint64_t kinds, const char *name, size_t name_len,
|
|
|
|
const char *filename, void *arg,
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_qualified_type *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-12-18 20:20:21 +00:00
|
|
|
* Register a type finding callback.
|
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-12-18 20:20:21 +00:00
|
|
|
* Callbacks are called in reverse order of the order they were added until the
|
|
|
|
* type is found. So, more recently added callbacks take precedence.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[in] fn The callback.
|
|
|
|
* @param[in] arg Argument to pass to @p fn.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *
|
|
|
|
drgn_program_add_type_finder(struct drgn_program *prog, drgn_type_find_fn fn,
|
|
|
|
void *arg);
|
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-12-18 20:20:21 +00:00
|
|
|
/** Flags for @ref drgn_program_find_object(). */
|
|
|
|
enum drgn_find_object_flags {
|
|
|
|
/** Find a constant (e.g., enumeration constant or macro). */
|
|
|
|
DRGN_FIND_OBJECT_CONSTANT = 1 << 0,
|
|
|
|
/** Find a function. */
|
|
|
|
DRGN_FIND_OBJECT_FUNCTION = 1 << 1,
|
|
|
|
/** Find a variable. */
|
|
|
|
DRGN_FIND_OBJECT_VARIABLE = 1 << 2,
|
|
|
|
/** Find any kind of object. */
|
|
|
|
DRGN_FIND_OBJECT_ANY = (1 << 3) - 1,
|
|
|
|
};
|
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-12-18 20:20:21 +00:00
|
|
|
* Callback for finding an object.
|
|
|
|
*
|
|
|
|
* @param[in] name Name of object. This is @em not null-terminated.
|
|
|
|
* @param[in] name_len Length of @p name.
|
|
|
|
* @param[in] filename Filename containing the object definition or @c NULL.
|
|
|
|
* This should be matched with @ref drgn_filename_matches().
|
|
|
|
* @param[in] flags Flags indicating what kind of object to look for.
|
|
|
|
* @param[in] arg Argument passed to @ref drgn_program_add_object_finder().
|
|
|
|
* @param[out] ret Returned object. This must only be modified on success.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error. In particular, if the
|
|
|
|
* object is not found, this should return &@ref drgn_not_found; any other
|
|
|
|
* errors are considered fatal.
|
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-12-18 20:20:21 +00:00
|
|
|
typedef struct drgn_error *
|
|
|
|
(*drgn_object_find_fn)(const char *name, size_t name_len, const char *filename,
|
|
|
|
enum drgn_find_object_flags flags, void *arg,
|
|
|
|
struct drgn_object *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-12-18 20:20:21 +00:00
|
|
|
* Register a object finding callback.
|
|
|
|
*
|
|
|
|
* Callbacks are called in reverse order of the order they were added until the
|
|
|
|
* object is found. So, more recently added callbacks take precedence.
|
|
|
|
*
|
|
|
|
* @param[in] fn The callback.
|
|
|
|
* @param[in] arg Argument to pass to @p fn.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *
|
|
|
|
drgn_program_add_object_finder(struct drgn_program *prog,
|
|
|
|
drgn_object_find_fn fn, void *arg);
|
|
|
|
|
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-12-18 20:20:21 +00:00
|
|
|
* Set a @ref drgn_program to a core dump.
|
|
|
|
*
|
|
|
|
* @sa drgn_program_from_core_dump()
|
|
|
|
*
|
|
|
|
* @param[in] path Core dump file path.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_program_set_core_dump(struct drgn_program *prog,
|
|
|
|
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
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Set a @ref drgn_program to the running operating system kernel.
|
|
|
|
*
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_program_set_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
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Set a @ref drgn_program to a running process.
|
|
|
|
*
|
|
|
|
* @sa drgn_program_from_pid()
|
|
|
|
*
|
|
|
|
* @param[in] pid Process ID.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_program_set_pid(struct drgn_program *prog, pid_t pid);
|
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-12-18 20:20:21 +00:00
|
|
|
* Load debugging information for a list of executable or library files.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[in] load_default Whether to also load debugging information which can
|
|
|
|
* automatically be determined from the program. This implies @p load_main.
|
|
|
|
* @param[in] load_main Whether to also load information for the main
|
|
|
|
* executable.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_program_load_debug_info(struct drgn_program *prog,
|
|
|
|
const char **paths, size_t n,
|
|
|
|
bool load_default,
|
|
|
|
bool load_main);
|
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-12-18 20:20:21 +00:00
|
|
|
* Create a @ref drgn_program from a core dump file.
|
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-12-18 20:20:21 +00:00
|
|
|
* The type of program (e.g., userspace or kernel) is determined automatically.
|
|
|
|
*
|
|
|
|
* @param[in] path Core dump file path.
|
|
|
|
* @param[out] ret Returned 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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_program_from_core_dump(const char *path,
|
|
|
|
struct drgn_program **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-12-18 20:20:21 +00:00
|
|
|
* Create a @ref drgn_program from the running operating system kernel.
|
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-12-18 20:20:21 +00:00
|
|
|
* This requires root privileges.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[out] ret Returned 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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_program_from_kernel(struct drgn_program **ret);
|
2020-12-16 00:35:18 +00:00
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Create a @ref drgn_program from the a running program.
|
2020-12-16 00:35:18 +00:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* On Linux, this requires @c PTRACE_MODE_ATTACH_FSCREDS permissions (see
|
|
|
|
* <tt>ptrace(2)</tt>).
|
2020-12-16 00:35:18 +00:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* @param[in] pid Process ID of the program to debug.
|
|
|
|
* @param[out] ret Returned program.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
2020-12-16 00:35:18 +00:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_program_from_pid(pid_t pid, struct drgn_program **ret);
|
|
|
|
|
|
|
|
/** Get the set of @ref drgn_program_flags applying to a @ref drgn_program. */
|
|
|
|
enum drgn_program_flags drgn_program_flags(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
|
|
|
|
2020-12-15 01:58:44 +00:00
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Get the platform of a @ref drgn_program.
|
2020-12-15 01:58:44 +00:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* This remains valid until the program is destroyed. It should @em not be
|
|
|
|
* destroyed with @ref drgn_platform_destroy().
|
|
|
|
* @return non-@c NULL on success, @c NULL if the platform is not known yet.
|
2020-12-15 01:58:44 +00:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
const struct drgn_platform *drgn_program_platform(struct drgn_program *prog);
|
2020-12-15 01:58:44 +00:00
|
|
|
|
2020-12-18 20:20:21 +00:00
|
|
|
/** Get the default language of a @ref drgn_program. */
|
|
|
|
const struct drgn_language *drgn_program_language(struct drgn_program *prog);
|
2020-12-15 23:51:11 +00:00
|
|
|
|
2022-02-16 21:22:41 +00:00
|
|
|
/** Set the default language of a @ref drgn_program. */
|
|
|
|
void drgn_program_set_language(struct drgn_program *prog,
|
|
|
|
const struct drgn_language *lang);
|
|
|
|
|
2020-12-15 23:51:11 +00:00
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Read from a program's memory.
|
2020-12-15 23:51:11 +00:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* @param[in] prog Program to read from.
|
|
|
|
* @param[out] buf Buffer to read into.
|
|
|
|
* @param[in] address Starting address in memory to read.
|
|
|
|
* @param[in] count Number of bytes to read.
|
|
|
|
* @param[in] physical Whether @c address is physical. A program may support
|
|
|
|
* only virtual or physical addresses or both.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
2020-12-15 23:51:11 +00:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_program_read_memory(struct drgn_program *prog,
|
|
|
|
void *buf, uint64_t address,
|
|
|
|
size_t count, bool physical);
|
2020-12-15 23:51:11 +00: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
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Read a C string from a program's memory.
|
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-12-18 20:20:21 +00:00
|
|
|
* This reads up to and including the terminating null byte.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[in] prog Program to read from.
|
|
|
|
* @param[in] address Starting address in memory to read.
|
|
|
|
* @param[in] physical Whether @c address is physical. See @ref
|
|
|
|
* drgn_program_read_memory().
|
|
|
|
* @param[in] max_size Stop after this many bytes are read, not including the
|
|
|
|
* null byte. A null byte is appended to @p ret in this case.
|
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
|
|
|
* @param[out] ret Returned string. On success, it must be freed with @c free().
|
|
|
|
* On error, its contents are undefined.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_program_read_c_string(struct drgn_program *prog,
|
|
|
|
uint64_t address, bool physical,
|
|
|
|
size_t max_size, char **ret);
|
|
|
|
|
|
|
|
struct drgn_error *drgn_program_read_u8(struct drgn_program *prog,
|
|
|
|
uint64_t address, bool physical,
|
|
|
|
uint8_t *ret);
|
|
|
|
|
|
|
|
struct drgn_error *drgn_program_read_u16(struct drgn_program *prog,
|
|
|
|
uint64_t address, bool physical,
|
|
|
|
uint16_t *ret);
|
|
|
|
|
|
|
|
struct drgn_error *drgn_program_read_u32(struct drgn_program *prog,
|
|
|
|
uint64_t address, bool physical,
|
|
|
|
uint32_t *ret);
|
|
|
|
|
|
|
|
struct drgn_error *drgn_program_read_u64(struct drgn_program *prog,
|
|
|
|
uint64_t address, bool physical,
|
|
|
|
uint64_t *ret);
|
|
|
|
|
|
|
|
struct drgn_error *drgn_program_read_word(struct drgn_program *prog,
|
|
|
|
uint64_t address, bool physical,
|
|
|
|
uint64_t *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-12-18 20:20:21 +00:00
|
|
|
* Find a type in a program by name.
|
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-12-18 20:20:21 +00:00
|
|
|
* The returned type is valid for the lifetime of the @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
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* @param[in] prog Program.
|
|
|
|
* @param[in] name Name of the type.
|
|
|
|
* @param[in] filename Filename containing the type definition. This is matched
|
|
|
|
* with @ref drgn_filename_matches(). If multiple definitions match, one is
|
|
|
|
* returned arbitrarily.
|
|
|
|
* @param[out] ret Returned type.
|
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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_program_find_type(struct drgn_program *prog,
|
|
|
|
const char *name,
|
|
|
|
const char *filename,
|
|
|
|
struct drgn_qualified_type *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
|
|
|
|
2019-07-29 08:57:28 +01:00
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Find an object in a program by name.
|
2019-07-29 08:57:28 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* The object can be a variable, constant, or function depending on @p flags.
|
2019-07-29 08:57:28 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* @param[in] prog Program.
|
|
|
|
* @param[in] name Name of the object.
|
|
|
|
* @param[in] filename Filename containing the object definition. This is
|
|
|
|
* matched with @ref drgn_filename_matches(). If multiple definitions match, one
|
|
|
|
* is returned arbitrarily.
|
|
|
|
* @param[in] flags Flags indicating what kind of object to look for.
|
|
|
|
* @param[out] ret Returned object. This must have already been initialized with
|
|
|
|
* @ref drgn_object_init().
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
2019-07-29 08:57:28 +01:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_program_find_object(struct drgn_program *prog,
|
|
|
|
const char *name,
|
|
|
|
const char *filename,
|
|
|
|
enum drgn_find_object_flags flags,
|
|
|
|
struct drgn_object *ret);
|
2019-10-18 10:03:32 +01:00
|
|
|
|
2019-07-29 08:57:28 +01:00
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* @ingroup Symbols
|
2019-07-29 08:57:28 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* @struct drgn_symbol
|
|
|
|
*
|
|
|
|
* A @ref drgn_symbol represents an entry in a program's symbol table.
|
2019-07-29 08:57:28 +01:00
|
|
|
*/
|
2023-05-23 22:45:03 +01:00
|
|
|
struct drgn_symbol; // IWYU pragma: export
|
2019-07-29 08:57:28 +01:00
|
|
|
|
2019-10-18 10:03:32 +01:00
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Get the symbol containing the given address.
|
2019-10-18 10:03:32 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* @param[out] ret The returned symbol. It should be freed with @ref
|
|
|
|
* drgn_symbol_destroy().
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
2019-10-18 10:03:32 +01:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *
|
|
|
|
drgn_program_find_symbol_by_address(struct drgn_program *prog, uint64_t address,
|
|
|
|
struct drgn_symbol **ret);
|
2019-10-18 10:03:32 +01:00
|
|
|
|
2019-07-29 08:57:28 +01:00
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Get the symbol corresponding to the given name.
|
2019-07-29 08:57:28 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* @param[out] ret The returned symbol. It should be freed with @ref
|
|
|
|
* drgn_symbol_destroy().
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
2019-07-29 08:57:28 +01:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_program_find_symbol_by_name(struct drgn_program *prog,
|
|
|
|
const char *name,
|
|
|
|
struct drgn_symbol **ret);
|
2019-07-29 08:57:28 +01:00
|
|
|
|
2021-08-02 21:34:30 +01:00
|
|
|
/**
|
|
|
|
* Get all global and local symbols, optionally with the given name.
|
|
|
|
*
|
|
|
|
* @param[in] prog Program.
|
|
|
|
* @param[in] name Name to match. If @c NULL, returns all symbols.
|
|
|
|
* @param[out] syms_ret Returned array of symbols. On success, this must be
|
|
|
|
* freed with @ref drgn_symbols_destroy().
|
|
|
|
* @param[out] count_ret Returned number of symbols in @p syms_ret.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_program_find_symbols_by_name(struct drgn_program *prog,
|
|
|
|
const char *name,
|
|
|
|
struct drgn_symbol ***syms_ret,
|
|
|
|
size_t *count_ret);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get all symbols containing the given address.
|
|
|
|
*
|
|
|
|
* @param[in] prog Program.
|
|
|
|
* @param[in] address Address to search for.
|
|
|
|
* @param[out] syms_ret Returned array of symbols. On success, this must be
|
|
|
|
* freed with @ref drgn_symbols_destroy().
|
|
|
|
* @param[out] count_ret Returned number of symbols in @p syms_ret.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_program_find_symbols_by_address(struct drgn_program *prog,
|
|
|
|
uint64_t address,
|
|
|
|
struct drgn_symbol ***syms_ret,
|
|
|
|
size_t *count_ret);
|
|
|
|
|
2020-12-18 20:20:21 +00:00
|
|
|
/** Element type and size. */
|
|
|
|
struct drgn_element_info {
|
|
|
|
/** Type of the element. */
|
|
|
|
struct drgn_qualified_type qualified_type;
|
|
|
|
/**
|
|
|
|
* Size in bits of one element.
|
|
|
|
*
|
|
|
|
* Element @c i is at bit offset <tt>i * bit_size</tt>.
|
|
|
|
*/
|
|
|
|
uint64_t bit_size;
|
|
|
|
};
|
2019-10-18 10:03:32 +01:00
|
|
|
|
2020-12-18 20:20:21 +00:00
|
|
|
/**
|
|
|
|
* Get the element type and size of an array or pointer @ref drgn_type.
|
|
|
|
*
|
|
|
|
* @param[in] prog Program.
|
|
|
|
* @param[in] type Array or pointer. After this function is called, this type
|
|
|
|
* must remain valid until the program is destroyed.
|
|
|
|
* @param[out] ret Returned element information.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_program_element_info(struct drgn_program *prog,
|
|
|
|
struct drgn_type *type,
|
|
|
|
struct drgn_element_info *ret);
|
2019-10-18 10:03:32 +01:00
|
|
|
|
2019-07-29 08:57:28 +01:00
|
|
|
/** @} */
|
|
|
|
|
2023-07-15 05:23:00 +01:00
|
|
|
/**
|
|
|
|
* @defgroup Logging Logging
|
|
|
|
*
|
|
|
|
* Logging configuration.
|
|
|
|
*
|
|
|
|
* drgn can log to a file (@ref drgn_program_set_log_file()) or an arbitrary
|
|
|
|
* callback (@ref drgn_program_set_log_callback()). Messages can be filtered
|
|
|
|
* based on the log level (@ref drgn_program_set_log_level()).
|
|
|
|
*
|
|
|
|
* By default, the log file is set to `stderr` and the log level is @ref
|
|
|
|
* DRGN_LOG_NONE, so logging is disabled.
|
|
|
|
*
|
|
|
|
* @{
|
|
|
|
*/
|
|
|
|
|
|
|
|
/** Log levels. */
|
|
|
|
enum drgn_log_level {
|
|
|
|
DRGN_LOG_DEBUG = 0,
|
|
|
|
DRGN_LOG_INFO = 1,
|
|
|
|
DRGN_LOG_WARNING = 2,
|
|
|
|
DRGN_LOG_ERROR = 3,
|
|
|
|
DRGN_LOG_CRITICAL = 4,
|
|
|
|
};
|
|
|
|
/** Don't log anything. */
|
|
|
|
#define DRGN_LOG_NONE (DRGN_LOG_CRITICAL + 1)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Set the minimum log level.
|
|
|
|
*
|
|
|
|
* Messages below this level will not be logged.
|
|
|
|
*
|
|
|
|
* @param[in] level Minimum @ref drgn_log_level to log, or @ref DRGN_LOG_NONE to
|
|
|
|
* disable logging.
|
|
|
|
*/
|
|
|
|
void drgn_program_set_log_level(struct drgn_program *prog, int level);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the minimum log level.
|
|
|
|
*
|
|
|
|
* @return Minimum @ref drgn_log_level being logged, or @ref DRGN_LOG_NONE if
|
|
|
|
* logging is disabled.
|
|
|
|
*/
|
|
|
|
int drgn_program_get_log_level(struct drgn_program *prog);
|
|
|
|
|
|
|
|
/** Write logs to the given file. */
|
|
|
|
void drgn_program_set_log_file(struct drgn_program *prog, FILE *file);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Log callback.
|
|
|
|
*
|
|
|
|
* @param[in] prog Program message was logged to.
|
|
|
|
* @param[in] arg `callback_arg` passed to @ref drgn_program_set_log_callback().
|
|
|
|
* @param[in] level Message level.
|
|
|
|
* @param[in] format printf-style format of message.
|
|
|
|
* @param[in] ap Arguments for @p format.
|
|
|
|
* @param[in] err Error to append after formatted message if non-@c NULL. This
|
|
|
|
* can be formatted with @ref drgn_error_string(), @ref drgn_error_fwrite(), or
|
|
|
|
* @ref drgn_error_dwrite().
|
|
|
|
*/
|
|
|
|
typedef void drgn_log_fn(struct drgn_program *prog, void *arg,
|
|
|
|
enum drgn_log_level level, const char *format,
|
|
|
|
va_list ap, struct drgn_error *err);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Set a callback to log to.
|
|
|
|
*
|
|
|
|
* @param[in] callback Callback to call for each log message. This is only
|
|
|
|
* called if the message's level is at least the current log level.
|
|
|
|
* @param[in] callback_arg Argument to pass to callback.
|
|
|
|
*/
|
|
|
|
void drgn_program_set_log_callback(struct drgn_program *prog,
|
|
|
|
drgn_log_fn *callback, void *callback_arg);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the current log callback.
|
|
|
|
*
|
|
|
|
* @param[out] callback_ret Returned callback.
|
|
|
|
* @param[out] callback_arg_ret Returned callback argument.
|
|
|
|
*/
|
|
|
|
void drgn_program_get_log_callback(struct drgn_program *prog,
|
|
|
|
drgn_log_fn **callback_ret,
|
|
|
|
void **callback_arg_ret);
|
|
|
|
|
|
|
|
/** @} */
|
|
|
|
|
2023-07-18 18:14:26 +01:00
|
|
|
/**
|
|
|
|
* @defgroup Embedding Embedding
|
|
|
|
*
|
|
|
|
* Embedding drgn in another runtime.
|
|
|
|
*
|
|
|
|
* @{
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Callback before a blocking operation.
|
|
|
|
*
|
|
|
|
* @param[in] arg @c callback_arg passed to @ref
|
|
|
|
* drgn_program_set_blocking_callback().
|
|
|
|
* @return Opaque pointer to pass to @ref drgn_program_end_blocking_fn().
|
|
|
|
*/
|
|
|
|
typedef void *drgn_program_begin_blocking_fn(struct drgn_program *prog,
|
|
|
|
void *arg);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Callback after a blocking operation.
|
|
|
|
*
|
|
|
|
* @param[in] arg @c callback_arg passed to @ref
|
|
|
|
* drgn_program_set_blocking_callback().
|
|
|
|
* @param[in] state Return value of @ref drgn_program_begin_blocking_fn().
|
|
|
|
*/
|
|
|
|
typedef void drgn_program_end_blocking_fn(struct drgn_program *prog,
|
|
|
|
void *arg, void *state);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Set callbacks around blocking operations.
|
|
|
|
*
|
|
|
|
* These callbacks will be called around blocking I/O operations and
|
|
|
|
* long-running computations. They are intended for things like releasing the
|
|
|
|
* [global interpreter
|
|
|
|
* lock](https://docs.python.org/3/glossary.html#term-global-interpreter-lock).
|
|
|
|
*
|
|
|
|
* @param[in] begin_callback Callback called before a blocking operation. Can be
|
|
|
|
* @c NULL to unset.
|
|
|
|
* @param[in] end_callback Callback called after a blocking operation. Can be @c
|
|
|
|
* NULL to unset.
|
|
|
|
* @param[in] callback_arg Argument passed to @p begin_callback and @p
|
|
|
|
* end_callback.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
drgn_program_set_blocking_callback(struct drgn_program *prog,
|
|
|
|
drgn_program_begin_blocking_fn *begin_callback,
|
|
|
|
drgn_program_end_blocking_fn *end_callback,
|
|
|
|
void *callback_arg);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get callbacks set by @ref drgn_program_set_blocking_callback().
|
|
|
|
*
|
|
|
|
* @param[out] begin_callback_ret Returned @c begin_callback.
|
|
|
|
* @param[out] end_callback_ret Returned @c end_callback.
|
|
|
|
* @param[out] callback_arg_ret Returned @c callback_arg.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
drgn_program_get_blocking_callback(struct drgn_program *prog,
|
|
|
|
drgn_program_begin_blocking_fn **begin_callback_ret,
|
|
|
|
drgn_program_end_blocking_fn **end_callback_ret,
|
|
|
|
void **callback_arg_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-12-18 20:20:21 +00:00
|
|
|
* @defgroup Objects Objects
|
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-12-18 20:20:21 +00:00
|
|
|
* Objects in a 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
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* A @ref drgn_object represents an object (e.g., variable, constant, or
|
|
|
|
* function) in a 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
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* Various operators and helpers are defined on objects; see @ref
|
|
|
|
* ObjectOperators and @ref ObjectHelpers.
|
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-12-18 20:20:21 +00:00
|
|
|
* Many operations are language-specific. C is currently the only supported
|
|
|
|
* language.
|
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-12-18 20:20:21 +00:00
|
|
|
* In drgn's emulation of C:
|
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-12-18 20:20:21 +00:00
|
|
|
* - Signed and unsigned integer arithmetic is reduced modulo 2^width.
|
|
|
|
* - Integer division truncates towards zero.
|
|
|
|
* - Modulo has the sign of the dividend.
|
|
|
|
* - Division or modulo by 0 returns an error.
|
|
|
|
* - Shifts are reduced modulo 2^width. In particular, a shift by a value
|
|
|
|
* greater than the width returns 0.
|
|
|
|
* - Shifts by a negative number return an error.
|
|
|
|
* - Bitwise operators on signed integers act on the two's complement
|
|
|
|
* representation.
|
|
|
|
* - Pointer arithmetic is supported.
|
|
|
|
* - Integer literal have the first type of @c int, @c long, <tt>long long</tt>,
|
|
|
|
* and <tt>unsigned long long</tt> which can represent the value.
|
|
|
|
* - Boolean literals have type @c int (@b not @c _Bool).
|
|
|
|
* - Floating-point literals have type @c double.
|
|
|
|
* @{
|
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-12-18 20:20:21 +00:00
|
|
|
/** Kinds of objects. */
|
|
|
|
enum drgn_object_kind {
|
|
|
|
/** Constant or temporary computed value. */
|
|
|
|
DRGN_OBJECT_VALUE,
|
|
|
|
/** In program memory. */
|
|
|
|
DRGN_OBJECT_REFERENCE,
|
|
|
|
/** Absent (e.g. optimized out). */
|
|
|
|
DRGN_OBJECT_ABSENT,
|
2021-02-21 11:16:23 +00:00
|
|
|
} __attribute__((__packed__));
|
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
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Object encodings.
|
2019-05-10 07:53:16 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* The value of a @ref drgn_object may be encoded in various ways depending on
|
|
|
|
* its type. This determines which field of a @ref drgn_value is used.
|
2019-05-10 07:53:16 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* The incomplete encodings are only possible for reference objects; values have
|
|
|
|
* a complete type.
|
2019-05-10 07:53:16 +01:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
enum drgn_object_encoding {
|
|
|
|
/**
|
|
|
|
* Memory buffer.
|
|
|
|
*
|
2021-02-17 22:56:33 +00:00
|
|
|
* This is used for objects with a structure, union, class, or array
|
libdrgn: support value objects with >64-bit integer types
The Linux kernel's struct task_struct on AArch64 contains an array of
__uint128_t:
>>> task = find_task(prog, 1)
>>> task.type_
struct task_struct *
>>> task.thread.type_
struct thread_struct {
struct cpu_context cpu_context;
struct {
unsigned long tp_value;
unsigned long tp2_value;
struct user_fpsimd_state fpsimd_state;
} uw;
enum fp_type fp_type;
unsigned int fpsimd_cpu;
void *sve_state;
void *sme_state;
unsigned int vl[2];
unsigned int vl_onexec[2];
unsigned long fault_address;
unsigned long fault_code;
struct debug_info debug;
struct ptrauth_keys_user keys_user;
struct ptrauth_keys_kernel keys_kernel;
u64 mte_ctrl;
u64 sctlr_user;
u64 svcr;
u64 tpidr2_el0;
}
>>> task.thread.uw.fpsimd_state.type_
struct user_fpsimd_state {
__int128 unsigned vregs[32];
__u32 fpsr;
__u32 fpcr;
__u32 __reserved[2];
}
As a result, printing a task_struct fails:
>>> task
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/host/home/osandov/repos/drgn3/drgn/cli.py", line 140, in _displayhook
text = value.format_(columns=shutil.get_terminal_size((0, 0)).columns)
NotImplementedError: integer values larger than 64 bits are not yet supported
PR #311 suggested treating >64-bit integers as byte arrays for now; I
tried an alternate hack of handling >64-bit integers only in the
pretty-printing code. Both of these had issues, though.
Instead, let's push >64-bit integer support a little further and allow
storing "big integer" value objects. We still don't support any
operations on them, so this still doesn't complete #170. We store the
raw bytes of the value for now, but we'll probably change this if we add
support for operations (e.g., to store the value as an mp_limb_t array
for GMP). We also print >64-bit integer types in hexadecimal for
simplicity. This is inconsistent with the existing behavior of printing
in decimal, but more readable. In the future, we might want to add
heuristics to decide when to print in decimal vs hexadecimal for all
sizes.
Closes #311.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-08-02 21:12:19 +01:00
|
|
|
* type.
|
2020-12-18 20:20:21 +00:00
|
|
|
*/
|
|
|
|
DRGN_OBJECT_ENCODING_BUFFER,
|
|
|
|
/**
|
|
|
|
* Signed integer.
|
|
|
|
*
|
|
|
|
* This is used for objects with a signed integer or signed enumerated
|
libdrgn: support value objects with >64-bit integer types
The Linux kernel's struct task_struct on AArch64 contains an array of
__uint128_t:
>>> task = find_task(prog, 1)
>>> task.type_
struct task_struct *
>>> task.thread.type_
struct thread_struct {
struct cpu_context cpu_context;
struct {
unsigned long tp_value;
unsigned long tp2_value;
struct user_fpsimd_state fpsimd_state;
} uw;
enum fp_type fp_type;
unsigned int fpsimd_cpu;
void *sve_state;
void *sme_state;
unsigned int vl[2];
unsigned int vl_onexec[2];
unsigned long fault_address;
unsigned long fault_code;
struct debug_info debug;
struct ptrauth_keys_user keys_user;
struct ptrauth_keys_kernel keys_kernel;
u64 mte_ctrl;
u64 sctlr_user;
u64 svcr;
u64 tpidr2_el0;
}
>>> task.thread.uw.fpsimd_state.type_
struct user_fpsimd_state {
__int128 unsigned vregs[32];
__u32 fpsr;
__u32 fpcr;
__u32 __reserved[2];
}
As a result, printing a task_struct fails:
>>> task
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/host/home/osandov/repos/drgn3/drgn/cli.py", line 140, in _displayhook
text = value.format_(columns=shutil.get_terminal_size((0, 0)).columns)
NotImplementedError: integer values larger than 64 bits are not yet supported
PR #311 suggested treating >64-bit integers as byte arrays for now; I
tried an alternate hack of handling >64-bit integers only in the
pretty-printing code. Both of these had issues, though.
Instead, let's push >64-bit integer support a little further and allow
storing "big integer" value objects. We still don't support any
operations on them, so this still doesn't complete #170. We store the
raw bytes of the value for now, but we'll probably change this if we add
support for operations (e.g., to store the value as an mp_limb_t array
for GMP). We also print >64-bit integer types in hexadecimal for
simplicity. This is inconsistent with the existing behavior of printing
in decimal, but more readable. In the future, we might want to add
heuristics to decide when to print in decimal vs hexadecimal for all
sizes.
Closes #311.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-08-02 21:12:19 +01:00
|
|
|
* type no larger than 64 bits.
|
2020-12-18 20:20:21 +00:00
|
|
|
*/
|
|
|
|
DRGN_OBJECT_ENCODING_SIGNED,
|
|
|
|
/**
|
|
|
|
* Unsigned integer.
|
|
|
|
*
|
|
|
|
* This is used for objects with a unsigned integer, boolean, or pointer
|
libdrgn: support value objects with >64-bit integer types
The Linux kernel's struct task_struct on AArch64 contains an array of
__uint128_t:
>>> task = find_task(prog, 1)
>>> task.type_
struct task_struct *
>>> task.thread.type_
struct thread_struct {
struct cpu_context cpu_context;
struct {
unsigned long tp_value;
unsigned long tp2_value;
struct user_fpsimd_state fpsimd_state;
} uw;
enum fp_type fp_type;
unsigned int fpsimd_cpu;
void *sve_state;
void *sme_state;
unsigned int vl[2];
unsigned int vl_onexec[2];
unsigned long fault_address;
unsigned long fault_code;
struct debug_info debug;
struct ptrauth_keys_user keys_user;
struct ptrauth_keys_kernel keys_kernel;
u64 mte_ctrl;
u64 sctlr_user;
u64 svcr;
u64 tpidr2_el0;
}
>>> task.thread.uw.fpsimd_state.type_
struct user_fpsimd_state {
__int128 unsigned vregs[32];
__u32 fpsr;
__u32 fpcr;
__u32 __reserved[2];
}
As a result, printing a task_struct fails:
>>> task
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/host/home/osandov/repos/drgn3/drgn/cli.py", line 140, in _displayhook
text = value.format_(columns=shutil.get_terminal_size((0, 0)).columns)
NotImplementedError: integer values larger than 64 bits are not yet supported
PR #311 suggested treating >64-bit integers as byte arrays for now; I
tried an alternate hack of handling >64-bit integers only in the
pretty-printing code. Both of these had issues, though.
Instead, let's push >64-bit integer support a little further and allow
storing "big integer" value objects. We still don't support any
operations on them, so this still doesn't complete #170. We store the
raw bytes of the value for now, but we'll probably change this if we add
support for operations (e.g., to store the value as an mp_limb_t array
for GMP). We also print >64-bit integer types in hexadecimal for
simplicity. This is inconsistent with the existing behavior of printing
in decimal, but more readable. In the future, we might want to add
heuristics to decide when to print in decimal vs hexadecimal for all
sizes.
Closes #311.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-08-02 21:12:19 +01:00
|
|
|
* type no larger than 64 bits.
|
2020-12-18 20:20:21 +00:00
|
|
|
*/
|
|
|
|
DRGN_OBJECT_ENCODING_UNSIGNED,
|
libdrgn: support value objects with >64-bit integer types
The Linux kernel's struct task_struct on AArch64 contains an array of
__uint128_t:
>>> task = find_task(prog, 1)
>>> task.type_
struct task_struct *
>>> task.thread.type_
struct thread_struct {
struct cpu_context cpu_context;
struct {
unsigned long tp_value;
unsigned long tp2_value;
struct user_fpsimd_state fpsimd_state;
} uw;
enum fp_type fp_type;
unsigned int fpsimd_cpu;
void *sve_state;
void *sme_state;
unsigned int vl[2];
unsigned int vl_onexec[2];
unsigned long fault_address;
unsigned long fault_code;
struct debug_info debug;
struct ptrauth_keys_user keys_user;
struct ptrauth_keys_kernel keys_kernel;
u64 mte_ctrl;
u64 sctlr_user;
u64 svcr;
u64 tpidr2_el0;
}
>>> task.thread.uw.fpsimd_state.type_
struct user_fpsimd_state {
__int128 unsigned vregs[32];
__u32 fpsr;
__u32 fpcr;
__u32 __reserved[2];
}
As a result, printing a task_struct fails:
>>> task
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/host/home/osandov/repos/drgn3/drgn/cli.py", line 140, in _displayhook
text = value.format_(columns=shutil.get_terminal_size((0, 0)).columns)
NotImplementedError: integer values larger than 64 bits are not yet supported
PR #311 suggested treating >64-bit integers as byte arrays for now; I
tried an alternate hack of handling >64-bit integers only in the
pretty-printing code. Both of these had issues, though.
Instead, let's push >64-bit integer support a little further and allow
storing "big integer" value objects. We still don't support any
operations on them, so this still doesn't complete #170. We store the
raw bytes of the value for now, but we'll probably change this if we add
support for operations (e.g., to store the value as an mp_limb_t array
for GMP). We also print >64-bit integer types in hexadecimal for
simplicity. This is inconsistent with the existing behavior of printing
in decimal, but more readable. In the future, we might want to add
heuristics to decide when to print in decimal vs hexadecimal for all
sizes.
Closes #311.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-08-02 21:12:19 +01:00
|
|
|
/**
|
|
|
|
* Big signed integer.
|
|
|
|
*
|
|
|
|
* This is used for objects with a signed integer or signed enumerated
|
|
|
|
* type larger than 64 bits.
|
|
|
|
*/
|
|
|
|
DRGN_OBJECT_ENCODING_SIGNED_BIG,
|
|
|
|
/**
|
|
|
|
* Big unsigned integer.
|
|
|
|
*
|
|
|
|
* This is used for objects with a unsigned integer, boolean, or pointer
|
|
|
|
* type larger than 64 bits.
|
|
|
|
*/
|
|
|
|
DRGN_OBJECT_ENCODING_UNSIGNED_BIG,
|
2020-12-18 20:20:21 +00:00
|
|
|
/**
|
|
|
|
* Floating-point value.
|
|
|
|
*
|
|
|
|
* This used for objects with a floating-point type.
|
|
|
|
*/
|
|
|
|
DRGN_OBJECT_ENCODING_FLOAT,
|
|
|
|
/**
|
|
|
|
* No value.
|
|
|
|
*
|
|
|
|
* This is used for reference objects with a void or function type.
|
|
|
|
*/
|
|
|
|
DRGN_OBJECT_ENCODING_NONE = -1,
|
|
|
|
/**
|
|
|
|
* Incomplete buffer value.
|
|
|
|
*
|
|
|
|
* This is used for reference objects with an incomplete structure,
|
|
|
|
* union, class, or array type.
|
|
|
|
*/
|
|
|
|
DRGN_OBJECT_ENCODING_INCOMPLETE_BUFFER = -2,
|
|
|
|
/**
|
|
|
|
* Incomplete integer value.
|
|
|
|
*
|
|
|
|
* This is used for reference objects with an incomplete enumerated
|
|
|
|
* types.
|
|
|
|
*/
|
|
|
|
DRGN_OBJECT_ENCODING_INCOMPLETE_INTEGER = -3,
|
2021-02-21 11:16:23 +00:00
|
|
|
} __attribute__((__packed__));
|
2019-05-10 07:53:16 +01:00
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Return whether a type corresponding to an object encoding is complete.
|
2019-05-10 07:53:16 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* @sa drgn_type_is_complete()
|
2019-05-10 07:53:16 +01:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
static inline bool
|
|
|
|
drgn_object_encoding_is_complete(enum drgn_object_encoding encoding)
|
|
|
|
{
|
|
|
|
return encoding >= 0;
|
|
|
|
}
|
2019-05-10 07:53:16 +01:00
|
|
|
|
2020-12-18 20:20:21 +00:00
|
|
|
/** Value of a @ref drgn_object. */
|
|
|
|
union drgn_value {
|
|
|
|
/**
|
libdrgn: support value objects with >64-bit integer types
The Linux kernel's struct task_struct on AArch64 contains an array of
__uint128_t:
>>> task = find_task(prog, 1)
>>> task.type_
struct task_struct *
>>> task.thread.type_
struct thread_struct {
struct cpu_context cpu_context;
struct {
unsigned long tp_value;
unsigned long tp2_value;
struct user_fpsimd_state fpsimd_state;
} uw;
enum fp_type fp_type;
unsigned int fpsimd_cpu;
void *sve_state;
void *sme_state;
unsigned int vl[2];
unsigned int vl_onexec[2];
unsigned long fault_address;
unsigned long fault_code;
struct debug_info debug;
struct ptrauth_keys_user keys_user;
struct ptrauth_keys_kernel keys_kernel;
u64 mte_ctrl;
u64 sctlr_user;
u64 svcr;
u64 tpidr2_el0;
}
>>> task.thread.uw.fpsimd_state.type_
struct user_fpsimd_state {
__int128 unsigned vregs[32];
__u32 fpsr;
__u32 fpcr;
__u32 __reserved[2];
}
As a result, printing a task_struct fails:
>>> task
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/host/home/osandov/repos/drgn3/drgn/cli.py", line 140, in _displayhook
text = value.format_(columns=shutil.get_terminal_size((0, 0)).columns)
NotImplementedError: integer values larger than 64 bits are not yet supported
PR #311 suggested treating >64-bit integers as byte arrays for now; I
tried an alternate hack of handling >64-bit integers only in the
pretty-printing code. Both of these had issues, though.
Instead, let's push >64-bit integer support a little further and allow
storing "big integer" value objects. We still don't support any
operations on them, so this still doesn't complete #170. We store the
raw bytes of the value for now, but we'll probably change this if we add
support for operations (e.g., to store the value as an mp_limb_t array
for GMP). We also print >64-bit integer types in hexadecimal for
simplicity. This is inconsistent with the existing behavior of printing
in decimal, but more readable. In the future, we might want to add
heuristics to decide when to print in decimal vs hexadecimal for all
sizes.
Closes #311.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-08-02 21:12:19 +01:00
|
|
|
* Pointer to an external buffer for a @ref DRGN_OBJECT_ENCODING_BUFFER,
|
|
|
|
* @ref DRGN_OBJECT_ENCODING_SIGNED_BIG, or @ref
|
|
|
|
* DRGN_OBJECT_ENCODING_UNSIGNED_BIG value.
|
|
|
|
*
|
|
|
|
* For @ref DRGN_OBJECT_ENCODING_BUFFER, this contains the object's
|
|
|
|
* representation in the memory of the program.
|
|
|
|
*
|
|
|
|
* For @ref DRGN_OBJECT_ENCODING_SIGNED_BIG and @ref
|
|
|
|
* DRGN_OBJECT_ENCODING_UNSIGNED_BIG, the representation of the value is
|
|
|
|
* an implementation detail which may change.
|
2020-12-18 20:20:21 +00:00
|
|
|
*/
|
|
|
|
char *bufp;
|
|
|
|
/**
|
libdrgn: support value objects with >64-bit integer types
The Linux kernel's struct task_struct on AArch64 contains an array of
__uint128_t:
>>> task = find_task(prog, 1)
>>> task.type_
struct task_struct *
>>> task.thread.type_
struct thread_struct {
struct cpu_context cpu_context;
struct {
unsigned long tp_value;
unsigned long tp2_value;
struct user_fpsimd_state fpsimd_state;
} uw;
enum fp_type fp_type;
unsigned int fpsimd_cpu;
void *sve_state;
void *sme_state;
unsigned int vl[2];
unsigned int vl_onexec[2];
unsigned long fault_address;
unsigned long fault_code;
struct debug_info debug;
struct ptrauth_keys_user keys_user;
struct ptrauth_keys_kernel keys_kernel;
u64 mte_ctrl;
u64 sctlr_user;
u64 svcr;
u64 tpidr2_el0;
}
>>> task.thread.uw.fpsimd_state.type_
struct user_fpsimd_state {
__int128 unsigned vregs[32];
__u32 fpsr;
__u32 fpcr;
__u32 __reserved[2];
}
As a result, printing a task_struct fails:
>>> task
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/host/home/osandov/repos/drgn3/drgn/cli.py", line 140, in _displayhook
text = value.format_(columns=shutil.get_terminal_size((0, 0)).columns)
NotImplementedError: integer values larger than 64 bits are not yet supported
PR #311 suggested treating >64-bit integers as byte arrays for now; I
tried an alternate hack of handling >64-bit integers only in the
pretty-printing code. Both of these had issues, though.
Instead, let's push >64-bit integer support a little further and allow
storing "big integer" value objects. We still don't support any
operations on them, so this still doesn't complete #170. We store the
raw bytes of the value for now, but we'll probably change this if we add
support for operations (e.g., to store the value as an mp_limb_t array
for GMP). We also print >64-bit integer types in hexadecimal for
simplicity. This is inconsistent with the existing behavior of printing
in decimal, but more readable. In the future, we might want to add
heuristics to decide when to print in decimal vs hexadecimal for all
sizes.
Closes #311.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-08-02 21:12:19 +01:00
|
|
|
* Inline buffer for a @ref DRGN_OBJECT_ENCODING_BUFFER value.
|
2020-12-18 20:20:21 +00:00
|
|
|
*
|
|
|
|
* Tiny buffers (see @ref drgn_value_is_inline()) are stored inline here
|
|
|
|
* instead of in a separate allocation.
|
|
|
|
*/
|
|
|
|
char ibuf[8];
|
libdrgn: support value objects with >64-bit integer types
The Linux kernel's struct task_struct on AArch64 contains an array of
__uint128_t:
>>> task = find_task(prog, 1)
>>> task.type_
struct task_struct *
>>> task.thread.type_
struct thread_struct {
struct cpu_context cpu_context;
struct {
unsigned long tp_value;
unsigned long tp2_value;
struct user_fpsimd_state fpsimd_state;
} uw;
enum fp_type fp_type;
unsigned int fpsimd_cpu;
void *sve_state;
void *sme_state;
unsigned int vl[2];
unsigned int vl_onexec[2];
unsigned long fault_address;
unsigned long fault_code;
struct debug_info debug;
struct ptrauth_keys_user keys_user;
struct ptrauth_keys_kernel keys_kernel;
u64 mte_ctrl;
u64 sctlr_user;
u64 svcr;
u64 tpidr2_el0;
}
>>> task.thread.uw.fpsimd_state.type_
struct user_fpsimd_state {
__int128 unsigned vregs[32];
__u32 fpsr;
__u32 fpcr;
__u32 __reserved[2];
}
As a result, printing a task_struct fails:
>>> task
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/host/home/osandov/repos/drgn3/drgn/cli.py", line 140, in _displayhook
text = value.format_(columns=shutil.get_terminal_size((0, 0)).columns)
NotImplementedError: integer values larger than 64 bits are not yet supported
PR #311 suggested treating >64-bit integers as byte arrays for now; I
tried an alternate hack of handling >64-bit integers only in the
pretty-printing code. Both of these had issues, though.
Instead, let's push >64-bit integer support a little further and allow
storing "big integer" value objects. We still don't support any
operations on them, so this still doesn't complete #170. We store the
raw bytes of the value for now, but we'll probably change this if we add
support for operations (e.g., to store the value as an mp_limb_t array
for GMP). We also print >64-bit integer types in hexadecimal for
simplicity. This is inconsistent with the existing behavior of printing
in decimal, but more readable. In the future, we might want to add
heuristics to decide when to print in decimal vs hexadecimal for all
sizes.
Closes #311.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-08-02 21:12:19 +01:00
|
|
|
/** @ref DRGN_OBJECT_ENCODING_SIGNED value. */
|
2020-12-18 20:20:21 +00:00
|
|
|
int64_t svalue;
|
libdrgn: support value objects with >64-bit integer types
The Linux kernel's struct task_struct on AArch64 contains an array of
__uint128_t:
>>> task = find_task(prog, 1)
>>> task.type_
struct task_struct *
>>> task.thread.type_
struct thread_struct {
struct cpu_context cpu_context;
struct {
unsigned long tp_value;
unsigned long tp2_value;
struct user_fpsimd_state fpsimd_state;
} uw;
enum fp_type fp_type;
unsigned int fpsimd_cpu;
void *sve_state;
void *sme_state;
unsigned int vl[2];
unsigned int vl_onexec[2];
unsigned long fault_address;
unsigned long fault_code;
struct debug_info debug;
struct ptrauth_keys_user keys_user;
struct ptrauth_keys_kernel keys_kernel;
u64 mte_ctrl;
u64 sctlr_user;
u64 svcr;
u64 tpidr2_el0;
}
>>> task.thread.uw.fpsimd_state.type_
struct user_fpsimd_state {
__int128 unsigned vregs[32];
__u32 fpsr;
__u32 fpcr;
__u32 __reserved[2];
}
As a result, printing a task_struct fails:
>>> task
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/host/home/osandov/repos/drgn3/drgn/cli.py", line 140, in _displayhook
text = value.format_(columns=shutil.get_terminal_size((0, 0)).columns)
NotImplementedError: integer values larger than 64 bits are not yet supported
PR #311 suggested treating >64-bit integers as byte arrays for now; I
tried an alternate hack of handling >64-bit integers only in the
pretty-printing code. Both of these had issues, though.
Instead, let's push >64-bit integer support a little further and allow
storing "big integer" value objects. We still don't support any
operations on them, so this still doesn't complete #170. We store the
raw bytes of the value for now, but we'll probably change this if we add
support for operations (e.g., to store the value as an mp_limb_t array
for GMP). We also print >64-bit integer types in hexadecimal for
simplicity. This is inconsistent with the existing behavior of printing
in decimal, but more readable. In the future, we might want to add
heuristics to decide when to print in decimal vs hexadecimal for all
sizes.
Closes #311.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-08-02 21:12:19 +01:00
|
|
|
/** @ref DRGN_OBJECT_ENCODING_UNSIGNED value. */
|
2020-12-18 20:20:21 +00:00
|
|
|
uint64_t uvalue;
|
libdrgn: support value objects with >64-bit integer types
The Linux kernel's struct task_struct on AArch64 contains an array of
__uint128_t:
>>> task = find_task(prog, 1)
>>> task.type_
struct task_struct *
>>> task.thread.type_
struct thread_struct {
struct cpu_context cpu_context;
struct {
unsigned long tp_value;
unsigned long tp2_value;
struct user_fpsimd_state fpsimd_state;
} uw;
enum fp_type fp_type;
unsigned int fpsimd_cpu;
void *sve_state;
void *sme_state;
unsigned int vl[2];
unsigned int vl_onexec[2];
unsigned long fault_address;
unsigned long fault_code;
struct debug_info debug;
struct ptrauth_keys_user keys_user;
struct ptrauth_keys_kernel keys_kernel;
u64 mte_ctrl;
u64 sctlr_user;
u64 svcr;
u64 tpidr2_el0;
}
>>> task.thread.uw.fpsimd_state.type_
struct user_fpsimd_state {
__int128 unsigned vregs[32];
__u32 fpsr;
__u32 fpcr;
__u32 __reserved[2];
}
As a result, printing a task_struct fails:
>>> task
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/host/home/osandov/repos/drgn3/drgn/cli.py", line 140, in _displayhook
text = value.format_(columns=shutil.get_terminal_size((0, 0)).columns)
NotImplementedError: integer values larger than 64 bits are not yet supported
PR #311 suggested treating >64-bit integers as byte arrays for now; I
tried an alternate hack of handling >64-bit integers only in the
pretty-printing code. Both of these had issues, though.
Instead, let's push >64-bit integer support a little further and allow
storing "big integer" value objects. We still don't support any
operations on them, so this still doesn't complete #170. We store the
raw bytes of the value for now, but we'll probably change this if we add
support for operations (e.g., to store the value as an mp_limb_t array
for GMP). We also print >64-bit integer types in hexadecimal for
simplicity. This is inconsistent with the existing behavior of printing
in decimal, but more readable. In the future, we might want to add
heuristics to decide when to print in decimal vs hexadecimal for all
sizes.
Closes #311.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-08-02 21:12:19 +01:00
|
|
|
/** @ref DRGN_OBJECT_ENCODING_FLOAT value. */
|
2020-12-18 20:20:21 +00:00
|
|
|
double fvalue;
|
|
|
|
};
|
2019-05-10 07:53:16 +01:00
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Return the number of bytes needed to store the given number of bits.
|
2019-05-10 07:53:16 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* @param[in] bits Number of bits.
|
2019-05-10 07:53:16 +01:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
static inline uint64_t drgn_value_size(uint64_t bits)
|
|
|
|
{
|
|
|
|
return bits / CHAR_BIT + (bits % CHAR_BIT ? 1 : 0);
|
|
|
|
}
|
2019-05-10 07:53:16 +01:00
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Return whether the given number of bits can be stored in the inline buffer of
|
|
|
|
* a @ref drgn_value (@ref drgn_value::ibuf).
|
2019-05-10 07:53:16 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* @param[in] bits Number of bits.
|
2019-05-10 07:53:16 +01:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_value_is_inline(uint64_t bits)
|
|
|
|
{
|
|
|
|
return bits <= CHAR_BIT * sizeof(((union drgn_value *)0)->ibuf);
|
|
|
|
}
|
2019-05-10 07:53:16 +01:00
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Object in a program.
|
2019-05-10 07:53:16 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* A @ref drgn_object represents a symbol or value in a program. It can be in
|
|
|
|
* the memory of the program (a "reference"), a temporary computed value (a
|
|
|
|
* "value"), or "absent".
|
2019-05-10 07:53:16 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* A @ref drgn_object must be initialized with @ref drgn_object_init() before it
|
|
|
|
* is used. It can then be set and otherwise changed repeatedly. When the object
|
|
|
|
* is no longer needed, it must be deinitialized @ref drgn_object_deinit().
|
2019-05-10 07:53:16 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* It is more effecient to initialize an object once and reuse it rather than
|
|
|
|
* creating a new one repeatedly (e.g., in a loop).
|
|
|
|
*
|
|
|
|
* Members of a @ref drgn_object should not be modified except through the
|
|
|
|
* provided functions.
|
|
|
|
*/
|
|
|
|
struct drgn_object {
|
|
|
|
/** Type of this object. */
|
|
|
|
struct drgn_type *type;
|
|
|
|
/**
|
|
|
|
* Size of this object in bits.
|
|
|
|
*
|
|
|
|
* This is usually the size of @ref drgn_object::type, but it may be
|
|
|
|
* smaller if this is a bit field (@ref drgn_object::is_bit_field).
|
|
|
|
*/
|
|
|
|
uint64_t bit_size;
|
|
|
|
/** Qualifiers on @ref drgn_object::type. */
|
|
|
|
enum drgn_qualifiers qualifiers;
|
|
|
|
/** How this object is encoded. */
|
|
|
|
enum drgn_object_encoding encoding;
|
|
|
|
/** Kind of this object. */
|
|
|
|
enum drgn_object_kind kind;
|
|
|
|
/** Whether this object is a bit field. */
|
|
|
|
bool is_bit_field;
|
|
|
|
/**
|
|
|
|
* Whether this object is little-endian.
|
|
|
|
*
|
libdrgn: support value objects with >64-bit integer types
The Linux kernel's struct task_struct on AArch64 contains an array of
__uint128_t:
>>> task = find_task(prog, 1)
>>> task.type_
struct task_struct *
>>> task.thread.type_
struct thread_struct {
struct cpu_context cpu_context;
struct {
unsigned long tp_value;
unsigned long tp2_value;
struct user_fpsimd_state fpsimd_state;
} uw;
enum fp_type fp_type;
unsigned int fpsimd_cpu;
void *sve_state;
void *sme_state;
unsigned int vl[2];
unsigned int vl_onexec[2];
unsigned long fault_address;
unsigned long fault_code;
struct debug_info debug;
struct ptrauth_keys_user keys_user;
struct ptrauth_keys_kernel keys_kernel;
u64 mte_ctrl;
u64 sctlr_user;
u64 svcr;
u64 tpidr2_el0;
}
>>> task.thread.uw.fpsimd_state.type_
struct user_fpsimd_state {
__int128 unsigned vregs[32];
__u32 fpsr;
__u32 fpcr;
__u32 __reserved[2];
}
As a result, printing a task_struct fails:
>>> task
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/host/home/osandov/repos/drgn3/drgn/cli.py", line 140, in _displayhook
text = value.format_(columns=shutil.get_terminal_size((0, 0)).columns)
NotImplementedError: integer values larger than 64 bits are not yet supported
PR #311 suggested treating >64-bit integers as byte arrays for now; I
tried an alternate hack of handling >64-bit integers only in the
pretty-printing code. Both of these had issues, though.
Instead, let's push >64-bit integer support a little further and allow
storing "big integer" value objects. We still don't support any
operations on them, so this still doesn't complete #170. We store the
raw bytes of the value for now, but we'll probably change this if we add
support for operations (e.g., to store the value as an mp_limb_t array
for GMP). We also print >64-bit integer types in hexadecimal for
simplicity. This is inconsistent with the existing behavior of printing
in decimal, but more readable. In the future, we might want to add
heuristics to decide when to print in decimal vs hexadecimal for all
sizes.
Closes #311.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-08-02 21:12:19 +01:00
|
|
|
* Valid only for scalars (i.e., @ref DRGN_OBJECT_ENCODING_SIGNED, @ref
|
|
|
|
* DRGN_OBJECT_ENCODING_UNSIGNED, @ref DRGN_OBJECT_ENCODING_SIGNED_BIG,
|
|
|
|
* @ref DRGN_OBJECT_ENCODING_UNSIGNED_BIG, @ref
|
|
|
|
* DRGN_OBJECT_ENCODING_FLOAT, or @ref
|
|
|
|
* DRGN_OBJECT_ENCODING_INCOMPLETE_INTEGER).
|
2020-12-18 20:20:21 +00:00
|
|
|
*/
|
|
|
|
bool little_endian;
|
|
|
|
/**
|
|
|
|
* Offset in bits from @c address.
|
|
|
|
*
|
|
|
|
* Valid only for reference objects.
|
|
|
|
*/
|
|
|
|
uint8_t bit_offset;
|
|
|
|
union {
|
|
|
|
/** Value of value object. */
|
|
|
|
union drgn_value value;
|
|
|
|
/** Address of reference object. */
|
|
|
|
uint64_t address;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Return the number of bytes needed to store an object's value. */
|
|
|
|
static inline uint64_t drgn_object_size(const struct drgn_object *obj)
|
|
|
|
{
|
|
|
|
return drgn_value_size(obj->bit_size);
|
|
|
|
}
|
2019-05-10 07:53:16 +01:00
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Return whether an object's value can be stored in the inline buffer of a @ref
|
|
|
|
* drgn_value (@ref drgn_value::ibuf).
|
2019-05-10 07:53:16 +01:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_object_is_inline(const struct drgn_object *obj)
|
|
|
|
{
|
|
|
|
return drgn_value_is_inline(obj->bit_size);
|
|
|
|
}
|
|
|
|
|
|
|
|
/** Return an object's buffer. */
|
|
|
|
#define drgn_object_buffer(obj) ({ \
|
|
|
|
__auto_type _obj = (obj); \
|
|
|
|
drgn_object_is_inline(_obj) ? _obj->value.ibuf : _obj->value.bufp; \
|
|
|
|
})
|
|
|
|
|
|
|
|
/** Get the type of a @ref drgn_object. */
|
|
|
|
static inline struct drgn_qualified_type
|
|
|
|
drgn_object_qualified_type(const struct drgn_object *obj)
|
|
|
|
{
|
|
|
|
return (struct drgn_qualified_type){
|
|
|
|
.type = obj->type,
|
|
|
|
.qualifiers = obj->qualifiers,
|
|
|
|
};
|
|
|
|
}
|
2019-05-10 07:53:16 +01:00
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Initialize a @ref drgn_object.
|
2019-05-10 07:53:16 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* The object is initialized to a @c NULL reference with a void type. This must
|
|
|
|
* be paired with a call to @ref drgn_object_deinit().
|
2019-05-10 07:53:16 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* @param[in] obj Object to initialize.
|
|
|
|
* @param[in] prog Program containing the object.
|
2019-05-10 07:53:16 +01:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
void drgn_object_init(struct drgn_object *obj, struct drgn_program *prog);
|
2019-05-10 07:53:16 +01:00
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Deinitialize a @ref drgn_object.
|
2019-05-10 07:53:16 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* The object cannot be used after this unless it is reinitialized with @ref
|
|
|
|
* drgn_object_init().
|
|
|
|
*
|
|
|
|
* @param[in] obj Object to deinitialize.
|
2019-05-10 07:53:16 +01:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
void drgn_object_deinit(struct drgn_object *obj);
|
|
|
|
|
|
|
|
/** Get the program that a @ref drgn_object is from. */
|
|
|
|
static inline struct drgn_program *
|
|
|
|
drgn_object_program(const struct drgn_object *obj)
|
|
|
|
{
|
|
|
|
return drgn_type_program(obj->type);
|
|
|
|
}
|
|
|
|
|
|
|
|
/** Get the language of a @ref drgn_object from its type. */
|
|
|
|
static inline const struct drgn_language *
|
|
|
|
drgn_object_language(const struct drgn_object *obj)
|
|
|
|
{
|
|
|
|
return drgn_type_language(obj->type);
|
|
|
|
}
|
2019-05-10 07:53:16 +01:00
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* @defgroup ObjectSetters Setters
|
2019-05-10 07:53:16 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* Object setters.
|
2019-05-10 07:53:16 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* Once a @ref drgn_object is initialized with @ref drgn_object_init(), it may
|
|
|
|
* be set any number of times.
|
|
|
|
*
|
|
|
|
* @{
|
2019-05-10 07:53:16 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Set a @ref drgn_object to a signed value.
|
2019-09-25 01:13:53 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* @param[out] res Object to set.
|
|
|
|
* @param[in] qualified_type Type to set to.
|
|
|
|
* @param[in] svalue Value to set to.
|
|
|
|
* @param[in] bit_field_size If the object should be a bit field, its size in
|
|
|
|
* bits. Otherwise, 0.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
2019-05-10 07:53:16 +01:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *
|
|
|
|
drgn_object_set_signed(struct drgn_object *res,
|
|
|
|
struct drgn_qualified_type qualified_type,
|
|
|
|
int64_t svalue, uint64_t bit_field_size);
|
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
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Set a @ref drgn_object to an unsigned value.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[out] res Object to set.
|
|
|
|
* @param[in] qualified_type Type to set to.
|
|
|
|
* @param[in] uvalue Value to set to.
|
|
|
|
* @param[in] bit_field_size If the object should be a bit field, its size in
|
|
|
|
* bits. Otherwise, 0.
|
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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *
|
|
|
|
drgn_object_set_unsigned(struct drgn_object *res,
|
|
|
|
struct drgn_qualified_type qualified_type,
|
|
|
|
uint64_t uvalue, uint64_t bit_field_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
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Set a @ref drgn_object to a floating-point value.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[out] res Object to set.
|
|
|
|
* @param[in] qualified_type Type to set to.
|
|
|
|
* @param[in] fvalue Value to set to.
|
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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *
|
|
|
|
drgn_object_set_float(struct drgn_object *res,
|
|
|
|
struct drgn_qualified_type qualified_type, double fvalue);
|
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-12-18 20:20:21 +00:00
|
|
|
* Set a @ref drgn_object from a buffer.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[out] res Object to set.
|
|
|
|
* @param[in] qualified_type Type to set to.
|
|
|
|
* @param[in] buf Buffer to set to. It is copied, so it need not remain valid
|
|
|
|
* after this function returns.
|
|
|
|
* @param[in] buf_size Size of @p buf, in bytes. `buf_size * 8` must be at least
|
|
|
|
* `bit_size + bit_offset`, where @c bit_size is @p bit_field_size if non-zero
|
|
|
|
* and the size of @p qualified_type in bits otherwise.
|
|
|
|
* @param[in] bit_offset Offset of the value from the beginning of the buffer,
|
Track byte order in scalar types instead of objects
Currently, reference objects and buffer value objects have a byte order.
However, this doesn't always make sense for a couple of reasons:
- Byte order is only meaningful for scalars. What does it mean for a
struct to be big endian? A struct doesn't have a most or least
significant byte; its scalar members do.
- The DWARF specification allows either types or variables to have a
byte order (DW_AT_endianity). The only producer I could find that uses
this is GCC for the scalar_storage_order type attribute, and it only
uses it for base types, not variables. GDB only seems to use to check
it for base types, as well.
So, remove the byte order from objects, and move it to integer, boolean,
floating-point, and pointer types. This model makes more sense, and it
means that we can get the binary representation of any object now.
The only downside is that we can no longer support a bit offset for
non-scalars, but as far as I can tell, nothing needs that.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-02-18 00:13:23 +00:00
|
|
|
* in bits. This is usually 0. It must be aligned to a byte unless the type is
|
|
|
|
* scalar.
|
2020-12-18 20:20:21 +00:00
|
|
|
* @param[in] bit_field_size If the object should be a bit field, its size in
|
|
|
|
* bits. Otherwise, 0.
|
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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *
|
|
|
|
drgn_object_set_from_buffer(struct drgn_object *res,
|
|
|
|
struct drgn_qualified_type qualified_type,
|
|
|
|
const void *buf, size_t buf_size,
|
Track byte order in scalar types instead of objects
Currently, reference objects and buffer value objects have a byte order.
However, this doesn't always make sense for a couple of reasons:
- Byte order is only meaningful for scalars. What does it mean for a
struct to be big endian? A struct doesn't have a most or least
significant byte; its scalar members do.
- The DWARF specification allows either types or variables to have a
byte order (DW_AT_endianity). The only producer I could find that uses
this is GCC for the scalar_storage_order type attribute, and it only
uses it for base types, not variables. GDB only seems to use to check
it for base types, as well.
So, remove the byte order from objects, and move it to integer, boolean,
floating-point, and pointer types. This model makes more sense, and it
means that we can get the binary representation of any object now.
The only downside is that we can no longer support a bit offset for
non-scalars, but as far as I can tell, nothing needs that.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-02-18 00:13:23 +00:00
|
|
|
uint64_t bit_offset, uint64_t bit_field_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
|
|
|
|
2019-07-29 08:57:28 +01:00
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Set a @ref drgn_object to a reference.
|
2019-07-29 08:57:28 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* @param[out] res Object to set.
|
|
|
|
* @param[in] qualified_type Type to set to.
|
|
|
|
* @param[in] address Address of the object.
|
|
|
|
* @param[in] bit_offset Offset of the value from @p address, in bits. This is
|
|
|
|
* usually 0.
|
|
|
|
* @param[in] bit_field_size If the object should be a bit field, its size in
|
|
|
|
* bits. Otherwise, 0.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
2019-07-29 08:57:28 +01:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *
|
|
|
|
drgn_object_set_reference(struct drgn_object *res,
|
|
|
|
struct drgn_qualified_type qualified_type,
|
|
|
|
uint64_t address, uint64_t bit_offset,
|
Track byte order in scalar types instead of objects
Currently, reference objects and buffer value objects have a byte order.
However, this doesn't always make sense for a couple of reasons:
- Byte order is only meaningful for scalars. What does it mean for a
struct to be big endian? A struct doesn't have a most or least
significant byte; its scalar members do.
- The DWARF specification allows either types or variables to have a
byte order (DW_AT_endianity). The only producer I could find that uses
this is GCC for the scalar_storage_order type attribute, and it only
uses it for base types, not variables. GDB only seems to use to check
it for base types, as well.
So, remove the byte order from objects, and move it to integer, boolean,
floating-point, and pointer types. This model makes more sense, and it
means that we can get the binary representation of any object now.
The only downside is that we can no longer support a bit offset for
non-scalars, but as far as I can tell, nothing needs that.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-02-18 00:13:23 +00:00
|
|
|
uint64_t bit_field_size);
|
2020-02-26 22:32:35 +00: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
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Set a @ref drgn_object as absent.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[out] res Object to set.
|
|
|
|
* @param[in] qualified_type Type to set to.
|
|
|
|
* @param[in] bit_field_size If the object should be a bit field, its size in
|
|
|
|
* bits. Otherwise, 0.
|
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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *
|
|
|
|
drgn_object_set_absent(struct drgn_object *res,
|
|
|
|
struct drgn_qualified_type qualified_type,
|
|
|
|
uint64_t bit_field_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
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Set a @ref drgn_object to a integer literal.
|
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-12-18 20:20:21 +00:00
|
|
|
* This determines the type based on the programming language of the program
|
|
|
|
* that the object belongs to.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[out] res Object to set.
|
|
|
|
* @param[in] uvalue Integer value.
|
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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_object_integer_literal(struct drgn_object *res,
|
|
|
|
uint64_t uvalue);
|
2020-04-27 08:34:04 +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
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Set a @ref drgn_object to a boolean literal.
|
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-12-18 20:20:21 +00:00
|
|
|
* This determines the type based on the programming language of the program
|
|
|
|
* that the object belongs to.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[out] res Object to set.
|
|
|
|
* @param[in] bvalue Boolean value.
|
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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_object_bool_literal(struct drgn_object *res,
|
|
|
|
bool bvalue);
|
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-12-18 20:20:21 +00:00
|
|
|
* Set a @ref drgn_object to a floating-point literal.
|
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-12-18 20:20:21 +00:00
|
|
|
* This determines the type based on the programming language of the program
|
|
|
|
* that the object belongs to.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[out] res Object to set.
|
|
|
|
* @param[in] fvalue Floating-point value.
|
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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_object_float_literal(struct drgn_object *res,
|
|
|
|
double fvalue);
|
|
|
|
|
|
|
|
/** @} */
|
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-25 08:47:13 +01:00
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* @defgroup ObjectHelpers Helpers
|
2019-07-25 08:47:13 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* Object helpers.
|
2019-07-25 08:47:13 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* Several helpers are provided for working with @ref drgn_object%s.
|
|
|
|
*
|
|
|
|
* Helpers which return a @ref drgn_object have the same calling convention: the
|
|
|
|
* result object is the first argument, which must be initialized and may be the
|
|
|
|
* same as the input object argument; the result is only modified if the helper
|
|
|
|
* succeeds.
|
|
|
|
*
|
|
|
|
* @{
|
2019-07-25 08:47:13 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Set a @ref drgn_object to another object.
|
2019-07-25 08:47:13 +01:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* This copies @c obj to @c res. If @c obj is a value, then @c res is set to a
|
|
|
|
* value with the same type and value, and similarly if @c obj was a reference,
|
|
|
|
* @c res is set to the same reference.
|
|
|
|
*
|
|
|
|
* @param[out] res Destination object.
|
|
|
|
* @param[in] obj Source object.
|
2019-07-25 08:47:13 +01:00
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_object_copy(struct drgn_object *res,
|
|
|
|
const struct drgn_object *obj);
|
2019-07-25 08:47:13 +01:00
|
|
|
|
2020-02-07 16:43:05 +00:00
|
|
|
/**
|
2021-03-16 23:15:43 +00:00
|
|
|
* Get a @ref drgn_object from a slice of a @ref DRGN_OBJECT_ENCODING_BUFFER
|
|
|
|
* object.
|
2020-02-07 16:43:05 +00:00
|
|
|
*
|
2020-12-18 20:20:21 +00:00
|
|
|
* This is a low-level interface used to implement @ref drgn_object_subscript()
|
|
|
|
* and @ref drgn_object_member(). Those functions are usually more convenient.
|
|
|
|
*
|
|
|
|
* If multiple elements of an array are accessed (e.g., when iterating through
|
|
|
|
* it), it can be more efficient to call @ref drgn_program_element_info() once
|
|
|
|
* to get the required information and this function with the computed bit
|
|
|
|
* offset for each element.
|
|
|
|
*
|
|
|
|
* If the same member of a type is accessed repeatedly (e.g., in a loop), it can
|
2021-02-21 10:41:20 +00:00
|
|
|
* be more efficient to call @ref drgn_type_find_member() once to get the
|
2020-12-18 20:20:21 +00:00
|
|
|
* required information and this function to access the member each time.
|
|
|
|
*
|
2021-02-21 10:41:20 +00:00
|
|
|
* @sa drgn_object_dereference_offset
|
2020-12-18 20:20:21 +00:00
|
|
|
*
|
|
|
|
* @param[out] res Destination object.
|
|
|
|
* @param[in] obj Source object.
|
|
|
|
* @param[in] qualified_type Result type.
|
|
|
|
* @param[in] bit_offset Offset in bits from the beginning of @p obj.
|
|
|
|
* @param[in] bit_field_size If the object should be a bit field, its size in
|
|
|
|
* bits. Otherwise, 0.
|
2020-02-07 16:43:05 +00:00
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_object_slice(struct drgn_object *res,
|
|
|
|
const struct drgn_object *obj,
|
|
|
|
struct drgn_qualified_type qualified_type,
|
|
|
|
uint64_t bit_offset,
|
|
|
|
uint64_t bit_field_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
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Get a @ref drgn_object from dereferencing a pointer object with an offset.
|
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-12-18 20:20:21 +00:00
|
|
|
* This is a low-level interface used to implement @ref drgn_object_subscript()
|
|
|
|
* and @ref drgn_object_member_dereference(). Those functions are usually more
|
|
|
|
* convenient, but this function can be more efficient if accessing multiple
|
|
|
|
* elements or the same member multiple times.
|
|
|
|
*
|
|
|
|
* @sa drgn_object_slice
|
|
|
|
*
|
|
|
|
* @param[out] res Dereferenced object.
|
|
|
|
* @param[in] obj Pointer object.
|
|
|
|
* @param[in] qualified_type Result type.
|
|
|
|
* @param[in] bit_offset Offset in bits from the address given by the value of
|
|
|
|
* @p obj.
|
|
|
|
* @param[in] bit_field_size If the object should be a bit field, its size in
|
|
|
|
* bits. Otherwise, 0.
|
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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *
|
|
|
|
drgn_object_dereference_offset(struct drgn_object *res,
|
|
|
|
const struct drgn_object *obj,
|
|
|
|
struct drgn_qualified_type qualified_type,
|
|
|
|
int64_t bit_offset, uint64_t bit_field_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
|
|
|
|
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Read a @ref drgn_object.
|
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-12-18 20:20:21 +00:00
|
|
|
* If @c obj is already a value, then this is equivalent to @ref
|
|
|
|
* drgn_object_copy(). If @c is a reference, then this reads the reference and
|
|
|
|
* sets @p res to the value.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[out] res Object to set.
|
|
|
|
* @param[in] obj Object to read.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_object_read(struct drgn_object *res,
|
|
|
|
const struct drgn_object *obj);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Read the value of a @ref drgn_object.
|
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-12-18 20:20:21 +00:00
|
|
|
* If @p obj is a value, that value is returned directly. If @p is a reference,
|
|
|
|
* the value is read into the provided temporary buffer.
|
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-12-18 20:20:21 +00:00
|
|
|
* This must be paired with @ref drgn_object_deinit_value().
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[in] obj Object to read.
|
|
|
|
* @param[in] value Temporary value to use if necessary.
|
|
|
|
* @param[out] ret Pointer to the returned value, which is <tt>&obj->value</tt>
|
|
|
|
* if @p obj is a value, or @p value if @p obj is a reference.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_object_read_value(const struct drgn_object *obj,
|
|
|
|
union drgn_value *value,
|
|
|
|
const union drgn_value **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-12-18 20:20:21 +00:00
|
|
|
/**
|
|
|
|
* Deinitialize a value which was read with @ref drgn_object_read_value().
|
|
|
|
*
|
|
|
|
* @param[in] obj Object which was read.
|
|
|
|
* @param[in] value Value returned from @ref drgn_object_read_value() in @p ret.
|
|
|
|
*/
|
|
|
|
void drgn_object_deinit_value(const struct drgn_object *obj,
|
|
|
|
const union drgn_value *value);
|
2020-12-04 21:20:09 +00:00
|
|
|
|
2021-07-22 10:02:20 +01:00
|
|
|
/**
|
|
|
|
* Get the binary representation of the value of a @ref drgn_object.
|
|
|
|
*
|
|
|
|
* @param[out] Buffer to read into. Size must be at least
|
|
|
|
* `drgn_object_size(obj)`.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_object_read_bytes(const struct drgn_object *obj,
|
|
|
|
void *buf);
|
|
|
|
|
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-12-18 20:20:21 +00:00
|
|
|
* Get the value of an object encoded with @ref
|
|
|
|
* drgn_object_encoding::DRGN_OBJECT_ENCODING_SIGNED.
|
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-12-18 20:20:21 +00:00
|
|
|
* If the object is not a signed integer, an error is returned.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[in] obj Object to read.
|
|
|
|
* @param[out] ret Returned value.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_object_read_signed(const struct drgn_object *obj,
|
|
|
|
int64_t *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-12-18 20:20:21 +00:00
|
|
|
* Get the value of an object encoded with @ref
|
|
|
|
* drgn_object_encoding::DRGN_OBJECT_ENCODING_UNSIGNED.
|
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-12-18 20:20:21 +00:00
|
|
|
* If the object is not an unsigned integer, an error is returned.
|
|
|
|
*
|
|
|
|
* @param[in] obj Object to read.
|
|
|
|
* @param[out] ret Returned value.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_object_read_unsigned(const struct drgn_object *obj,
|
|
|
|
uint64_t *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-12-18 20:20:21 +00:00
|
|
|
/**
|
|
|
|
* Get the value of an object encoded with @ref
|
|
|
|
* drgn_object_encoding::DRGN_OBJECT_ENCODING_SIGNED or @ref
|
|
|
|
* drgn_object_encoding::DRGN_OBJECT_ENCODING_UNSIGNED.
|
|
|
|
*
|
|
|
|
* If the object is not an integer, an error is returned.
|
|
|
|
*
|
|
|
|
* @param[in] obj Object to read.
|
|
|
|
* @param[out] ret Returned value.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_object_read_integer(const struct drgn_object *obj,
|
|
|
|
union drgn_value *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-12-18 20:20:21 +00:00
|
|
|
/**
|
|
|
|
* Get the value of an object encoded with @ref
|
|
|
|
* drgn_object_encoding::DRGN_OBJECT_ENCODING_FLOAT.
|
|
|
|
*
|
|
|
|
* If the object does not have a floating-point type, an error is returned.
|
|
|
|
*
|
|
|
|
* @param[in] obj Object to read.
|
|
|
|
* @param[out] ret Returned value.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_object_read_float(const struct drgn_object *obj,
|
|
|
|
double *ret);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Read the null-terminated string pointed to by a @ref drgn_object.
|
|
|
|
*
|
|
|
|
* This is only valid for pointers and arrays. The element type is ignored; this
|
|
|
|
* operates byte-by-byte.
|
|
|
|
*
|
|
|
|
* For pointers and flexible arrays, this stops at the first null byte.
|
|
|
|
*
|
|
|
|
* For complete arrays, this stops at the first null byte or at the end of the
|
|
|
|
* array.
|
|
|
|
*
|
|
|
|
* The returned string is always null-terminated.
|
|
|
|
*
|
|
|
|
* @param[in] obj Object to read.
|
|
|
|
* @param[out] ret Returned string. On success, it must be freed with @c free().
|
|
|
|
* On error, its contents are undefined.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_object_read_c_string(const struct drgn_object *obj,
|
|
|
|
char **ret);
|
|
|
|
|
|
|
|
/** Flags to control @ref drgn_format_object() output. */
|
|
|
|
enum drgn_format_object_flags {
|
|
|
|
DRGN_FORMAT_OBJECT_DEREFERENCE = 1 << 0,
|
|
|
|
DRGN_FORMAT_OBJECT_SYMBOLIZE = 1 << 1,
|
|
|
|
DRGN_FORMAT_OBJECT_STRING = 1 << 2,
|
|
|
|
DRGN_FORMAT_OBJECT_CHAR = 1 << 3,
|
|
|
|
DRGN_FORMAT_OBJECT_TYPE_NAME = 1 << 4,
|
|
|
|
DRGN_FORMAT_OBJECT_MEMBER_TYPE_NAMES = 1 << 5,
|
|
|
|
DRGN_FORMAT_OBJECT_ELEMENT_TYPE_NAMES = 1 << 6,
|
|
|
|
DRGN_FORMAT_OBJECT_MEMBERS_SAME_LINE = 1 << 7,
|
|
|
|
DRGN_FORMAT_OBJECT_ELEMENTS_SAME_LINE = 1 << 8,
|
|
|
|
DRGN_FORMAT_OBJECT_MEMBER_NAMES = 1 << 9,
|
|
|
|
DRGN_FORMAT_OBJECT_ELEMENT_INDICES = 1 << 10,
|
|
|
|
DRGN_FORMAT_OBJECT_IMPLICIT_MEMBERS = 1 << 11,
|
|
|
|
DRGN_FORMAT_OBJECT_IMPLICIT_ELEMENTS = 1 << 12,
|
|
|
|
/** Default "pretty" flags. */
|
|
|
|
DRGN_FORMAT_OBJECT_PRETTY = (DRGN_FORMAT_OBJECT_DEREFERENCE |
|
|
|
|
DRGN_FORMAT_OBJECT_SYMBOLIZE |
|
|
|
|
DRGN_FORMAT_OBJECT_STRING |
|
|
|
|
DRGN_FORMAT_OBJECT_TYPE_NAME |
|
|
|
|
DRGN_FORMAT_OBJECT_MEMBER_TYPE_NAMES |
|
|
|
|
DRGN_FORMAT_OBJECT_ELEMENTS_SAME_LINE |
|
|
|
|
DRGN_FORMAT_OBJECT_MEMBER_NAMES |
|
|
|
|
DRGN_FORMAT_OBJECT_IMPLICIT_MEMBERS),
|
|
|
|
DRGN_FORMAT_OBJECT_VALID_FLAGS = (1 << 13) - 1,
|
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-12-18 20:20:21 +00:00
|
|
|
* Format a @ref drgn_object as a string.
|
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-12-18 20:20:21 +00:00
|
|
|
* This will format the object similarly to an expression in its programming
|
|
|
|
* language.
|
|
|
|
*
|
|
|
|
* @param[in] obj Object to format.
|
|
|
|
* @param[in] columns Number of columns to limit output to when the expression
|
|
|
|
* can be reasonably wrapped.
|
|
|
|
* param[in] flags Flags to change output.
|
|
|
|
* @param[out] ret Returned string. On success, it must be freed with @c free().
|
|
|
|
* On error, its contents are undefined.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_format_object(const struct drgn_object *obj,
|
|
|
|
size_t columns,
|
|
|
|
enum drgn_format_object_flags flags,
|
|
|
|
char **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-12-18 20:20:21 +00:00
|
|
|
* @defgroup ObjectOperators Operators
|
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-12-18 20:20:21 +00:00
|
|
|
* Object operators.
|
|
|
|
*
|
|
|
|
* Various operators are defined on @ref drgn_object%s. These operators obey the
|
|
|
|
* rules of the programming language of the given objects.
|
|
|
|
*
|
|
|
|
* Operators which return a @ref drgn_object have the same calling convention:
|
|
|
|
* the result object is the first argument, which must be initialized and may be
|
|
|
|
* the same as one or more of the operands; the result is only modified if the
|
|
|
|
* operator succeeds.
|
|
|
|
*
|
|
|
|
* @{
|
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-12-18 20:20:21 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Set a @ref drgn_object to the value of an object casted to a another type.
|
|
|
|
*
|
|
|
|
* Objects with a scalar type can be casted to a different scalar type. Other
|
|
|
|
* objects can only be casted to the same type. @p res is always set to a value
|
|
|
|
* object.
|
|
|
|
*
|
|
|
|
* @sa drgn_object_reinterpret()
|
|
|
|
*
|
|
|
|
* @param[out] res Object to set.
|
|
|
|
* @param[in] qualified_type New type.
|
|
|
|
* @param[in] obj Object to read.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_object_cast(struct drgn_object *res,
|
|
|
|
struct drgn_qualified_type qualified_type,
|
|
|
|
const struct drgn_object *obj);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Set a @ref drgn_object to the value of an object reinterpreted as another
|
|
|
|
* type.
|
|
|
|
*
|
|
|
|
* This reinterprets the raw memory of the object, so an object can be
|
|
|
|
* reinterpreted as any other type. However, value objects with a scalar type
|
|
|
|
* cannot be reinterpreted, as their memory layout is not known.
|
|
|
|
*
|
|
|
|
* If @c obj is a value, then @c res is set to a value; if @c obj was a
|
|
|
|
* reference, then @c res is set to a reference.
|
|
|
|
*
|
|
|
|
* @sa drgn_object_cast()
|
|
|
|
*
|
|
|
|
* @param[out] res Object to set.
|
|
|
|
* @param[in] qualified_type New type.
|
|
|
|
* @param[in] obj Object to reinterpret.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *
|
|
|
|
drgn_object_reinterpret(struct drgn_object *res,
|
|
|
|
struct drgn_qualified_type qualified_type,
|
|
|
|
const struct drgn_object *obj);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @ref drgn_object binary operator.
|
|
|
|
*
|
|
|
|
* Binary operators apply any language-specific conversions to @p lhs and @p
|
|
|
|
* rhs, apply the operator, and store the result in @p res.
|
|
|
|
*
|
|
|
|
* @param[out] res Operator result. May be the same as @p lhs and/or @p rhs.
|
|
|
|
* @param[in] lhs Operator left hand side.
|
|
|
|
* @param[in] rhs Operator right hand side.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error. @p res is not modified on
|
|
|
|
* error.
|
|
|
|
*/
|
|
|
|
typedef struct drgn_error *drgn_binary_op(struct drgn_object *res,
|
|
|
|
const struct drgn_object *lhs,
|
|
|
|
const struct drgn_object *rhs);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @ref drgn_object unary operator.
|
|
|
|
*
|
|
|
|
* Unary operators apply any language-specific conversions to @p obj, apply the
|
|
|
|
* operator, and store the result in @p res.
|
|
|
|
*
|
|
|
|
* @param[out] res Operator result. May be the same as @p obj.
|
|
|
|
* @param[in] obj Operand.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error. @p res is not modified on
|
|
|
|
* error.
|
|
|
|
*/
|
|
|
|
typedef struct drgn_error *drgn_unary_op(struct drgn_object *res,
|
|
|
|
const struct drgn_object *obj);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Convert a @ref drgn_object to a boolean value.
|
|
|
|
*
|
|
|
|
* This gets the "truthiness" of an object according to its programming
|
|
|
|
* language.
|
|
|
|
*
|
|
|
|
* @param[in] obj Object.
|
|
|
|
* @param[out] ret Returned boolean value.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_object_bool(const struct drgn_object *obj, bool *ret);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Compare the value of two @ref drgn_object%s.
|
|
|
|
*
|
|
|
|
* This applies any language-specific conversions to @p lhs and @p rhs and
|
|
|
|
* compares the resulting values.
|
|
|
|
*
|
|
|
|
* @param[in] lhs Comparison left hand side.
|
|
|
|
* @param[in] rhs Comparison right hand side.
|
|
|
|
* @param[out] ret 0 if the operands are equal, < 0 if @p lhs < @p rhs, and > 0
|
|
|
|
* if @p lhs > @p rhs.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_object_cmp(const struct drgn_object *lhs,
|
|
|
|
const struct drgn_object *rhs, int *ret);
|
|
|
|
|
|
|
|
/** Add (@c +) two @ref drgn_object%s. */
|
|
|
|
drgn_binary_op drgn_object_add;
|
|
|
|
/** Subtract (@c -) a @ref drgn_object from another. */
|
|
|
|
drgn_binary_op drgn_object_sub;
|
|
|
|
/** Multiply (@c *) two @ref drgn_object%s. */
|
|
|
|
drgn_binary_op drgn_object_mul;
|
|
|
|
/** Divide (@c /) a @ref drgn_object by another. */
|
|
|
|
drgn_binary_op drgn_object_div;
|
|
|
|
/** Calculate the modulus (@c %) of two @ref drgn_object%s. */
|
|
|
|
drgn_binary_op drgn_object_mod;
|
|
|
|
/** Left shift (@c <<) a @ref drgn_object by another. */
|
|
|
|
drgn_binary_op drgn_object_lshift;
|
|
|
|
/** Right shift (@c >>) a @ref drgn_object by another. */
|
|
|
|
drgn_binary_op drgn_object_rshift;
|
|
|
|
/** Calculate the bitwise and (@c &) of two @ref drgn_object%s. */
|
|
|
|
drgn_binary_op drgn_object_and;
|
|
|
|
/** Calculate the bitwise or (@c |) of two @ref drgn_object%s. */
|
|
|
|
drgn_binary_op drgn_object_or;
|
|
|
|
/** Calculate the bitwise exclusive or (@c ^) of two @ref drgn_object%s. */
|
|
|
|
drgn_binary_op drgn_object_xor;
|
|
|
|
/** Apply unary plus (@c +) to a @ref drgn_object. */
|
|
|
|
drgn_unary_op drgn_object_pos;
|
|
|
|
/** Calculate the arithmetic negation (@c -) of a @ref drgn_object. */
|
|
|
|
drgn_unary_op drgn_object_neg;
|
|
|
|
/** Calculate the bitwise negation (@c ~) of a @ref drgn_object. */
|
|
|
|
drgn_unary_op drgn_object_not;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the address of (@c &) a @ref drgn_object as an object.
|
|
|
|
*
|
|
|
|
* This is only possible for reference objects, as value objects don't have an
|
|
|
|
* address in the program.
|
|
|
|
*
|
|
|
|
* @param[out] res Resulting pointer value. May be the same as @p obj.
|
|
|
|
* @param[in] obj Reference object.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error. @p res is not modified on
|
|
|
|
* error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_object_address_of(struct drgn_object *res,
|
|
|
|
const struct drgn_object *obj);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Subscript (@c []) a @ref drgn_object.
|
|
|
|
*
|
|
|
|
* This is applicable to pointers and arrays.
|
|
|
|
*
|
|
|
|
* @param[out] res Resulting element. May be the same as @p obj.
|
|
|
|
* @param[in] obj Object to subscript.
|
|
|
|
* @param[in] index Element index.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error. @p res is not modified on
|
|
|
|
* error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_object_subscript(struct drgn_object *res,
|
|
|
|
const struct drgn_object *obj,
|
|
|
|
int64_t index);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Deference (@c *) a @ref drgn_object.
|
|
|
|
*
|
|
|
|
* This is equivalent to @ref drgn_object_subscript with an index of 0.
|
|
|
|
*
|
|
|
|
* @param[out] res Deferenced object. May be the same as @p obj.
|
|
|
|
* @param[in] obj Object to dereference.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error. @p res is not modified on
|
|
|
|
* error.
|
|
|
|
*/
|
|
|
|
static inline struct drgn_error *
|
|
|
|
drgn_object_dereference(struct drgn_object *res, const struct drgn_object *obj)
|
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-12-18 20:20:21 +00:00
|
|
|
return drgn_object_subscript(res, obj, 0);
|
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-12-18 20:20:21 +00:00
|
|
|
* Get a member of a structure, union, or class @ref drgn_object (@c .).
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[out] res Returned member. May be the same as @p obj.
|
|
|
|
* @param[in] obj Object.
|
|
|
|
* @param[in] member_name Name of member.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error. @p res is not modified on
|
|
|
|
* error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_object_member(struct drgn_object *res,
|
|
|
|
const struct drgn_object *obj,
|
|
|
|
const char *member_name);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get a member of a pointer @ref drgn_object (@c ->).
|
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-12-18 20:20:21 +00:00
|
|
|
* This is applicable to pointers to structures and pointers to unions.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[out] res Returned member. May be the same as @p obj.
|
|
|
|
* @param[in] obj Object.
|
|
|
|
* @param[in] member_name Name of member.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error. @p res is not modified on
|
|
|
|
* error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_object_member_dereference(struct drgn_object *res,
|
|
|
|
const struct drgn_object *obj,
|
|
|
|
const char *member_name);
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the containing object of a member @ref drgn_object.
|
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-12-18 20:20:21 +00:00
|
|
|
* This corresponds to the @c container_of() macro commonly used in C.
|
|
|
|
*
|
|
|
|
* @param[out] res Returned object. May be the same as @p obj.
|
|
|
|
* @param[in] obj Pointer to a member.
|
|
|
|
* @param[in] qualified_type Type which contains the member.
|
|
|
|
* @param[in] member_designator Name of the member in @p qualified_type. This
|
|
|
|
* can include one or more member references and zero or more array subscripts.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error. @p res is not modified on
|
|
|
|
* error.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *
|
|
|
|
drgn_object_container_of(struct drgn_object *res, const struct drgn_object *obj,
|
|
|
|
struct drgn_qualified_type qualified_type,
|
|
|
|
const char *member_designator);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the size of a @ref drgn_object in bytes.
|
|
|
|
*
|
|
|
|
* @param[in] obj Object.
|
|
|
|
* @param[out] ret Returned size.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_object_sizeof(const struct drgn_object *obj,
|
|
|
|
uint64_t *ret);
|
|
|
|
|
|
|
|
/** @} */
|
|
|
|
|
|
|
|
/** @} */
|
|
|
|
|
|
|
|
/**
|
2020-12-18 19:01:29 +00:00
|
|
|
* @ingroup LazyObjects
|
2020-12-18 20:20:21 +00:00
|
|
|
*
|
2020-12-18 19:01:29 +00:00
|
|
|
* Callback to evaluate and/or free a @ref drgn_lazy_object.
|
2020-12-18 20:20:21 +00:00
|
|
|
*
|
2020-12-18 19:01:29 +00:00
|
|
|
* If @p res is not @c NULL, then this should return the object in @p res and
|
|
|
|
* free @p arg if necessary. If this returns an error, it may be called again
|
|
|
|
* (so @p arg must remain valid).
|
|
|
|
*
|
|
|
|
* If @p res is @c NULL, then this should free @p arg if necessary; it must not
|
|
|
|
* return an error.
|
|
|
|
*
|
|
|
|
* @param[out] res Result object (if evaluating) or @c NULL (if freeing). This
|
|
|
|
* is already initialized and should not be deinitialized on error.
|
|
|
|
* @param[in] arg Callback argument passed to @ref
|
|
|
|
* drgn_lazy_object_init_thunk().
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
typedef struct drgn_error *drgn_object_thunk_fn(struct drgn_object *res,
|
|
|
|
void *arg);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @ingroup LazyObjects
|
|
|
|
*
|
|
|
|
* Lazily-evaluated object.
|
|
|
|
*
|
|
|
|
* A lazy object may be in two states: unevaluated, in which case a callback
|
|
|
|
* must be called to evaluate the object, or evaluated, in which case the object
|
|
|
|
* is cached. To evaluate an object, the callback is called, and the result is
|
|
|
|
* cached.
|
2020-12-18 20:20:21 +00:00
|
|
|
*
|
|
|
|
* This is for internal use only.
|
|
|
|
*/
|
2020-12-18 19:01:29 +00:00
|
|
|
union drgn_lazy_object {
|
|
|
|
/** Object if it has already been evaluated. */
|
|
|
|
struct drgn_object obj;
|
|
|
|
/** Thunk if the object has not been evaluated yet. */
|
|
|
|
struct {
|
|
|
|
/**
|
|
|
|
* Always @c NULL to indicate an unevaluated lazy object.
|
|
|
|
*
|
|
|
|
* This must be at the same offset as @ref drgn_object::type.
|
|
|
|
*/
|
|
|
|
struct drgn_type *dummy_type;
|
|
|
|
/** Program owning this thunk. */
|
|
|
|
struct drgn_program *prog;
|
|
|
|
/** Callback. */
|
|
|
|
drgn_object_thunk_fn *fn;
|
2021-03-16 23:15:43 +00:00
|
|
|
/** Argument passed to @ref drgn_lazy_object::thunk::fn. */
|
2020-12-18 19:01:29 +00:00
|
|
|
void *arg;
|
|
|
|
} thunk;
|
2020-12-18 20:20:21 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @defgroup Types Types
|
|
|
|
*
|
|
|
|
* Type descriptors.
|
|
|
|
*
|
|
|
|
* Types in a program are represented by @ref drgn_type.
|
|
|
|
*
|
|
|
|
* Type descriptors have various fields depending on the kind of type. For each
|
|
|
|
* field @c foo, there is a @c drgn_type_kind_has_foo() helper which returns
|
|
|
|
* whether the given kind of type has the field @c foo; a @c drgn_type_has_foo()
|
|
|
|
* helper which does the same but takes a type; and a @c drgn_type_foo() helper
|
|
|
|
* which returns the field. For members, enumerators, and parameters, there is
|
|
|
|
* also a @c drgn_type_num_foo() helper.
|
|
|
|
*
|
|
|
|
* @{
|
|
|
|
*/
|
|
|
|
|
|
|
|
/** Primitive types known to drgn. */
|
|
|
|
enum drgn_primitive_type {
|
|
|
|
/* Primitive C types. */
|
|
|
|
DRGN_C_TYPE_VOID,
|
|
|
|
DRGN_C_TYPE_CHAR,
|
|
|
|
DRGN_C_TYPE_SIGNED_CHAR,
|
|
|
|
DRGN_C_TYPE_UNSIGNED_CHAR,
|
|
|
|
DRGN_C_TYPE_SHORT,
|
|
|
|
DRGN_C_TYPE_UNSIGNED_SHORT,
|
|
|
|
DRGN_C_TYPE_INT,
|
|
|
|
DRGN_C_TYPE_UNSIGNED_INT,
|
|
|
|
DRGN_C_TYPE_LONG,
|
|
|
|
DRGN_C_TYPE_UNSIGNED_LONG,
|
|
|
|
DRGN_C_TYPE_LONG_LONG,
|
|
|
|
DRGN_C_TYPE_UNSIGNED_LONG_LONG,
|
|
|
|
DRGN_C_TYPE_BOOL,
|
|
|
|
DRGN_C_TYPE_FLOAT,
|
|
|
|
DRGN_C_TYPE_DOUBLE,
|
|
|
|
DRGN_C_TYPE_LONG_DOUBLE,
|
|
|
|
DRGN_C_TYPE_SIZE_T,
|
|
|
|
DRGN_C_TYPE_PTRDIFF_T,
|
|
|
|
DRGN_PRIMITIVE_TYPE_NUM,
|
|
|
|
DRGN_NOT_PRIMITIVE_TYPE = DRGN_PRIMITIVE_TYPE_NUM,
|
|
|
|
/*
|
|
|
|
* Make sure to update api_reference.rst and type.c when adding anything
|
|
|
|
* here.
|
|
|
|
*/
|
2021-02-21 11:16:23 +00:00
|
|
|
} __attribute__((__packed__));
|
2020-12-18 20:20:21 +00:00
|
|
|
|
|
|
|
/** Member of a structure, union, or class type. */
|
|
|
|
struct drgn_type_member {
|
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-12-18 19:01:29 +00:00
|
|
|
* Member as an object.
|
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-12-18 19:01:29 +00:00
|
|
|
* Access this with @ref drgn_member_object() or @ref
|
|
|
|
* drgn_member_type().
|
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-12-18 19:01:29 +00:00
|
|
|
union drgn_lazy_object object;
|
2020-12-18 20:20:21 +00:00
|
|
|
/** Member name or @c NULL if it is unnamed. */
|
|
|
|
const char *name;
|
2020-12-14 10:46:42 +00:00
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Offset in bits from the beginning of the type to the beginning of
|
|
|
|
* this member (i.e., for little-endian machines, the least significant
|
|
|
|
* bit, and for big-endian machines, the most significant bit). Members
|
|
|
|
* are usually aligned to at least a byte, so this is usually a multiple
|
|
|
|
* of 8 (but that may not be the case for bit fields).
|
2020-12-14 10:46:42 +00:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
uint64_t bit_offset;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Value of an enumerated type. */
|
|
|
|
struct drgn_type_enumerator {
|
|
|
|
/** Enumerator name. */
|
|
|
|
const char *name;
|
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
|
|
|
union {
|
2020-12-18 20:20:21 +00:00
|
|
|
/** Enumerator value if the type is signed. */
|
|
|
|
int64_t svalue;
|
|
|
|
/** Enumerator value if the type is unsigned. */
|
|
|
|
uint64_t uvalue;
|
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-12-18 20:20:21 +00:00
|
|
|
/** Parameter of a function type. */
|
|
|
|
struct drgn_type_parameter {
|
|
|
|
/**
|
2020-12-18 19:01:29 +00:00
|
|
|
* Parameter type and default argument.
|
2020-12-18 20:20:21 +00:00
|
|
|
*
|
2020-12-18 19:01:29 +00:00
|
|
|
* Access this with @ref drgn_parameter_default_argument() or @ref
|
|
|
|
* drgn_parameter_type().
|
2020-12-18 20:20:21 +00:00
|
|
|
*/
|
2020-12-18 19:01:29 +00:00
|
|
|
union drgn_lazy_object default_argument;
|
2020-12-18 20:20:21 +00:00
|
|
|
/** Parameter name or @c NULL if it is unnamed. */
|
|
|
|
const char *name;
|
|
|
|
};
|
2019-10-28 18:28:38 +00:00
|
|
|
|
2021-01-09 01:28:27 +00:00
|
|
|
/** Template parameter of a structure, union, class, or function type. */
|
|
|
|
struct drgn_type_template_parameter {
|
|
|
|
/**
|
|
|
|
* Template parameter type or value.
|
|
|
|
*
|
|
|
|
* Access this with @ref drgn_template_parameter_type() and @ref
|
|
|
|
* drgn_template_parameter_object().
|
|
|
|
*/
|
|
|
|
union drgn_lazy_object argument;
|
|
|
|
/** Template parameter name or @c NULL if it is unnamed. */
|
|
|
|
const char *name;
|
|
|
|
/** Whether the argument is the default. */
|
|
|
|
bool is_default;
|
|
|
|
};
|
|
|
|
|
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-12-18 20:20:21 +00:00
|
|
|
* Language-agnostic type descriptor.
|
|
|
|
*
|
|
|
|
* This structure should not be accessed directly; see @ref Types.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_type {
|
|
|
|
/** @privatesection */
|
|
|
|
struct {
|
|
|
|
enum drgn_type_kind kind;
|
|
|
|
bool is_complete;
|
|
|
|
enum drgn_primitive_type primitive;
|
|
|
|
/* These are the qualifiers for the wrapped type, not this type. */
|
|
|
|
enum drgn_qualifiers qualifiers;
|
|
|
|
struct drgn_program *program;
|
|
|
|
const struct drgn_language *language;
|
|
|
|
/*
|
|
|
|
* This mess of unions is used to make this as compact as possible. Use
|
|
|
|
* the provided helpers and don't think about it.
|
|
|
|
*/
|
|
|
|
union {
|
|
|
|
const char *name;
|
|
|
|
const char *tag;
|
|
|
|
size_t num_parameters;
|
|
|
|
};
|
|
|
|
union {
|
|
|
|
uint64_t size;
|
|
|
|
uint64_t length;
|
|
|
|
size_t num_enumerators;
|
|
|
|
bool is_variadic;
|
|
|
|
};
|
|
|
|
union {
|
|
|
|
bool is_signed;
|
|
|
|
size_t num_members;
|
|
|
|
struct drgn_type *type;
|
|
|
|
};
|
|
|
|
union {
|
Track byte order in scalar types instead of objects
Currently, reference objects and buffer value objects have a byte order.
However, this doesn't always make sense for a couple of reasons:
- Byte order is only meaningful for scalars. What does it mean for a
struct to be big endian? A struct doesn't have a most or least
significant byte; its scalar members do.
- The DWARF specification allows either types or variables to have a
byte order (DW_AT_endianity). The only producer I could find that uses
this is GCC for the scalar_storage_order type attribute, and it only
uses it for base types, not variables. GDB only seems to use to check
it for base types, as well.
So, remove the byte order from objects, and move it to integer, boolean,
floating-point, and pointer types. This model makes more sense, and it
means that we can get the binary representation of any object now.
The only downside is that we can no longer support a bit offset for
non-scalars, but as far as I can tell, nothing needs that.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-02-18 00:13:23 +00:00
|
|
|
bool little_endian;
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_type_member *members;
|
|
|
|
struct drgn_type_enumerator *enumerators;
|
|
|
|
struct drgn_type_parameter *parameters;
|
|
|
|
};
|
2021-01-09 01:28:27 +00:00
|
|
|
struct drgn_type_template_parameter *template_parameters;
|
|
|
|
size_t num_template_parameters;
|
2020-12-18 20:20:21 +00:00
|
|
|
} _private;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Get the kind of a type. */
|
|
|
|
static inline enum drgn_type_kind drgn_type_kind(struct drgn_type *type)
|
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-12-18 20:20:21 +00:00
|
|
|
return type->_private.kind;
|
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-12-18 20:20:21 +00:00
|
|
|
/** Get the primitive type corresponding to a @ref drgn_type. */
|
|
|
|
static inline enum drgn_primitive_type
|
|
|
|
drgn_type_primitive(struct drgn_type *type)
|
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-12-18 20:20:21 +00:00
|
|
|
return type->_private.primitive;
|
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-12-18 20:20:21 +00:00
|
|
|
* Get whether a type is complete (i.e., the type definition is known).
|
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-12-18 20:20:21 +00:00
|
|
|
* This is always @c false for the void type. It may be @c false for structure,
|
|
|
|
* union, class, enumerated, and array types, as well as typedef types where the
|
|
|
|
* underlying type is one of those. Otherwise, it is always @c true.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_type_is_complete(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
return type->_private.is_complete;
|
|
|
|
}
|
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-27 19:26:39 +01:00
|
|
|
static inline struct drgn_program *
|
2020-12-18 20:20:21 +00:00
|
|
|
drgn_type_program(struct drgn_type *type)
|
2020-08-27 19:26:39 +01:00
|
|
|
{
|
2020-12-18 20:20:21 +00:00
|
|
|
return type->_private.program;
|
2020-08-27 19:26:39 +01:00
|
|
|
}
|
2020-02-26 21:22:51 +00:00
|
|
|
|
2020-12-18 20:20:21 +00:00
|
|
|
/** Get the language of a type. */
|
2020-02-26 21:22:51 +00:00
|
|
|
static inline const struct drgn_language *
|
2020-12-18 20:20:21 +00:00
|
|
|
drgn_type_language(struct drgn_type *type)
|
2020-02-26 21:22:51 +00:00
|
|
|
{
|
2020-12-18 20:20:21 +00:00
|
|
|
return type->_private.language;
|
2020-02-26 21:22:51 +00: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
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Get whether a kind of type has a name. This is true for integer, boolean,
|
2021-02-17 22:56:33 +00:00
|
|
|
* floating-point, and typedef types.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_type_kind_has_name(enum drgn_type_kind kind)
|
|
|
|
{
|
|
|
|
return (kind == DRGN_TYPE_INT ||
|
|
|
|
kind == DRGN_TYPE_BOOL ||
|
|
|
|
kind == DRGN_TYPE_FLOAT ||
|
|
|
|
kind == DRGN_TYPE_TYPEDEF);
|
|
|
|
}
|
|
|
|
/** Get whether a type has a name. @sa drgn_type_kind_has_name() */
|
|
|
|
static inline bool drgn_type_has_name(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
return drgn_type_kind_has_name(drgn_type_kind(type));
|
|
|
|
}
|
|
|
|
/**
|
|
|
|
* Get the name of a type. @ref drgn_type_has_name() must be true for this type.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline const char *drgn_type_name(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_name(type));
|
|
|
|
return type->_private.name;
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get whether a kind of type has a size. This is true for integer, boolean,
|
2021-02-17 22:56:33 +00:00
|
|
|
* floating-point, structure, union, class, and pointer types.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_type_kind_has_size(enum drgn_type_kind kind)
|
|
|
|
{
|
|
|
|
return (kind == DRGN_TYPE_INT ||
|
|
|
|
kind == DRGN_TYPE_BOOL ||
|
|
|
|
kind == DRGN_TYPE_FLOAT ||
|
|
|
|
kind == DRGN_TYPE_STRUCT ||
|
|
|
|
kind == DRGN_TYPE_UNION ||
|
|
|
|
kind == DRGN_TYPE_CLASS ||
|
|
|
|
kind == DRGN_TYPE_POINTER);
|
|
|
|
}
|
|
|
|
/** Get whether a type has a size. @sa drgn_type_kind_has_size() */
|
|
|
|
static inline bool drgn_type_has_size(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
return drgn_type_kind_has_size(drgn_type_kind(type));
|
|
|
|
}
|
2020-12-04 21:27:01 +00:00
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Get the size of a type in bytes. @ref drgn_type_has_size() must be true for
|
|
|
|
* this type.
|
2020-12-04 21:27:01 +00:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
static inline uint64_t drgn_type_size(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_size(type));
|
|
|
|
return type->_private.size;
|
|
|
|
}
|
2020-12-04 21:27:01 +00: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
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Get whether a kind of type has a signedness. This is true for integer types.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_type_kind_has_is_signed(enum drgn_type_kind kind)
|
|
|
|
{
|
|
|
|
return kind == DRGN_TYPE_INT;
|
|
|
|
}
|
|
|
|
/** Get whether a type has a signedness. @sa drgn_type_kind_has_is_signed() */
|
|
|
|
static inline bool drgn_type_has_is_signed(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
return drgn_type_kind_has_is_signed(drgn_type_kind(type));
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get the signedness of a type. @ref drgn_type_has_is_signed() must be true for
|
|
|
|
* this type.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_type_is_signed(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_is_signed(type));
|
|
|
|
return type->_private.is_signed;
|
|
|
|
}
|
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
|
|
|
|
Track byte order in scalar types instead of objects
Currently, reference objects and buffer value objects have a byte order.
However, this doesn't always make sense for a couple of reasons:
- Byte order is only meaningful for scalars. What does it mean for a
struct to be big endian? A struct doesn't have a most or least
significant byte; its scalar members do.
- The DWARF specification allows either types or variables to have a
byte order (DW_AT_endianity). The only producer I could find that uses
this is GCC for the scalar_storage_order type attribute, and it only
uses it for base types, not variables. GDB only seems to use to check
it for base types, as well.
So, remove the byte order from objects, and move it to integer, boolean,
floating-point, and pointer types. This model makes more sense, and it
means that we can get the binary representation of any object now.
The only downside is that we can no longer support a bit offset for
non-scalars, but as far as I can tell, nothing needs that.
Signed-off-by: Omar Sandoval <osandov@osandov.com>
2021-02-18 00:13:23 +00:00
|
|
|
/**
|
|
|
|
* Get whether a kind of type has a byte order. This is true for integer,
|
|
|
|
* boolean, floating-point, and pointer types.
|
|
|
|
*/
|
|
|
|
static inline bool drgn_type_kind_has_little_endian(enum drgn_type_kind kind)
|
|
|
|
{
|
|
|
|
return (kind == DRGN_TYPE_INT ||
|
|
|
|
kind == DRGN_TYPE_BOOL ||
|
|
|
|
kind == DRGN_TYPE_FLOAT ||
|
|
|
|
kind == DRGN_TYPE_POINTER);
|
|
|
|
}
|
|
|
|
/**
|
|
|
|
* Get whether a type has a byte order. @sa drgn_type_kind_has_little_endian()
|
|
|
|
*/
|
|
|
|
static inline bool drgn_type_has_little_endian(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
return drgn_type_kind_has_little_endian(drgn_type_kind(type));
|
|
|
|
}
|
|
|
|
/**
|
|
|
|
* Get the byte order of a type. @ref drgn_type_has_little_endian() must be true
|
|
|
|
* for this type.
|
|
|
|
*
|
|
|
|
* @return @c true if the type is little-endian, @c false if it is big-endian.
|
|
|
|
*/
|
|
|
|
static inline bool drgn_type_little_endian(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_little_endian(type));
|
|
|
|
return type->_private.little_endian;
|
|
|
|
}
|
|
|
|
|
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-12-18 20:20:21 +00:00
|
|
|
* Get whether a kind of type has a tag. This is true for structure, union,
|
|
|
|
* class, and enumerated types.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_type_kind_has_tag(enum drgn_type_kind kind)
|
|
|
|
{
|
|
|
|
return (kind == DRGN_TYPE_STRUCT ||
|
|
|
|
kind == DRGN_TYPE_UNION ||
|
|
|
|
kind == DRGN_TYPE_CLASS ||
|
|
|
|
kind == DRGN_TYPE_ENUM);
|
|
|
|
}
|
|
|
|
/** Get whether a type has a tag. @sa drgn_type_kind_has_tag() */
|
|
|
|
static inline bool drgn_type_has_tag(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
return drgn_type_kind_has_tag(drgn_type_kind(type));
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get the tag of a type. @ref drgn_type_has_tag() must be true for this type.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline const char *drgn_type_tag(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_tag(type));
|
|
|
|
return type->_private.tag;
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get whether a kind of type has members. This is true for structure, union,
|
|
|
|
* and class types.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_type_kind_has_members(enum drgn_type_kind kind)
|
|
|
|
{
|
|
|
|
return (kind == DRGN_TYPE_STRUCT ||
|
|
|
|
kind == DRGN_TYPE_UNION ||
|
|
|
|
kind == DRGN_TYPE_CLASS);
|
|
|
|
}
|
|
|
|
/** Get whether a type has members. @sa drgn_type_kind_has_members() */
|
|
|
|
static inline bool drgn_type_has_members(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
return drgn_type_kind_has_members(drgn_type_kind(type));
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get the members of a type. @ref drgn_type_has_members() must be true for this
|
|
|
|
* type.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline struct drgn_type_member *drgn_type_members(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_members(type));
|
|
|
|
return type->_private.members;
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get the number of members of a type. @ref drgn_type_has_members() must be
|
|
|
|
* true for this type. If the type is incomplete, this is always zero.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline size_t drgn_type_num_members(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_members(type));
|
|
|
|
return type->_private.num_members;
|
|
|
|
}
|
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
|
|
|
|
|
|
|
/**
|
2021-02-17 22:56:33 +00:00
|
|
|
* Get whether a kind of type has a wrapped type. This is true for enumerated,
|
|
|
|
* typedef, pointer, array, and function types.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_type_kind_has_type(enum drgn_type_kind kind)
|
|
|
|
{
|
2021-02-17 22:56:33 +00:00
|
|
|
return (kind == DRGN_TYPE_ENUM ||
|
2020-12-18 20:20:21 +00:00
|
|
|
kind == DRGN_TYPE_TYPEDEF ||
|
|
|
|
kind == DRGN_TYPE_POINTER ||
|
|
|
|
kind == DRGN_TYPE_ARRAY ||
|
|
|
|
kind == DRGN_TYPE_FUNCTION);
|
|
|
|
}
|
|
|
|
/** Get whether a type has a wrapped type. @sa drgn_type_kind_has_type() */
|
|
|
|
static inline bool drgn_type_has_type(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
return drgn_type_kind_has_type(drgn_type_kind(type));
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get the type wrapped by this type.
|
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-12-18 20:20:21 +00:00
|
|
|
* For an enumerated type, this is the compatible integer type. It is @c NULL if
|
|
|
|
* the enumerated type is incomplete.
|
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-12-18 20:20:21 +00:00
|
|
|
* For a typedef type, this is the aliased type.
|
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-12-18 20:20:21 +00:00
|
|
|
* For a pointer type, this is the referenced type.
|
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-12-18 20:20:21 +00:00
|
|
|
* For an array type, this is the element type.
|
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-12-18 20:20:21 +00:00
|
|
|
* For a function type, this is the return type.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline struct drgn_qualified_type
|
|
|
|
drgn_type_type(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_type(type));
|
|
|
|
return (struct drgn_qualified_type){
|
|
|
|
.type = type->_private.type,
|
|
|
|
.qualifiers = type->_private.qualifiers,
|
|
|
|
};
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get whether a kind of type has enumerators. This is true for enumerated
|
|
|
|
* types.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_type_kind_has_enumerators(enum drgn_type_kind kind)
|
|
|
|
{
|
|
|
|
return kind == DRGN_TYPE_ENUM;
|
|
|
|
}
|
|
|
|
/** Get whether a type has enumerators. @sa drgn_type_kind_has_enumerators() */
|
|
|
|
static inline bool drgn_type_has_enumerators(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
return drgn_type_kind_has_enumerators(drgn_type_kind(type));
|
|
|
|
}
|
2019-10-28 20:00:11 +00:00
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Get the enumerators of a type. @ref drgn_type_has_enumerators() must be true
|
|
|
|
* for this type.
|
2019-10-28 20:00:11 +00:00
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
static inline struct drgn_type_enumerator *
|
|
|
|
drgn_type_enumerators(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_enumerators(type));
|
|
|
|
return type->_private.enumerators;
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get the number of enumerators of a type. @ref drgn_type_has_enumerators()
|
|
|
|
* must be true for this type. If the type is incomplete, this is always zero.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline size_t drgn_type_num_enumerators(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_enumerators(type));
|
|
|
|
return type->_private.num_enumerators;
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
/** Get whether a kind of type has a length. This is true for array types. */
|
|
|
|
static inline bool drgn_type_kind_has_length(enum drgn_type_kind kind)
|
|
|
|
{
|
|
|
|
return kind == DRGN_TYPE_ARRAY;
|
|
|
|
}
|
|
|
|
/** Get whether a type has a length. @sa drgn_type_kind_has_length() */
|
|
|
|
static inline bool drgn_type_has_length(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
return drgn_type_kind_has_length(drgn_type_kind(type));
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get the length of a type. @ref drgn_type_has_length() must be true for this
|
|
|
|
* type. If the type is incomplete, this is always zero.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline uint64_t drgn_type_length(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_length(type));
|
|
|
|
return type->_private.length;
|
|
|
|
}
|
2019-12-06 08:50:11 +00: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
|
|
|
/**
|
2020-12-18 20:20:21 +00:00
|
|
|
* Get whether a kind of type has parameters. This is true for function types.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_type_kind_has_parameters(enum drgn_type_kind kind)
|
|
|
|
{
|
|
|
|
return kind == DRGN_TYPE_FUNCTION;
|
|
|
|
}
|
|
|
|
/** Get whether a type has parameters. @sa drgn_type_kind_has_parameters() */
|
|
|
|
static inline bool drgn_type_has_parameters(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
return drgn_type_kind_has_parameters(drgn_type_kind(type));
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get the parameters of a type. @ref drgn_type_has_parameters() must be true
|
|
|
|
* for this type.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline struct drgn_type_parameter *drgn_type_parameters(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_parameters(type));
|
|
|
|
return type->_private.parameters;
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get the number of parameters of a type. @ref drgn_type_has_parameters() must
|
|
|
|
* be true for this type.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline size_t drgn_type_num_parameters(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_parameters(type));
|
|
|
|
return type->_private.num_parameters;
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get whether a kind of type can be variadic. This is true for function types.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_type_kind_has_is_variadic(enum drgn_type_kind kind)
|
|
|
|
{
|
|
|
|
return kind == DRGN_TYPE_FUNCTION;
|
|
|
|
}
|
|
|
|
/** Get whether a type can be variadic. @sa drgn_type_kind_has_is_variadic() */
|
|
|
|
static inline bool drgn_type_has_is_variadic(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
return drgn_type_kind_has_is_variadic(drgn_type_kind(type));
|
|
|
|
}
|
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-12-18 20:20:21 +00:00
|
|
|
* Get whether a type is variadic. @ref drgn_type_has_is_variadic() must be true
|
|
|
|
* for this type.
|
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-12-18 20:20:21 +00:00
|
|
|
static inline bool drgn_type_is_variadic(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_is_variadic(type));
|
|
|
|
return type->_private.is_variadic;
|
|
|
|
}
|
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
|
|
|
|
2021-01-09 01:28:27 +00:00
|
|
|
/** Get whether a kind of type can have template parameters. */
|
|
|
|
static inline bool
|
|
|
|
drgn_type_kind_has_template_parameters(enum drgn_type_kind kind)
|
|
|
|
{
|
|
|
|
return (kind == DRGN_TYPE_STRUCT ||
|
|
|
|
kind == DRGN_TYPE_UNION ||
|
|
|
|
kind == DRGN_TYPE_CLASS ||
|
|
|
|
kind == DRGN_TYPE_FUNCTION);
|
|
|
|
}
|
|
|
|
|
|
|
|
/** Get whether a type can have template parameters. */
|
|
|
|
static inline bool drgn_type_has_template_parameters(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
return drgn_type_kind_has_template_parameters(drgn_type_kind(type));
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the template parameters of a type. @ref
|
|
|
|
* drgn_type_has_template_parameters() must be true for this type.
|
|
|
|
*/
|
|
|
|
static inline struct drgn_type_template_parameter *
|
|
|
|
drgn_type_template_parameters(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_template_parameters(type));
|
|
|
|
return type->_private.template_parameters;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the number of template parameters of a type. @ref
|
|
|
|
* drgn_type_has_template_parameters() must be true for this type.
|
|
|
|
*/
|
|
|
|
static inline size_t drgn_type_num_template_parameters(struct drgn_type *type)
|
|
|
|
{
|
|
|
|
assert(drgn_type_has_template_parameters(type));
|
|
|
|
return type->_private.num_template_parameters;
|
|
|
|
}
|
|
|
|
|
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-12-18 19:01:29 +00:00
|
|
|
* Get the object corresponding to a @ref drgn_type_member.
|
|
|
|
*
|
|
|
|
* @param[in] member Member.
|
|
|
|
* @param[out] ret Returned object.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_member_object(struct drgn_type_member *member,
|
|
|
|
const struct drgn_object **ret)
|
|
|
|
__attribute__((__nonnull__(1, 2)));
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the type of a @ref drgn_type_member.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[in] member Member.
|
2020-12-18 22:11:29 +00:00
|
|
|
* @param[out] type_ret Returned type.
|
|
|
|
* @param[out] bit_field_size_ret If the member is a bit field, returned size of
|
|
|
|
* the field in bits. Otherwise, returned as 0. Can be @c NULL if not needed.
|
2020-12-18 20:20:21 +00:00
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_member_type(struct drgn_type_member *member,
|
2020-12-18 22:11:29 +00:00
|
|
|
struct drgn_qualified_type *type_ret,
|
|
|
|
uint64_t *bit_field_size_ret)
|
|
|
|
__attribute__((__nonnull__(1, 2)));
|
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-12-18 19:01:29 +00:00
|
|
|
* Get the default argument of a @ref drgn_type_parameter.
|
|
|
|
*
|
|
|
|
* @param[in] parameter Parameter.
|
|
|
|
* @param[out] ret Returned object.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *
|
|
|
|
drgn_parameter_default_argument(struct drgn_type_parameter *parameter,
|
|
|
|
const struct drgn_object **ret)
|
|
|
|
__attribute__((__nonnull__(1, 2)));
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the type of a @ref drgn_type_parameter.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[in] parameter Parameter.
|
|
|
|
* @param[out] ret Returned type.
|
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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_parameter_type(struct drgn_type_parameter *parameter,
|
2020-12-18 19:01:29 +00:00
|
|
|
struct drgn_qualified_type *ret)
|
|
|
|
__attribute__((__nonnull__(1, 2)));
|
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
|
|
|
|
2021-01-09 01:28:27 +00:00
|
|
|
/**
|
|
|
|
* Get the type of a @ref drgn_type_template_parameter.
|
|
|
|
*
|
|
|
|
* If the template parameter is a non-type template parameter, this is the type
|
|
|
|
* of its value.
|
|
|
|
*
|
|
|
|
* @param[in] parameter Template parameter.
|
|
|
|
* @param[out] ret Returned type.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *
|
|
|
|
drgn_template_parameter_type(struct drgn_type_template_parameter *parameter,
|
|
|
|
struct drgn_qualified_type *ret)
|
|
|
|
__attribute__((__nonnull__(1, 2)));
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the value of a @ref drgn_type_template_parameter.
|
|
|
|
*
|
|
|
|
* @param[in] parameter Template parameter.
|
|
|
|
* @param[out] ret Returned object. If @p parameter is a type template
|
|
|
|
* parameter, this is returned as @c NULL.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *
|
|
|
|
drgn_template_parameter_object(struct drgn_type_template_parameter *parameter,
|
|
|
|
const struct drgn_object **ret)
|
|
|
|
__attribute__((__nonnull__(1, 2)));
|
|
|
|
|
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-12-18 20:20:21 +00:00
|
|
|
* Get the size of a type in bytes.
|
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-12-18 20:20:21 +00:00
|
|
|
* Unlike @ref drgn_type_size(), this is applicable to any type which has a
|
|
|
|
* meaningful size, including typedefs and arrays. Void, function, and
|
|
|
|
* incomplete types do not have a size; an error is returned for those types.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[in] type Type.
|
|
|
|
* @param[out] ret Returned 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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_type_sizeof(struct drgn_type *type, uint64_t *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-12-18 20:20:21 +00:00
|
|
|
* Get the offset in bytes of a member from the start of a structure, union, or
|
|
|
|
* class type.
|
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-12-18 20:20:21 +00:00
|
|
|
* This corresponds to @c offsetof() in C.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[in] type Type which contains the member.
|
|
|
|
* @param[in] member_designator Name of the member in @p type. This can include
|
|
|
|
* one or more member references and zero or more array subscripts.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_type_offsetof(struct drgn_type *type,
|
|
|
|
const char *member_designator,
|
|
|
|
uint64_t *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-12-18 20:20:21 +00:00
|
|
|
* Like @ref drgn_type_find_member(), but takes the length of @p member_name.
|
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-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *
|
|
|
|
drgn_type_find_member_len(struct drgn_type *type, const char *member_name,
|
|
|
|
size_t member_name_len,
|
|
|
|
struct drgn_type_member **member_ret,
|
|
|
|
uint64_t *bit_offset_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-12-18 20:20:21 +00:00
|
|
|
* Find a member in a @ref drgn_type by name.
|
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-12-18 20:20:21 +00:00
|
|
|
* If the type has any unnamed members, this also matches members of those
|
|
|
|
* unnamed members, recursively.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[in] type Structure, union, or class type.
|
|
|
|
* @param[in] member_name Name of member.
|
|
|
|
* @param[out] member_ret Returned member.
|
2021-03-16 23:15:43 +00:00
|
|
|
* @param[out] bit_offset_ret Returned offset in bits from the beginning of @p
|
|
|
|
* type to the beginning of the member. This can be different from @ref
|
2020-12-18 20:20:21 +00:00
|
|
|
* drgn_type_member::bit_offset if the returned member was found in an unnamed
|
|
|
|
* member of @p type.
|
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
|
|
|
*/
|
|
|
|
static inline struct drgn_error *
|
2020-12-18 20:20:21 +00:00
|
|
|
drgn_type_find_member(struct drgn_type *type, const char *member_name,
|
|
|
|
struct drgn_type_member **member_ret,
|
|
|
|
uint64_t *bit_offset_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-12-18 20:20:21 +00:00
|
|
|
return drgn_type_find_member_len(type, member_name, strlen(member_name),
|
|
|
|
member_ret, bit_offset_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-12-18 20:20:21 +00:00
|
|
|
/** Like @ref drgn_type_has_member(), but takes the length of @p member_name. */
|
|
|
|
struct drgn_error *drgn_type_has_member_len(struct drgn_type *type,
|
|
|
|
const char *member_name,
|
|
|
|
size_t member_name_len, 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-12-18 20:20:21 +00:00
|
|
|
* Return whether a @ref drgn_type has a member with the given name.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[in] type Structure, union, or class type.
|
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
|
|
|
* @param[in] member_name Name of member.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
static inline struct drgn_error *drgn_type_has_member(struct drgn_type *type,
|
|
|
|
const char *member_name,
|
|
|
|
bool *ret)
|
|
|
|
{
|
|
|
|
return drgn_type_has_member_len(type, member_name, strlen(member_name),
|
|
|
|
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-12-18 20:20:21 +00:00
|
|
|
* Format the name of a type as a string.
|
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-12-18 20:20:21 +00:00
|
|
|
* This will format the name of the type as it would be referred to in its
|
|
|
|
* programming language.
|
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-12-18 20:20:21 +00:00
|
|
|
* @param[in] qualified_type Type to format.
|
|
|
|
* @param[out] ret Returned string. On success, it must be freed with @c free().
|
|
|
|
* On error, its contents are undefined.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
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 *
|
2020-12-18 20:20:21 +00:00
|
|
|
drgn_format_type_name(struct drgn_qualified_type qualified_type, char **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-12-18 20:20:21 +00:00
|
|
|
* Format the definition of a type as a string.
|
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-12-18 20:20:21 +00:00
|
|
|
* This will format the type as it would be defined in its programming language.
|
|
|
|
*
|
|
|
|
* @param[in] qualified_type Type to format.
|
|
|
|
* @param[out] ret Returned string. On success, it must be freed with @c free().
|
|
|
|
* On error, its contents are undefined.
|
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
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-12-18 20:20:21 +00:00
|
|
|
struct drgn_error *drgn_format_type(struct drgn_qualified_type qualified_type,
|
|
|
|
char **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
|
|
|
|
|
|
|
/** @} */
|
|
|
|
|
2019-07-25 08:47:13 +01:00
|
|
|
/**
|
|
|
|
* @defgroup Symbols Symbols
|
|
|
|
*
|
|
|
|
* Symbol table entries.
|
|
|
|
*
|
2020-02-07 16:42:25 +00:00
|
|
|
* @sa drgn_program_find_symbol_by_address()
|
2019-07-25 08:47:13 +01:00
|
|
|
*
|
|
|
|
* @{
|
|
|
|
*/
|
|
|
|
|
2021-08-19 22:12:44 +01:00
|
|
|
/** Symbol linkage behavior and visibility. */
|
|
|
|
enum drgn_symbol_binding {
|
|
|
|
DRGN_SYMBOL_BINDING_UNKNOWN,
|
|
|
|
/*
|
|
|
|
* These values match the ELF STB_* definitions (offset by 1). This is
|
|
|
|
* an implementation detail; future values may not correspond 1:1 with
|
|
|
|
* ELF definitions.
|
|
|
|
*/
|
|
|
|
DRGN_SYMBOL_BINDING_LOCAL,
|
|
|
|
DRGN_SYMBOL_BINDING_GLOBAL,
|
|
|
|
DRGN_SYMBOL_BINDING_WEAK,
|
|
|
|
DRGN_SYMBOL_BINDING_UNIQUE = 11, /* STB_GNU_UNIQUE + 1 */
|
|
|
|
};
|
|
|
|
|
|
|
|
/** Kind of entity represented by a symbol. */
|
|
|
|
enum drgn_symbol_kind {
|
|
|
|
/*
|
|
|
|
* Like enum drgn_symbol_binding, these values match the ELF STT_*
|
|
|
|
* definitions, but this will not necessarily be true for future values.
|
|
|
|
*/
|
|
|
|
DRGN_SYMBOL_KIND_UNKNOWN,
|
|
|
|
DRGN_SYMBOL_KIND_OBJECT,
|
|
|
|
DRGN_SYMBOL_KIND_FUNC,
|
|
|
|
DRGN_SYMBOL_KIND_SECTION,
|
|
|
|
DRGN_SYMBOL_KIND_FILE,
|
|
|
|
DRGN_SYMBOL_KIND_COMMON,
|
|
|
|
DRGN_SYMBOL_KIND_TLS,
|
|
|
|
DRGN_SYMBOL_KIND_IFUNC = 10, /* STT_GNU_IFUNC */
|
|
|
|
};
|
|
|
|
|
2019-07-25 08:47:13 +01:00
|
|
|
/** Destroy a @ref drgn_symbol. */
|
|
|
|
void drgn_symbol_destroy(struct drgn_symbol *sym);
|
|
|
|
|
2021-08-02 21:34:30 +01:00
|
|
|
/**
|
|
|
|
* Destroy each @ref drgn_symbol in @syms, and free the array.
|
|
|
|
*
|
|
|
|
* This will ignore any @c NULL entry in the array, allowing you to take
|
|
|
|
* ownership of any symbol from the array prior to freeing the rest. For each
|
|
|
|
* symbol you take ownership of, you must free it with @ref
|
|
|
|
* drgn_symbol_destroy().
|
|
|
|
*/
|
|
|
|
void drgn_symbols_destroy(struct drgn_symbol **syms, size_t count);
|
|
|
|
|
2019-07-25 08:47:13 +01:00
|
|
|
/**
|
|
|
|
* Get the name of a @ref drgn_symbol.
|
|
|
|
*
|
|
|
|
* The returned string is valid until @p sym is destroyed. It should not be
|
|
|
|
* freed.
|
|
|
|
*/
|
|
|
|
const char *drgn_symbol_name(struct drgn_symbol *sym);
|
|
|
|
|
|
|
|
/** Get the start address of a @ref drgn_symbol. */
|
|
|
|
uint64_t drgn_symbol_address(struct drgn_symbol *sym);
|
|
|
|
|
|
|
|
/** Get the size in bytes of a @ref drgn_symbol. */
|
|
|
|
uint64_t drgn_symbol_size(struct drgn_symbol *sym);
|
|
|
|
|
2021-08-19 22:12:44 +01:00
|
|
|
/** Get the binding of a @ref drgn_symbol. */
|
|
|
|
enum drgn_symbol_binding drgn_symbol_binding(struct drgn_symbol *sym);
|
|
|
|
|
|
|
|
/** Get the kind of a @ref drgn_symbol. */
|
|
|
|
enum drgn_symbol_kind drgn_symbol_kind(struct drgn_symbol *sym);
|
|
|
|
|
2019-07-25 08:47:13 +01:00
|
|
|
/** Return whether two symbols are identical. */
|
|
|
|
bool drgn_symbol_eq(struct drgn_symbol *a, struct drgn_symbol *b);
|
|
|
|
|
|
|
|
/** @} */
|
|
|
|
|
2019-07-29 22:41:33 +01:00
|
|
|
/**
|
|
|
|
* @defgroup StackTraces Stack traces
|
|
|
|
*
|
|
|
|
* Call stacks and stack frames.
|
|
|
|
*
|
|
|
|
* @{
|
|
|
|
*/
|
|
|
|
|
2023-05-23 22:45:03 +01:00
|
|
|
struct drgn_stack_trace; // IWYU pragma: export
|
2019-10-18 10:42:02 +01:00
|
|
|
|
2019-07-29 22:41:33 +01:00
|
|
|
/** Destroy a @ref drgn_stack_trace. */
|
|
|
|
void drgn_stack_trace_destroy(struct drgn_stack_trace *trace);
|
|
|
|
|
2022-08-11 22:42:21 +01:00
|
|
|
/** Get the @ref drgn_program that a @ref drgn_stack_trace came from. */
|
|
|
|
struct drgn_program *drgn_stack_trace_program(struct drgn_stack_trace *trace);
|
|
|
|
|
2019-07-29 22:41:33 +01:00
|
|
|
/** Get the number of stack frames in a stack trace. */
|
|
|
|
size_t drgn_stack_trace_num_frames(struct drgn_stack_trace *trace);
|
|
|
|
|
|
|
|
/**
|
2019-11-28 03:27:14 +00:00
|
|
|
* Format a stack trace as a string.
|
2019-07-29 22:41:33 +01:00
|
|
|
*
|
|
|
|
* @param[out] ret Returned string. On success, it must be freed with @c free().
|
|
|
|
* On error, its contents are undefined.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2019-11-28 03:27:14 +00:00
|
|
|
struct drgn_error *drgn_format_stack_trace(struct drgn_stack_trace *trace,
|
|
|
|
char **ret);
|
2019-07-29 22:41:33 +01:00
|
|
|
|
2021-03-10 09:51:33 +00:00
|
|
|
/** Return whether a stack frame was interrupted (e.g., by a signal). */
|
|
|
|
bool drgn_stack_frame_interrupted(struct drgn_stack_trace *trace, size_t frame);
|
|
|
|
|
2020-12-02 19:24:05 +00:00
|
|
|
/**
|
|
|
|
* Format a stack frame as a string.
|
|
|
|
*
|
|
|
|
* @param[out] ret Returned string. On success, it must be freed with @c free().
|
|
|
|
* On error, its contents are undefined.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_format_stack_frame(struct drgn_stack_trace *trace,
|
|
|
|
size_t frame, char **ret);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the name of the function at a stack frame.
|
|
|
|
*
|
|
|
|
* @return Function name. This is valid until the stack trace is destroyed; it
|
|
|
|
* should not be freed. @c NULL if the name could not be determined.
|
|
|
|
*/
|
|
|
|
const char *drgn_stack_frame_name(struct drgn_stack_trace *trace, size_t frame);
|
|
|
|
|
|
|
|
/** Return whether a stack frame is for an inlined call. */
|
|
|
|
bool drgn_stack_frame_is_inline(struct drgn_stack_trace *trace, size_t frame);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the source code location of a stack frame.
|
|
|
|
*
|
|
|
|
* @param[out] line_ret Returned line number. Returned as 0 if unknown. May be
|
|
|
|
* @c NULL if not needed.
|
|
|
|
* @param[out] column_ret Returned column number. Returned as 0 if unknown. May
|
|
|
|
* be @c NULL if not needed.
|
|
|
|
* @return Filename. This is valid until the stack trace is destroyed; it should
|
|
|
|
* not be freed. @c NULL if the location could not be determined (in which case
|
|
|
|
* `*line_ret` and `*column_ret` are undefined).
|
|
|
|
*/
|
|
|
|
const char *drgn_stack_frame_source(struct drgn_stack_trace *trace,
|
|
|
|
size_t frame, int *line_ret,
|
|
|
|
int *column_ret);
|
|
|
|
|
2021-03-10 09:51:33 +00:00
|
|
|
/**
|
|
|
|
* Get the program counter at a stack frame.
|
|
|
|
*
|
2021-03-16 23:15:43 +00:00
|
|
|
* @param[out] ret Returned program counter.
|
2021-03-10 09:51:33 +00:00
|
|
|
* @return @c true if the program counter is known, @c false if it is not.
|
|
|
|
*/
|
|
|
|
bool drgn_stack_frame_pc(struct drgn_stack_trace *trace, size_t frame,
|
|
|
|
uint64_t *ret);
|
2019-07-29 22:41:33 +01:00
|
|
|
|
2022-11-23 00:51:44 +00:00
|
|
|
/**
|
|
|
|
* Get the stack pointer at a stack frame.
|
|
|
|
*
|
|
|
|
* @param[out] ret Returned stack pointer.
|
|
|
|
* @return @c true if the stack pointer is known, @c false if it is not.
|
|
|
|
*/
|
|
|
|
bool drgn_stack_frame_sp(struct drgn_stack_trace *trace, size_t frame,
|
|
|
|
uint64_t *ret);
|
|
|
|
|
2019-07-29 22:41:33 +01:00
|
|
|
/**
|
|
|
|
* Get the function symbol at a stack frame.
|
|
|
|
*
|
|
|
|
* @param[out] ret Returned symbol. On success, it should be freed with @ref
|
|
|
|
* drgn_symbol_destroy(). On error, its contents are undefined.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2020-05-13 07:21:50 +01:00
|
|
|
struct drgn_error *drgn_stack_frame_symbol(struct drgn_stack_trace *trace,
|
|
|
|
size_t frame,
|
2019-07-29 22:41:33 +01:00
|
|
|
struct drgn_symbol **ret);
|
2021-06-02 21:17:41 +01:00
|
|
|
|
2022-05-27 00:42:20 +01:00
|
|
|
/**
|
|
|
|
* Get the names of local objects in the scope of this frame.
|
|
|
|
*
|
|
|
|
* The array of names must be freed with @ref drgn_stack_frame_locals_destroy().
|
|
|
|
*
|
|
|
|
* @param[out] names_ret Returned array of names. On success, must be freed with
|
|
|
|
* @ref drgn_stack_frame_locals_destroy().
|
|
|
|
* @param[out] count_ret Returned number of names in @p names_ret.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error
|
|
|
|
*/
|
|
|
|
struct drgn_error *
|
|
|
|
drgn_stack_frame_locals(struct drgn_stack_trace *trace, size_t frame,
|
|
|
|
const char ***names_ret, size_t *count_ret);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Free an array of names returned by @ref drgn_stack_frame_locals().
|
|
|
|
*
|
|
|
|
* The individual names from this array are invalid once this function is
|
|
|
|
* called. Any string which will be used later should be copied.
|
|
|
|
*
|
|
|
|
* @param names Array of names returned by @ref drgn_stack_frame_locals().
|
|
|
|
* @param count Count returned by @ref drgn_stack_frame_locals().
|
|
|
|
*/
|
|
|
|
void drgn_stack_frame_locals_destroy(const char **names, size_t count);
|
|
|
|
|
2021-06-02 21:17:41 +01:00
|
|
|
/**
|
|
|
|
* Find an object in the scope of a stack frame.
|
|
|
|
*
|
|
|
|
* @param[in] name Object name.
|
|
|
|
* @param[out] ret Returned object. This must have already been initialized with
|
|
|
|
* @ref drgn_object_init().
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *
|
|
|
|
drgn_stack_frame_find_object(struct drgn_stack_trace *trace, size_t frame,
|
|
|
|
const char *name, struct drgn_object *ret);
|
|
|
|
|
2021-01-28 23:49:21 +00:00
|
|
|
/**
|
|
|
|
* Get the value of a register in a stack frame.
|
|
|
|
*
|
|
|
|
* @param[in] reg Register to get. Must be from the platform of the program that
|
|
|
|
* the trace was taken from.
|
|
|
|
* @param[out] ret Returned register value.
|
2021-03-10 09:51:33 +00:00
|
|
|
* @return @c true on success, @c false if the value is not known or the
|
|
|
|
* register is too large to return in a @c uint64_t.
|
2021-01-28 23:49:21 +00:00
|
|
|
*/
|
|
|
|
bool drgn_stack_frame_register(struct drgn_stack_trace *trace, size_t frame,
|
|
|
|
const struct drgn_register *reg, uint64_t *ret);
|
2019-10-18 10:42:51 +01:00
|
|
|
|
2019-07-29 22:41:33 +01:00
|
|
|
/**
|
2019-10-26 00:11:14 +01:00
|
|
|
* Get a stack trace for the thread with the given thread ID.
|
2019-07-29 22:41:33 +01:00
|
|
|
*
|
|
|
|
* @param[out] ret Returned stack trace. On success, it should be freed with
|
|
|
|
* @ref drgn_stack_trace_destroy(). On error, its contents are undefined.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
2019-10-26 00:11:14 +01:00
|
|
|
struct drgn_error *drgn_program_stack_trace(struct drgn_program *prog,
|
|
|
|
uint32_t tid,
|
|
|
|
struct drgn_stack_trace **ret);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get a stack trace for the thread represented by @p obj.
|
|
|
|
*
|
|
|
|
* @sa drgn_program_stack_trace().
|
|
|
|
*/
|
2019-07-29 22:41:33 +01:00
|
|
|
struct drgn_error *drgn_object_stack_trace(const struct drgn_object *obj,
|
|
|
|
struct drgn_stack_trace **ret);
|
|
|
|
|
|
|
|
/** @} */
|
|
|
|
|
2021-11-19 00:46:59 +00:00
|
|
|
/**
|
|
|
|
* @defgroup Threads Threads
|
|
|
|
*
|
|
|
|
* Threads in a program.
|
|
|
|
*
|
|
|
|
* @{
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @struct drgn_thread
|
|
|
|
*
|
|
|
|
* A thread in a program.
|
|
|
|
*/
|
|
|
|
struct drgn_thread;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Create a copy of a @ref drgn_thread.
|
|
|
|
*
|
|
|
|
* @param[in] thread Thread to copy.
|
|
|
|
* @param[out] ret Returned copy. On success, must be destroyed with @ref
|
|
|
|
* drgn_thread_destroy().
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_thread_dup(const struct drgn_thread *thread,
|
|
|
|
struct drgn_thread **ret);
|
|
|
|
|
|
|
|
/** Free a @ref drgn_thread. */
|
|
|
|
void drgn_thread_destroy(struct drgn_thread *thread);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @struct drgn_thread_iterator
|
|
|
|
*
|
|
|
|
* An iterator over all the threads in a program.
|
|
|
|
*/
|
|
|
|
struct drgn_thread_iterator;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get an iterator over all of the threads in the program.
|
|
|
|
*
|
|
|
|
* @param[out] ret Returned iterator, which can be advanced with @ref
|
|
|
|
* drgn_thread_iterator_next, and must be destroyed with @ref
|
|
|
|
* drgn_thread_iterator_destroy.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *
|
|
|
|
drgn_thread_iterator_create(struct drgn_program *prog,
|
|
|
|
struct drgn_thread_iterator **ret);
|
|
|
|
|
|
|
|
/** Free a @ref drgn_thread_iterator. */
|
|
|
|
void drgn_thread_iterator_destroy(struct drgn_thread_iterator *it);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the next thread from a @ref drgn_thread_iterator.
|
|
|
|
*
|
|
|
|
* @param[out] ret Borrowed thread handle, or @c NULL if there are no more
|
|
|
|
* threads. This is valid until until the next call to @ref
|
|
|
|
* drgn_thread_iterator_next() with the same @p it, or until @p it is destroyed.
|
|
|
|
* It may be copied with @ref drgn_thread_dup() if it is needed for longer. This
|
|
|
|
* must NOT be destroyed with @ref drgn_thread_destroy().
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_thread_iterator_next(struct drgn_thread_iterator *it,
|
|
|
|
struct drgn_thread **ret);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the thread with the given thread ID.
|
|
|
|
*
|
|
|
|
* @param[in] tid Thread ID.
|
2022-02-12 01:42:29 +00:00
|
|
|
* @param[out] ret New thread handle, or @c NULL if not found. On success, must
|
|
|
|
* be destroyed with @ref drgn_thread_destroy().
|
2021-11-19 00:46:59 +00:00
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_program_find_thread(struct drgn_program *prog,
|
|
|
|
uint32_t tid,
|
|
|
|
struct drgn_thread **ret);
|
|
|
|
|
2022-02-08 19:43:44 +00:00
|
|
|
/**
|
|
|
|
* Get the main program thread.
|
|
|
|
*
|
|
|
|
* @param[out] ret Borrowed thread handle. This is valid for the lifetime of @p
|
|
|
|
* prog. This must NOT be destroyed with @ref drgn_thread_destroy().
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_program_main_thread(struct drgn_program *prog,
|
|
|
|
struct drgn_thread **ret);
|
|
|
|
|
2021-11-19 00:46:59 +00:00
|
|
|
/**
|
|
|
|
* Get the thread that caused the program to crash.
|
|
|
|
*
|
|
|
|
* @param[out] ret Borrowed thread handle. This is valid for the lifetime of @p
|
|
|
|
* prog. This must NOT be destroyed with @ref drgn_thread_destroy().
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_program_crashed_thread(struct drgn_program *prog,
|
|
|
|
struct drgn_thread **ret);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the object for the given thread. This is currently only defined for the
|
|
|
|
* Linux kernel.
|
|
|
|
*
|
|
|
|
* @param[out] ret Returned object. This must not be modified and is valid for
|
|
|
|
* the lifetime of @p thread. It can be copied with @ref drgn_object_copy() if
|
|
|
|
* it is needed for longer.
|
|
|
|
* @return @c NULL on success, non-@c NULL on error.
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_thread_object(struct drgn_thread *thread,
|
|
|
|
const struct drgn_object **ret);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get a stack trace for the thread represented by @p thread.
|
|
|
|
*
|
|
|
|
* @sa drgn_program_stack_trace().
|
|
|
|
*/
|
|
|
|
struct drgn_error *drgn_thread_stack_trace(struct drgn_thread *thread,
|
|
|
|
struct drgn_stack_trace **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
|
|
|
#endif /* DRGN_H */
|