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
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
"""
|
|
|
|
libdrgn bindings
|
|
|
|
|
|
|
|
Don't use this module directly. Instead, use the drgn package.
|
|
|
|
"""
|
|
|
|
|
2024-06-04 21:13:35 +01:00
|
|
|
import collections.abc
|
2020-02-25 19:43:01 +00:00
|
|
|
import enum
|
|
|
|
import os
|
2020-08-13 22:47:59 +01:00
|
|
|
import sys
|
2020-02-25 19:43:01 +00:00
|
|
|
from typing import (
|
|
|
|
Any,
|
|
|
|
Callable,
|
2023-01-18 23:01:24 +00:00
|
|
|
ClassVar,
|
2020-02-25 19:43:01 +00:00
|
|
|
Dict,
|
|
|
|
Iterable,
|
|
|
|
Iterator,
|
2021-08-02 21:34:30 +01:00
|
|
|
List,
|
2020-12-11 01:44:02 +00:00
|
|
|
Mapping,
|
2020-02-25 19:43:01 +00:00
|
|
|
Optional,
|
|
|
|
Sequence,
|
2024-04-26 23:33:37 +01:00
|
|
|
Set,
|
2020-12-02 19:24:05 +00:00
|
|
|
Tuple,
|
2020-02-25 19:43:01 +00:00
|
|
|
Union,
|
|
|
|
overload,
|
|
|
|
)
|
|
|
|
|
2020-08-13 22:47:59 +01:00
|
|
|
if sys.version_info < (3, 8):
|
2023-01-18 23:01:24 +00:00
|
|
|
from typing_extensions import Final, Protocol
|
2020-08-13 22:47:59 +01:00
|
|
|
else:
|
2023-01-18 23:01:24 +00:00
|
|
|
from typing import Final, Protocol
|
|
|
|
|
|
|
|
if sys.version_info < (3, 10):
|
|
|
|
from typing_extensions import TypeAlias
|
|
|
|
else:
|
|
|
|
from typing import TypeAlias
|
2020-08-13 22:47:59 +01:00
|
|
|
|
|
|
|
# This is effectively typing.SupportsIndex without @typing.runtime_checkable
|
|
|
|
# (both of which are only available since Python 3.8), with a more
|
|
|
|
# self-explanatory name.
|
|
|
|
class IntegerLike(Protocol):
|
|
|
|
"""
|
|
|
|
An :class:`int` or integer-like object.
|
|
|
|
|
|
|
|
Parameters annotated with this type expect an integer which may be given as
|
|
|
|
a Python :class:`int` or an :class:`Object` with integer type.
|
|
|
|
"""
|
|
|
|
|
|
|
|
def __index__(self) -> int: ...
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
Path: TypeAlias = Union[str, bytes, os.PathLike[str], os.PathLike[bytes]]
|
2020-08-13 23:27:20 +01:00
|
|
|
"""
|
|
|
|
Filesystem path.
|
|
|
|
|
|
|
|
Parameters annotated with this type accept a filesystem path as :class:`str`,
|
|
|
|
:class:`bytes`, or :class:`os.PathLike`.
|
|
|
|
"""
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
class Program:
|
|
|
|
"""
|
|
|
|
A ``Program`` represents a crashed or running program. It can be used to
|
|
|
|
lookup type definitions, access variables, and read arbitrary memory.
|
|
|
|
|
|
|
|
The main functionality of a ``Program`` is looking up objects (i.e.,
|
|
|
|
variables, constants, or functions). This is usually done with the
|
|
|
|
:meth:`[] <.__getitem__>` operator.
|
|
|
|
"""
|
|
|
|
|
2023-09-08 18:25:43 +01:00
|
|
|
def __init__(
|
|
|
|
self,
|
|
|
|
platform: Optional[Platform] = None,
|
|
|
|
*,
|
|
|
|
vmcoreinfo: Union[bytes, str, None] = None,
|
|
|
|
) -> None:
|
2020-08-17 04:40:47 +01:00
|
|
|
"""
|
2020-12-11 00:38:09 +00:00
|
|
|
Create a ``Program`` with no target program. It is usually more
|
2020-08-17 04:40:47 +01:00
|
|
|
convenient to use one of the :ref:`api-program-constructors`.
|
|
|
|
|
|
|
|
:param platform: The platform of the program, or ``None`` if it should
|
|
|
|
be determined automatically when a core dump or symbol file is
|
|
|
|
added.
|
2023-09-08 18:25:43 +01:00
|
|
|
:param vmcoreinfo: Optionally provide the ``VMCOREINFO`` note data for
|
|
|
|
Linux kernel core dumps, which will override any detected data. When
|
|
|
|
not provided or ``None``, automatically detect the info.
|
2020-08-17 04:40:47 +01:00
|
|
|
"""
|
|
|
|
...
|
2020-02-25 19:43:01 +00:00
|
|
|
flags: ProgramFlags
|
|
|
|
"""Flags which apply to this program."""
|
|
|
|
|
|
|
|
platform: Optional[Platform]
|
|
|
|
"""
|
|
|
|
Platform that this program runs on, or ``None`` if it has not been
|
|
|
|
determined yet.
|
|
|
|
"""
|
2020-02-26 22:32:35 +00:00
|
|
|
|
|
|
|
language: Language
|
|
|
|
"""
|
|
|
|
Default programming language of the program.
|
|
|
|
|
|
|
|
This is used for interpreting the type name given to :meth:`type()` and
|
|
|
|
when creating an :class:`Object` without an explicit type.
|
|
|
|
|
2022-02-16 21:22:41 +00:00
|
|
|
For the Linux kernel, this defaults to :attr:`Language.C`. For userspace
|
|
|
|
programs, this defaults to the language of ``main`` in the program, falling
|
2020-02-26 22:32:35 +00:00
|
|
|
back to :attr:`Language.C`. This heuristic may change in the future.
|
2022-02-16 21:22:41 +00:00
|
|
|
|
|
|
|
This can be explicitly set to a different language (e.g., if the heuristic
|
|
|
|
was incorrect).
|
2020-02-26 22:32:35 +00:00
|
|
|
"""
|
2020-02-25 19:43:01 +00:00
|
|
|
def __getitem__(self, name: str) -> Object:
|
|
|
|
"""
|
|
|
|
Implement ``self[name]``. Get the object (variable, constant, or
|
|
|
|
function) with the given name.
|
|
|
|
|
|
|
|
This is equivalent to ``prog.object(name)`` except that this raises
|
|
|
|
:exc:`KeyError` instead of :exc:`LookupError` if no objects with the
|
|
|
|
given name are found.
|
|
|
|
|
|
|
|
If there are multiple objects with the same name, one is returned
|
|
|
|
arbitrarily. In this case, the :meth:`variable()`, :meth:`constant()`,
|
|
|
|
:meth:`function()`, or :meth:`object()` methods can be used instead.
|
|
|
|
|
|
|
|
>>> prog['jiffies']
|
|
|
|
Object(prog, 'volatile unsigned long', address=0xffffffff94c05000)
|
|
|
|
|
2021-05-13 00:19:42 +01:00
|
|
|
:param name: Object name.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def __contains__(self, name: str) -> bool:
|
|
|
|
"""
|
|
|
|
Implement ``name in self``. Return whether an object (variable,
|
|
|
|
constant, or function) with the given name exists in the program.
|
|
|
|
|
|
|
|
:param name: Object name.
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
...
|
|
|
|
def variable(self, name: str, filename: Optional[str] = None) -> Object:
|
|
|
|
"""
|
|
|
|
Get the variable with the given name.
|
|
|
|
|
|
|
|
>>> prog.variable('jiffies')
|
|
|
|
Object(prog, 'volatile unsigned long', address=0xffffffff94c05000)
|
|
|
|
|
|
|
|
This is equivalent to ``prog.object(name, FindObjectFlags.VARIABLE,
|
|
|
|
filename)``.
|
|
|
|
|
|
|
|
:param name: The variable name.
|
|
|
|
:param filename: The source code file that contains the definition. See
|
|
|
|
:ref:`api-filenames`.
|
|
|
|
:raises LookupError: if no variables with the given name are found in
|
|
|
|
the given file
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def constant(self, name: str, filename: Optional[str] = None) -> Object:
|
|
|
|
"""
|
|
|
|
Get the constant (e.g., enumeration constant) with the given name.
|
|
|
|
|
|
|
|
Note that support for macro constants is not yet implemented for DWARF
|
|
|
|
files, and most compilers don't generate macro debugging information by
|
|
|
|
default anyways.
|
|
|
|
|
|
|
|
>>> prog.constant('PIDTYPE_MAX')
|
|
|
|
Object(prog, 'enum pid_type', value=4)
|
|
|
|
|
|
|
|
This is equivalent to ``prog.object(name, FindObjectFlags.CONSTANT,
|
|
|
|
filename)``.
|
|
|
|
|
|
|
|
:param name: The constant name.
|
|
|
|
:param filename: The source code file that contains the definition. See
|
|
|
|
:ref:`api-filenames`.
|
|
|
|
:raises LookupError: if no constants with the given name are found in
|
|
|
|
the given file
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def function(self, name: str, filename: Optional[str] = None) -> Object:
|
|
|
|
"""
|
|
|
|
Get the function with the given name.
|
|
|
|
|
|
|
|
>>> prog.function('schedule')
|
|
|
|
Object(prog, 'void (void)', address=0xffffffff94392370)
|
|
|
|
|
|
|
|
This is equivalent to ``prog.object(name, FindObjectFlags.FUNCTION,
|
|
|
|
filename)``.
|
|
|
|
|
|
|
|
:param name: The function name.
|
|
|
|
:param filename: The source code file that contains the definition. See
|
|
|
|
:ref:`api-filenames`.
|
|
|
|
:raises LookupError: if no functions with the given name are found in
|
|
|
|
the given file
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def object(
|
|
|
|
self,
|
|
|
|
name: str,
|
2020-08-27 01:32:49 +01:00
|
|
|
flags: FindObjectFlags = FindObjectFlags.ANY,
|
2020-02-25 19:43:01 +00:00
|
|
|
filename: Optional[str] = None,
|
|
|
|
) -> Object:
|
|
|
|
"""
|
|
|
|
Get the object (variable, constant, or function) with the given name.
|
|
|
|
|
2023-01-13 19:24:44 +00:00
|
|
|
When debugging the Linux kernel, this can look up certain special
|
|
|
|
objects documented in :ref:`kernel-special-objects`, sometimes without
|
|
|
|
any debugging information loaded.
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
:param name: The object name.
|
2020-08-27 01:32:49 +01:00
|
|
|
:param flags: Flags indicating what kind of object to look for.
|
2020-02-25 19:43:01 +00:00
|
|
|
:param filename: The source code file that contains the definition. See
|
|
|
|
:ref:`api-filenames`.
|
|
|
|
:raises LookupError: if no objects with the given name are found in
|
|
|
|
the given file
|
|
|
|
"""
|
|
|
|
...
|
2020-08-13 22:47:59 +01:00
|
|
|
def symbol(self, address_or_name: Union[IntegerLike, str]) -> Symbol:
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
2021-11-20 01:07:23 +00:00
|
|
|
Get a symbol containing the given address, or a symbol with the given
|
|
|
|
name.
|
|
|
|
|
|
|
|
Global symbols are preferred over weak symbols, and weak symbols are
|
|
|
|
preferred over other symbols. In other words: if a matching
|
|
|
|
:attr:`SymbolBinding.GLOBAL` or :attr:`SymbolBinding.UNIQUE` symbol is
|
|
|
|
found, it is returned. Otherwise, if a matching
|
|
|
|
:attr:`SymbolBinding.WEAK` symbol is found, it is returned. Otherwise,
|
|
|
|
any matching symbol (e.g., :attr:`SymbolBinding.LOCAL`) is returned. If
|
|
|
|
there are multiple matching symbols with the same binding, one is
|
2021-08-02 21:34:30 +01:00
|
|
|
returned arbitrarily. To retrieve all matching symbols, use
|
|
|
|
:meth:`symbols()`.
|
2021-11-20 01:07:23 +00:00
|
|
|
|
2021-08-02 21:34:30 +01:00
|
|
|
:param address_or_name: Address or name to search for. This parameter
|
|
|
|
is positional-only.
|
2020-02-25 19:43:01 +00:00
|
|
|
:raises LookupError: if no symbol contains the given address or matches
|
|
|
|
the given name
|
|
|
|
"""
|
|
|
|
...
|
2021-08-02 21:34:30 +01:00
|
|
|
def symbols(
|
|
|
|
self,
|
|
|
|
address_or_name: Union[None, IntegerLike, str] = None,
|
|
|
|
) -> List[Symbol]:
|
|
|
|
"""
|
|
|
|
Get a list of global and local symbols, optionally matching a name or
|
|
|
|
address.
|
|
|
|
|
|
|
|
If a string argument is given, this returns all symbols matching that
|
|
|
|
name. If an integer-like argument given, this returns a list of all
|
|
|
|
symbols containing that address. If no argument is given, all symbols
|
|
|
|
in the program are returned. In all cases, the symbols are returned in
|
|
|
|
an unspecified order.
|
|
|
|
|
|
|
|
:param address_or_name: Address or name to search for. This parameter
|
|
|
|
is positional-only.
|
|
|
|
"""
|
|
|
|
...
|
2020-08-13 22:47:59 +01:00
|
|
|
def stack_trace(
|
|
|
|
self,
|
|
|
|
# Object is already IntegerLike, but this explicitly documents that it
|
|
|
|
# can take non-integer Objects.
|
|
|
|
thread: Union[Object, IntegerLike],
|
|
|
|
) -> StackTrace:
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Get the stack trace for the given thread in the program.
|
|
|
|
|
2022-08-26 18:30:34 +01:00
|
|
|
``thread`` may be a thread ID (as defined by :manpage:`gettid(2)`), in
|
|
|
|
which case this will unwind the stack for the thread with that ID. The
|
|
|
|
ID may be a Python ``int`` or an integer :class:`Object`
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
``thread`` may also be a ``struct pt_regs`` or ``struct pt_regs *``
|
|
|
|
object, in which case the initial register values will be fetched from
|
|
|
|
that object.
|
|
|
|
|
|
|
|
Finally, if debugging the Linux kernel, ``thread`` may be a ``struct
|
|
|
|
task_struct *`` object, in which case this will unwind the stack for
|
|
|
|
that task. See :func:`drgn.helpers.linux.pid.find_task()`.
|
|
|
|
|
|
|
|
This is implemented for the Linux kernel (both live and core dumps) as
|
|
|
|
well as userspace core dumps; it is not yet implemented for live
|
|
|
|
userspace processes.
|
|
|
|
|
|
|
|
:param thread: Thread ID, ``struct pt_regs`` object, or
|
|
|
|
``struct task_struct *`` object.
|
|
|
|
"""
|
|
|
|
...
|
2023-12-05 03:16:01 +00:00
|
|
|
def stack_trace_from_pcs(self, pcs: Sequence[IntegerLike]) -> StackTrace:
|
|
|
|
"""
|
|
|
|
Get a stack trace with the supplied list of program counters.
|
|
|
|
|
|
|
|
:param pcs: List of program counters.
|
|
|
|
"""
|
|
|
|
...
|
2022-01-22 00:47:44 +00:00
|
|
|
@overload
|
2020-02-25 19:43:01 +00:00
|
|
|
def type(self, name: str, filename: Optional[str] = None) -> Type:
|
|
|
|
"""
|
|
|
|
Get the type with the given name.
|
|
|
|
|
|
|
|
>>> prog.type('long')
|
2021-08-02 23:49:29 +01:00
|
|
|
prog.int_type(name='long', size=8, is_signed=True)
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
:param name: The type name.
|
|
|
|
:param filename: The source code file that contains the definition. See
|
|
|
|
:ref:`api-filenames`.
|
|
|
|
:raises LookupError: if no types with the given name are found in
|
|
|
|
the given file
|
|
|
|
"""
|
|
|
|
...
|
2022-01-22 00:47:44 +00:00
|
|
|
@overload
|
|
|
|
# type is positional-only.
|
|
|
|
def type(self, type: Type) -> Type:
|
|
|
|
"""
|
|
|
|
Return the given type.
|
|
|
|
|
|
|
|
This is mainly useful so that helpers can use ``prog.type()`` to get a
|
|
|
|
:class:`Type` regardless of whether they were given a :class:`str` or a
|
|
|
|
:class:`Type`. For example:
|
|
|
|
|
|
|
|
.. code-block:: python3
|
|
|
|
|
|
|
|
def my_helper(obj: Object, type: Union[str, Type]) -> bool:
|
|
|
|
# type may be str or Type.
|
|
|
|
type = obj.prog_.type(type)
|
|
|
|
# type is now always Type.
|
|
|
|
return sizeof(obj) > sizeof(type)
|
|
|
|
|
|
|
|
:param type: Type.
|
|
|
|
:return: The exact same type.
|
|
|
|
"""
|
|
|
|
...
|
2021-11-19 00:46:59 +00:00
|
|
|
def threads(self) -> Iterator[Thread]:
|
|
|
|
"""Get an iterator over all of the threads in the program."""
|
|
|
|
...
|
|
|
|
def thread(self, tid: IntegerLike) -> Thread:
|
|
|
|
"""
|
|
|
|
Get the thread with the given thread ID.
|
|
|
|
|
2022-08-26 18:30:34 +01:00
|
|
|
:param tid: Thread ID (as defined by :manpage:`gettid(2)`).
|
2021-11-19 00:46:59 +00:00
|
|
|
:raises LookupError: if no thread has the given thread ID
|
|
|
|
"""
|
|
|
|
...
|
2022-02-08 19:43:44 +00:00
|
|
|
def main_thread(self) -> Thread:
|
|
|
|
"""
|
|
|
|
Get the main thread of the program.
|
|
|
|
|
|
|
|
This is only defined for userspace programs.
|
|
|
|
|
|
|
|
:raises ValueError: if the program is the Linux kernel
|
|
|
|
"""
|
|
|
|
...
|
2021-11-19 00:46:59 +00:00
|
|
|
def crashed_thread(self) -> Thread:
|
|
|
|
"""
|
|
|
|
Get the thread that caused the program to crash.
|
|
|
|
|
|
|
|
For userspace programs, this is the thread that received the fatal
|
|
|
|
signal (e.g., ``SIGSEGV`` or ``SIGQUIT``).
|
|
|
|
|
|
|
|
For the kernel, this is the thread that panicked (either directly or as
|
|
|
|
a result of an oops, ``BUG_ON()``, etc.).
|
|
|
|
|
|
|
|
:raises ValueError: if the program is live (i.e., not a core dump)
|
|
|
|
"""
|
|
|
|
...
|
2020-08-13 22:47:59 +01:00
|
|
|
def read(
|
|
|
|
self, address: IntegerLike, size: IntegerLike, physical: bool = False
|
|
|
|
) -> bytes:
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Read *size* bytes of memory starting at *address* in the program. The
|
|
|
|
address may be virtual (the default) or physical if the program
|
|
|
|
supports it.
|
|
|
|
|
|
|
|
>>> prog.read(0xffffffffbe012b40, 16)
|
|
|
|
b'swapper/0\x00\x00\x00\x00\x00\x00\x00'
|
|
|
|
|
|
|
|
:param address: The starting address.
|
|
|
|
:param size: The number of bytes to read.
|
|
|
|
:param physical: Whether *address* is a physical memory address. If
|
|
|
|
``False``, then it is a virtual memory address. Physical memory can
|
|
|
|
usually only be read when the program is an operating system
|
|
|
|
kernel.
|
|
|
|
:raises FaultError: if the address range is invalid or the type of
|
|
|
|
address (physical or virtual) is not supported by the program
|
|
|
|
:raises ValueError: if *size* is negative
|
|
|
|
"""
|
|
|
|
...
|
2020-08-17 04:40:47 +01:00
|
|
|
def read_u8(self, address: IntegerLike, physical: bool = False) -> int:
|
2021-05-01 01:06:47 +01:00
|
|
|
""" """
|
2020-08-17 04:40:47 +01:00
|
|
|
...
|
|
|
|
def read_u16(self, address: IntegerLike, physical: bool = False) -> int:
|
2021-05-01 01:06:47 +01:00
|
|
|
""" """
|
2020-08-17 04:40:47 +01:00
|
|
|
...
|
|
|
|
def read_u32(self, address: IntegerLike, physical: bool = False) -> int:
|
2021-05-01 01:06:47 +01:00
|
|
|
""" """
|
2020-08-17 04:40:47 +01:00
|
|
|
...
|
|
|
|
def read_u64(self, address: IntegerLike, physical: bool = False) -> int:
|
2021-05-01 01:06:47 +01:00
|
|
|
""" """
|
2020-08-17 04:40:47 +01:00
|
|
|
...
|
2020-08-13 22:47:59 +01:00
|
|
|
def read_word(self, address: IntegerLike, physical: bool = False) -> int:
|
2020-04-27 08:34:04 +01:00
|
|
|
"""
|
|
|
|
Read an unsigned integer from the program's memory in the program's
|
|
|
|
byte order.
|
|
|
|
|
|
|
|
:meth:`read_u8()`, :meth:`read_u16()`, :meth:`read_u32()`, and
|
|
|
|
:meth:`read_u64()` read an 8-, 16-, 32-, or 64-bit unsigned integer,
|
|
|
|
respectively. :meth:`read_word()` reads a program word-sized unsigned
|
|
|
|
integer.
|
|
|
|
|
|
|
|
For signed integers, alternate byte order, or other formats, you can
|
|
|
|
use :meth:`read()` and :meth:`int.from_bytes()` or the :mod:`struct`
|
|
|
|
module.
|
|
|
|
|
|
|
|
:param address: Address of the integer.
|
|
|
|
:param physical: Whether *address* is a physical memory address; see
|
|
|
|
:meth:`read()`.
|
|
|
|
:raises FaultError: if the address is invalid; see :meth:`read()`
|
|
|
|
"""
|
|
|
|
...
|
2020-02-25 19:43:01 +00:00
|
|
|
def add_memory_segment(
|
|
|
|
self,
|
2020-08-13 22:47:59 +01:00
|
|
|
address: IntegerLike,
|
|
|
|
size: IntegerLike,
|
2020-02-25 19:43:01 +00:00
|
|
|
read_fn: Callable[[int, int, int, bool], bytes],
|
|
|
|
physical: bool = False,
|
|
|
|
) -> None:
|
|
|
|
"""
|
|
|
|
Define a region of memory in the program.
|
|
|
|
|
|
|
|
If it overlaps a previously registered segment, the new segment takes
|
|
|
|
precedence.
|
|
|
|
|
|
|
|
:param address: Address of the segment.
|
|
|
|
:param size: Size of the segment in bytes.
|
|
|
|
:param physical: Whether to add a physical memory segment. If
|
|
|
|
``False``, then this adds a virtual memory segment.
|
|
|
|
:param read_fn: Callable to call to read memory from the segment. It is
|
|
|
|
passed the address being read from, the number of bytes to read,
|
|
|
|
the offset in bytes from the beginning of the segment, and whether
|
|
|
|
the address is physical: ``(address, count, offset, physical)``. It
|
|
|
|
should return the requested number of bytes as :class:`bytes` or
|
|
|
|
another :ref:`buffer <python:binaryseq>` type.
|
|
|
|
"""
|
|
|
|
...
|
2024-05-31 19:44:32 +01:00
|
|
|
def register_type_finder(
|
|
|
|
self,
|
|
|
|
name: str,
|
|
|
|
fn: Callable[[Program, TypeKindSet, str, Optional[str]], Optional[Type]],
|
|
|
|
*,
|
|
|
|
enable_index: Optional[int] = None,
|
|
|
|
) -> None:
|
|
|
|
"""
|
|
|
|
Register a callback for finding types in the program.
|
|
|
|
|
|
|
|
This does not enable the finder unless *enable_index* is given.
|
|
|
|
|
|
|
|
:param name: Finder name.
|
|
|
|
:param fn: Callable taking the program, a :class:`TypeKindSet`, name,
|
|
|
|
and filename: ``(prog, kinds, name, filename)``. The filename
|
|
|
|
should be matched with :func:`filename_matches()`. This should
|
|
|
|
return a :class:`Type` or ``None`` if not found.
|
|
|
|
:param enable_index: Insert the finder into the list of enabled type
|
|
|
|
finders at the given index. If -1 or greater than the number of
|
|
|
|
enabled finders, insert it at the end. If ``None`` or not given,
|
|
|
|
don't enable the finder.
|
|
|
|
:raises ValueError: if there is already a finder with the given name
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def registered_type_finders(self) -> Set[str]:
|
|
|
|
"""Return the names of all registered type finders."""
|
|
|
|
...
|
|
|
|
def set_enabled_type_finders(self, names: Sequence[str]) -> None:
|
|
|
|
"""
|
|
|
|
Set the list of enabled type finders.
|
|
|
|
|
|
|
|
Finders are called in the same order as the list until a type is found.
|
|
|
|
|
|
|
|
Finders that are not in the list are not called.
|
|
|
|
|
|
|
|
:param names: Names of finders to enable, in order.
|
|
|
|
:raises ValueError: if no finder has a given name or the same name is
|
|
|
|
given more than once
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def enabled_type_finders(self) -> List[str]:
|
|
|
|
"""Return the names of enabled type finders, in order."""
|
|
|
|
...
|
2024-06-05 00:58:25 +01:00
|
|
|
def register_object_finder(
|
|
|
|
self,
|
|
|
|
name: str,
|
|
|
|
fn: Callable[[Program, str, FindObjectFlags, Optional[str]], Optional[Object]],
|
|
|
|
*,
|
|
|
|
enable_index: Optional[int] = None,
|
|
|
|
) -> None:
|
|
|
|
"""
|
|
|
|
Register a callback for finding objects in the program.
|
|
|
|
|
|
|
|
This does not enable the finder unless *enable_index* is given.
|
|
|
|
|
|
|
|
:param name: Finder name.
|
|
|
|
:param fn: Callable taking the program, name, :class:`FindObjectFlags`,
|
|
|
|
and filename: ``(prog, name, flags, filename)``. The filename
|
|
|
|
should be matched with :func:`filename_matches()`. This should
|
|
|
|
return an :class:`Object` or ``None`` if not found.
|
|
|
|
:param enable_index: Insert the finder into the list of enabled object
|
|
|
|
finders at the given index. If -1 or greater than the number of
|
|
|
|
enabled finders, insert it at the end. If ``None`` or not given,
|
|
|
|
don't enable the finder.
|
|
|
|
:raises ValueError: if there is already a finder with the given name
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def registered_object_finders(self) -> Set[str]:
|
|
|
|
"""Return the names of all registered object finders."""
|
|
|
|
...
|
|
|
|
def set_enabled_object_finders(self, names: Sequence[str]) -> None:
|
|
|
|
"""
|
|
|
|
Set the list of enabled object finders.
|
|
|
|
|
|
|
|
Finders are called in the same order as the list until an object is found.
|
|
|
|
|
|
|
|
Finders that are not in the list are not called.
|
|
|
|
|
|
|
|
:param names: Names of finders to enable, in order.
|
|
|
|
:raises ValueError: if no finder has a given name or the same name is
|
|
|
|
given more than once
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def enabled_object_finders(self) -> List[str]:
|
|
|
|
"""Return the names of enabled object finders, in order."""
|
|
|
|
...
|
2024-04-26 23:33:37 +01:00
|
|
|
def register_symbol_finder(
|
|
|
|
self,
|
|
|
|
name: str,
|
|
|
|
fn: Callable[[Program, Optional[str], Optional[int], bool], Sequence[Symbol]],
|
|
|
|
*,
|
|
|
|
enable_index: Optional[int] = None,
|
|
|
|
) -> None:
|
|
|
|
"""
|
|
|
|
Register a callback for finding symbols in the program.
|
|
|
|
|
|
|
|
This does not enable the finder unless *enable_index* is given.
|
|
|
|
|
|
|
|
The callback should take four arguments: the program, a *name*, an
|
|
|
|
*address*, and a boolean flag *one*. It should return a list of symbols
|
|
|
|
or an empty list if no matches are found.
|
|
|
|
|
|
|
|
If *name* is not ``None``, then only symbols with that name should be
|
|
|
|
returned. If *address* is not ``None``, then only symbols containing
|
|
|
|
that address should be returned. If neither is ``None``, then the
|
|
|
|
returned symbols must match both. If both are ``None``, then all
|
|
|
|
symbols should be considered matching.
|
|
|
|
|
|
|
|
When the *one* flag is ``False``, the callback should return a list of
|
|
|
|
all matching symbols. When it is ``True``, it should return a list with
|
|
|
|
at most one symbol which is the best match.
|
|
|
|
|
|
|
|
:param name: Finder name.
|
|
|
|
:param fn: Callable taking ``(prog, name, address, one)`` and returning
|
|
|
|
a sequence of :class:`Symbol`\\ s.
|
|
|
|
:param enable_index: Insert the finder into the list of enabled finders
|
|
|
|
at the given index. If -1 or greater than the number of enabled
|
|
|
|
finders, insert it at the end. If ``None`` or not given, don't
|
|
|
|
enable the finder.
|
|
|
|
:raises ValueError: if there is already a finder with the given name
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def registered_symbol_finders(self) -> Set[str]:
|
|
|
|
"""Return the names of all registered symbol finders."""
|
|
|
|
...
|
|
|
|
def set_enabled_symbol_finders(self, names: Sequence[str]) -> None:
|
|
|
|
"""
|
|
|
|
Set the list of enabled symbol finders.
|
|
|
|
|
|
|
|
Finders are called in the same order as the list. When the *one* flag
|
|
|
|
is set, the search will short-circuit after the first finder which
|
|
|
|
returns a result, and subsequent finders will not be called. Otherwise,
|
|
|
|
all callbacks will be called, and all results will be returned.
|
|
|
|
|
|
|
|
Finders that are not in the list are not called.
|
|
|
|
|
|
|
|
:param names: Names of finders to enable, in order.
|
|
|
|
:raises ValueError: if no finder has a given name or the same name is
|
|
|
|
given more than once
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def enabled_symbol_finders(self) -> List[str]:
|
|
|
|
"""Return the names of enabled symbol finders, in order."""
|
|
|
|
...
|
2020-02-25 19:43:01 +00:00
|
|
|
def add_type_finder(
|
2023-03-09 18:04:14 +00:00
|
|
|
self, fn: Callable[[TypeKind, str, Optional[str]], Optional[Type]]
|
2020-02-25 19:43:01 +00:00
|
|
|
) -> None:
|
|
|
|
"""
|
2024-05-31 19:44:32 +01:00
|
|
|
Deprecated method to register and enable a callback for finding types
|
|
|
|
in the program.
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2024-05-31 19:44:32 +01:00
|
|
|
.. deprecated:: 0.0.27
|
|
|
|
Use :meth:`register_type_finder()` instead.
|
|
|
|
|
|
|
|
The differences from :meth:`register_type_finder()` are:
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2024-05-31 19:44:32 +01:00
|
|
|
1. *fn* is not passed *prog*.
|
|
|
|
2. *fn* is passed a :class:`TypeKind` instead of a
|
|
|
|
:class:`TypeKindSet`. If multiple kinds are being searched for, *fn*
|
|
|
|
will be called multiple times.
|
|
|
|
3. A name for the finder is generated from *fn*.
|
|
|
|
4. The finder is always enabled before any existing finders.
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
...
|
|
|
|
def add_object_finder(
|
2023-03-09 18:04:14 +00:00
|
|
|
self,
|
|
|
|
fn: Callable[[Program, str, FindObjectFlags, Optional[str]], Optional[Object]],
|
2020-02-25 19:43:01 +00:00
|
|
|
) -> None:
|
|
|
|
"""
|
2024-06-05 00:58:25 +01:00
|
|
|
Deprecated method to register and enable a callback for finding objects
|
|
|
|
in the program.
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2024-06-05 00:58:25 +01:00
|
|
|
.. deprecated:: 0.0.27
|
|
|
|
Use :meth:`register_object_finder()` instead.
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2024-06-05 00:58:25 +01:00
|
|
|
The differences from :meth:`register_object_finder()` are:
|
|
|
|
|
|
|
|
1. A name for the finder is generated from *fn*.
|
|
|
|
2. The finder is always enabled before any existing finders.
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
...
|
2023-08-16 07:38:04 +01:00
|
|
|
def set_core_dump(self, path: Union[Path, int]) -> None:
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Set the program to a core dump.
|
|
|
|
|
|
|
|
This loads the memory segments from the core dump and determines the
|
|
|
|
mapped executable and libraries. It does not load any debugging
|
|
|
|
symbols; see :meth:`load_default_debug_info()`.
|
|
|
|
|
2023-08-16 07:38:04 +01:00
|
|
|
:param path: Core dump file path or open file descriptor.
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
...
|
|
|
|
def set_kernel(self) -> None:
|
|
|
|
"""
|
|
|
|
Set the program to the running operating system kernel.
|
|
|
|
|
|
|
|
This loads the memory of the running kernel and thus requires root
|
|
|
|
privileges. It does not load any debugging symbols; see
|
|
|
|
:meth:`load_default_debug_info()`.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def set_pid(self, pid: int) -> None:
|
|
|
|
"""
|
|
|
|
Set the program to a running process.
|
|
|
|
|
|
|
|
This loads the memory of the process and determines the mapped
|
|
|
|
executable and libraries. It does not load any debugging symbols; see
|
|
|
|
:meth:`load_default_debug_info()`.
|
|
|
|
|
|
|
|
:param pid: Process ID.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def load_debug_info(
|
|
|
|
self,
|
2020-08-13 23:27:20 +01:00
|
|
|
paths: Optional[Iterable[Path]] = None,
|
2020-02-25 19:43:01 +00:00
|
|
|
default: bool = False,
|
|
|
|
main: bool = False,
|
|
|
|
) -> None:
|
|
|
|
"""
|
|
|
|
Load debugging information for a list of executable or library files.
|
|
|
|
|
|
|
|
Note that this is parallelized, so it is usually faster to load
|
|
|
|
multiple files at once rather than one by one.
|
|
|
|
|
|
|
|
:param paths: Paths of binary files.
|
|
|
|
:param default: Also load debugging information which can automatically
|
|
|
|
be determined from the program.
|
|
|
|
|
|
|
|
For the Linux kernel, this tries to load ``vmlinux`` and any loaded
|
|
|
|
kernel modules from a few standard locations.
|
|
|
|
|
|
|
|
For userspace programs, this tries to load the executable and any
|
|
|
|
loaded libraries.
|
|
|
|
|
|
|
|
This implies ``main=True``.
|
|
|
|
:param main: Also load debugging information for the main executable.
|
|
|
|
|
|
|
|
For the Linux kernel, this tries to load ``vmlinux``.
|
|
|
|
|
|
|
|
This is currently ignored for userspace programs.
|
|
|
|
:raises MissingDebugInfoError: if debugging information was not
|
|
|
|
available for some files; other files with debugging information
|
|
|
|
are still loaded
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def load_default_debug_info(self) -> None:
|
|
|
|
"""
|
|
|
|
Load debugging information which can automatically be determined from
|
|
|
|
the program.
|
|
|
|
|
|
|
|
This is equivalent to ``load_debug_info(None, True)``.
|
|
|
|
"""
|
|
|
|
...
|
2020-08-20 20:10:23 +01:00
|
|
|
cache: Dict[Any, Any]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Dictionary for caching program metadata.
|
|
|
|
|
|
|
|
This isn't used by drgn itself. It is intended to be used by helpers to
|
|
|
|
cache metadata about the program. For example, if a helper for a program
|
|
|
|
depends on the program version or an optional feature, the helper can
|
|
|
|
detect it and cache it for subsequent invocations:
|
|
|
|
|
|
|
|
.. code-block:: python3
|
|
|
|
|
|
|
|
def my_helper(prog):
|
|
|
|
try:
|
|
|
|
have_foo = prog.cache['have_foo']
|
|
|
|
except KeyError:
|
|
|
|
have_foo = detect_foo_feature(prog)
|
|
|
|
prog.cache['have_foo'] = have_foo
|
|
|
|
if have_foo:
|
|
|
|
return prog['foo']
|
|
|
|
else:
|
|
|
|
return prog['bar']
|
|
|
|
"""
|
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
|
|
|
def void_type(
|
|
|
|
self,
|
|
|
|
*,
|
2020-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""
|
|
|
|
Create a new void type. It has kind :attr:`TypeKind.VOID`.
|
|
|
|
|
|
|
|
:param qualifiers: :attr:`Type.qualifiers`
|
|
|
|
:param lang: :attr:`Type.language`
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def int_type(
|
|
|
|
self,
|
|
|
|
name: str,
|
|
|
|
size: IntegerLike,
|
|
|
|
is_signed: bool,
|
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
|
|
|
byteorder: Optional[str] = None,
|
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-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""
|
|
|
|
Create a new integer type. It has kind :attr:`TypeKind.INT`.
|
|
|
|
|
|
|
|
:param name: :attr:`Type.name`
|
|
|
|
:param size: :attr:`Type.size`
|
|
|
|
:param is_signed: :attr:`Type.is_signed`
|
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
|
|
|
:param byteorder: :attr:`Type.byteorder`, or ``None`` to use the
|
|
|
|
program's default byte order.
|
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
|
|
|
:param qualifiers: :attr:`Type.qualifiers`
|
|
|
|
:param lang: :attr:`Type.language`
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def bool_type(
|
|
|
|
self,
|
|
|
|
name: str,
|
|
|
|
size: IntegerLike,
|
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
|
|
|
byteorder: Optional[str] = None,
|
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-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""
|
|
|
|
Create a new boolean type. It has kind :attr:`TypeKind.BOOL`.
|
|
|
|
|
|
|
|
:param name: :attr:`Type.name`
|
|
|
|
:param size: :attr:`Type.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
|
|
|
:param byteorder: :attr:`Type.byteorder`, or ``None`` to use the
|
|
|
|
program's default byte order.
|
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
|
|
|
:param qualifiers: :attr:`Type.qualifiers`
|
|
|
|
:param lang: :attr:`Type.language`
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def float_type(
|
|
|
|
self,
|
|
|
|
name: str,
|
|
|
|
size: IntegerLike,
|
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
|
|
|
byteorder: Optional[str] = None,
|
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-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""
|
|
|
|
Create a new floating-point type. It has kind :attr:`TypeKind.FLOAT`.
|
|
|
|
|
|
|
|
:param name: :attr:`Type.name`
|
|
|
|
:param size: :attr:`Type.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
|
|
|
:param byteorder: :attr:`Type.byteorder`, or ``None`` to use the
|
|
|
|
program's default byte order.
|
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
|
|
|
:param qualifiers: :attr:`Type.qualifiers`
|
|
|
|
:param lang: :attr:`Type.language`
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
@overload
|
|
|
|
def struct_type(
|
|
|
|
self,
|
|
|
|
tag: Optional[str],
|
|
|
|
size: IntegerLike,
|
|
|
|
members: Sequence[TypeMember],
|
|
|
|
*,
|
2021-01-09 01:28:27 +00:00
|
|
|
template_parameters: Sequence[TypeTemplateParameter] = (),
|
2020-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""
|
|
|
|
Create a new structure type. It has kind :attr:`TypeKind.STRUCT`.
|
|
|
|
|
|
|
|
:param tag: :attr:`Type.tag`
|
|
|
|
:param size: :attr:`Type.size`
|
|
|
|
:param members: :attr:`Type.members`
|
2021-01-09 01:28:27 +00:00
|
|
|
:param template_parameters: :attr:`Type.template_parameters`
|
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
|
|
|
:param qualifiers: :attr:`Type.qualifiers`
|
|
|
|
:param lang: :attr:`Type.language`
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
@overload
|
|
|
|
def struct_type(
|
|
|
|
self,
|
|
|
|
tag: Optional[str],
|
|
|
|
size: None = None,
|
|
|
|
members: None = None,
|
|
|
|
*,
|
2021-01-09 01:28:27 +00:00
|
|
|
template_parameters: Sequence[TypeTemplateParameter] = (),
|
2020-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""Create a new incomplete structure type."""
|
|
|
|
...
|
|
|
|
@overload
|
|
|
|
def union_type(
|
|
|
|
self,
|
|
|
|
tag: Optional[str],
|
|
|
|
size: IntegerLike,
|
|
|
|
members: Sequence[TypeMember],
|
|
|
|
*,
|
2021-01-09 01:28:27 +00:00
|
|
|
template_parameters: Sequence[TypeTemplateParameter] = (),
|
2020-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""
|
|
|
|
Create a new union type. It has kind :attr:`TypeKind.UNION`. Otherwise,
|
|
|
|
this is the same as as :meth:`struct_type()`.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
@overload
|
|
|
|
def union_type(
|
|
|
|
self,
|
|
|
|
tag: Optional[str],
|
|
|
|
size: None = None,
|
|
|
|
members: None = None,
|
|
|
|
*,
|
2021-01-09 01:28:27 +00:00
|
|
|
template_parameters: Sequence[TypeTemplateParameter] = (),
|
2020-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""Create a new incomplete union type."""
|
|
|
|
...
|
|
|
|
@overload
|
|
|
|
def class_type(
|
|
|
|
self,
|
|
|
|
tag: Optional[str],
|
|
|
|
size: IntegerLike,
|
|
|
|
members: Sequence[TypeMember],
|
|
|
|
*,
|
2021-01-09 01:28:27 +00:00
|
|
|
template_parameters: Sequence[TypeTemplateParameter] = (),
|
2020-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""
|
|
|
|
Create a new class type. It has kind :attr:`TypeKind.CLASS`. Otherwise,
|
|
|
|
this is the same as as :meth:`struct_type()`.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
@overload
|
|
|
|
def class_type(
|
|
|
|
self,
|
|
|
|
tag: Optional[str],
|
|
|
|
size: None = None,
|
|
|
|
members: None = None,
|
|
|
|
*,
|
2021-01-09 01:28:27 +00:00
|
|
|
template_parameters: Sequence[TypeTemplateParameter] = (),
|
2020-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""Create a new incomplete class type."""
|
|
|
|
...
|
|
|
|
@overload
|
|
|
|
def enum_type(
|
|
|
|
self,
|
|
|
|
tag: Optional[str],
|
|
|
|
type: Type,
|
|
|
|
enumerators: Sequence[TypeEnumerator],
|
|
|
|
*,
|
2020-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""
|
|
|
|
Create a new enumerated type. It has kind :attr:`TypeKind.ENUM`.
|
|
|
|
|
|
|
|
:param tag: :attr:`Type.tag`
|
|
|
|
:param type: The compatible integer type (:attr:`Type.type`)
|
|
|
|
:param enumerators: :attr:`Type.enumerators`
|
|
|
|
:param qualifiers: :attr:`Type.qualifiers`
|
|
|
|
:param lang: :attr:`Type.language`
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
@overload
|
|
|
|
def enum_type(
|
|
|
|
self,
|
|
|
|
tag: Optional[str],
|
|
|
|
type: None = None,
|
|
|
|
enumerators: None = None,
|
|
|
|
*,
|
2020-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""Create a new incomplete enumerated type."""
|
|
|
|
...
|
|
|
|
def typedef_type(
|
|
|
|
self,
|
|
|
|
name: str,
|
|
|
|
type: Type,
|
|
|
|
*,
|
2020-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""
|
|
|
|
Create a new typedef type. It has kind :attr:`TypeKind.TYPEDEF`.
|
|
|
|
|
|
|
|
:param name: :attr:`Type.name`
|
|
|
|
:param type: The aliased type (:attr:`Type.type`)
|
|
|
|
:param qualifiers: :attr:`Type.qualifiers`
|
|
|
|
:param lang: :attr:`Type.language`
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def pointer_type(
|
|
|
|
self,
|
|
|
|
type: Type,
|
|
|
|
size: Optional[int] = None,
|
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
|
|
|
byteorder: Optional[str] = None,
|
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-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""
|
|
|
|
Create a new pointer type. It has kind :attr:`TypeKind.POINTER`,
|
|
|
|
|
|
|
|
:param type: The referenced type (:attr:`Type.type`)
|
|
|
|
:param size: :attr:`Type.size`, or ``None`` to use the program's
|
|
|
|
default pointer 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
|
|
|
:param byteorder: :attr:`Type.byteorder`, or ``None`` to use the
|
|
|
|
program's default byte order.
|
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
|
|
|
:param qualifiers: :attr:`Type.qualifiers`
|
|
|
|
:param lang: :attr:`Type.language`
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def array_type(
|
|
|
|
self,
|
|
|
|
type: Type,
|
|
|
|
length: Optional[int] = None,
|
|
|
|
*,
|
2020-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""
|
|
|
|
Create a new array type. It has kind :attr:`TypeKind.ARRAY`.
|
|
|
|
|
|
|
|
:param type: The element type (:attr:`Type.type`)
|
|
|
|
:param length: :attr:`Type.length`
|
|
|
|
:param qualifiers: :attr:`Type.qualifiers`
|
|
|
|
:param lang: :attr:`Type.language`
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def function_type(
|
|
|
|
self,
|
|
|
|
type: Type,
|
|
|
|
parameters: Sequence[TypeParameter],
|
|
|
|
is_variadic: bool = False,
|
|
|
|
*,
|
2021-01-09 01:28:27 +00:00
|
|
|
template_parameters: Sequence[TypeTemplateParameter] = (),
|
2020-08-27 01:25:30 +01:00
|
|
|
qualifiers: Qualifiers = Qualifiers.NONE,
|
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
|
|
|
language: Optional[Language] = None,
|
|
|
|
) -> Type:
|
|
|
|
"""
|
|
|
|
Create a new function type. It has kind :attr:`TypeKind.FUNCTION`.
|
|
|
|
|
|
|
|
:param type: The return type (:attr:`Type.type`)
|
|
|
|
:param parameters: :attr:`Type.parameters`
|
|
|
|
:param is_variadic: :attr:`Type.is_variadic`
|
2021-01-09 01:28:27 +00:00
|
|
|
:param template_parameters: :attr:`Type.template_parameters`
|
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
|
|
|
:param qualifiers: :attr:`Type.qualifiers`
|
|
|
|
:param lang: :attr:`Type.language`
|
|
|
|
"""
|
|
|
|
...
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
class ProgramFlags(enum.Flag):
|
|
|
|
"""
|
|
|
|
``ProgramFlags`` are flags that can apply to a :class:`Program` (e.g.,
|
|
|
|
about what kind of program it is).
|
|
|
|
"""
|
|
|
|
|
|
|
|
IS_LINUX_KERNEL = ...
|
|
|
|
"""The program is the Linux kernel."""
|
|
|
|
|
|
|
|
IS_LIVE = ...
|
|
|
|
"""
|
|
|
|
The program is currently running (e.g., it is the running operating system
|
|
|
|
kernel or a running process).
|
|
|
|
"""
|
|
|
|
|
2023-06-29 21:27:16 +01:00
|
|
|
IS_LOCAL = ...
|
|
|
|
"""
|
|
|
|
The program is running on the local machine.
|
|
|
|
"""
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
class FindObjectFlags(enum.Flag):
|
|
|
|
"""
|
|
|
|
``FindObjectFlags`` are flags for :meth:`Program.object()`. These can be
|
|
|
|
combined to search for multiple kinds of objects at once.
|
|
|
|
"""
|
|
|
|
|
|
|
|
CONSTANT = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
FUNCTION = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
VARIABLE = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
ANY = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2023-11-01 21:24:37 +00:00
|
|
|
def get_default_prog() -> Program:
|
|
|
|
"""
|
|
|
|
Get the default program for the current thread.
|
|
|
|
|
|
|
|
:raises NoDefaultProgramError: if the default program is not set
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
|
|
|
# prog is positional-only.
|
|
|
|
def set_default_prog(prog: Optional[Program]) -> None:
|
|
|
|
"""
|
|
|
|
Set the default program for the current thread.
|
|
|
|
|
|
|
|
:param prog: Program to set as the default, or ``None`` to unset it.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
|
|
|
class NoDefaultProgramError(Exception):
|
|
|
|
"""
|
|
|
|
Error raised when trying to use the default program when it is not set.
|
|
|
|
"""
|
|
|
|
|
|
|
|
...
|
|
|
|
|
2021-11-19 00:46:59 +00:00
|
|
|
class Thread:
|
|
|
|
"""A thread in a program."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
tid: Final[int]
|
2022-08-26 18:30:34 +01:00
|
|
|
"""Thread ID (as defined by :manpage:`gettid(2)`)."""
|
2023-01-18 23:01:24 +00:00
|
|
|
object: Final[Object]
|
2021-11-19 00:46:59 +00:00
|
|
|
"""
|
|
|
|
If the program is the Linux kernel, the ``struct task_struct *`` object for
|
|
|
|
this thread. Otherwise, not defined.
|
|
|
|
"""
|
|
|
|
def stack_trace(self) -> StackTrace:
|
|
|
|
"""
|
|
|
|
Get the stack trace for this thread.
|
|
|
|
|
|
|
|
This is equivalent to ``prog.stack_trace(thread.tid)``. See
|
|
|
|
:meth:`Program.stack_trace()`.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
def filename_matches(haystack: Optional[str], needle: Optional[str]) -> bool:
|
|
|
|
"""
|
|
|
|
Return whether a filename containing a definition (*haystack*) matches a
|
|
|
|
filename being searched for (*needle*).
|
|
|
|
|
|
|
|
The filename is matched from right to left, so ``'stdio.h'``,
|
|
|
|
``'include/stdio.h'``, ``'usr/include/stdio.h'``, and
|
|
|
|
``'/usr/include/stdio.h'`` would all match a definition in
|
|
|
|
``/usr/include/stdio.h``. If *needle* is ``None`` or empty, it matches any
|
|
|
|
definition. If *haystack* is ``None`` or empty, it only matches if *needle*
|
|
|
|
is also ``None`` or empty.
|
|
|
|
|
|
|
|
:param haystack: Path of file containing definition.
|
|
|
|
:param needle: Filename to match.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2023-08-16 07:38:04 +01:00
|
|
|
def program_from_core_dump(path: Union[Path, int]) -> Program:
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Create a :class:`Program` from a core dump file. The type of program (e.g.,
|
|
|
|
userspace or kernel) is determined automatically.
|
|
|
|
|
2023-08-16 07:38:04 +01:00
|
|
|
:param path: Core dump file path or open file descriptor.
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
|
|
|
def program_from_kernel() -> Program:
|
|
|
|
"""
|
|
|
|
Create a :class:`Program` from the running operating system kernel. This
|
|
|
|
requires root privileges.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
|
|
|
def program_from_pid(pid: int) -> Program:
|
|
|
|
"""
|
|
|
|
Create a :class:`Program` from a running program with the given PID. This
|
|
|
|
requires appropriate permissions (on Linux, :manpage:`ptrace(2)` attach
|
|
|
|
permissions).
|
|
|
|
|
|
|
|
:param pid: Process ID of the program to debug.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
|
|
|
class Platform:
|
|
|
|
"""
|
|
|
|
A ``Platform`` represents the environment (i.e., architecture and ABI) that
|
|
|
|
a program runs on.
|
|
|
|
"""
|
|
|
|
|
|
|
|
def __init__(
|
|
|
|
self, arch: Architecture, flags: Optional[PlatformFlags] = None
|
2020-08-17 04:40:47 +01:00
|
|
|
) -> None:
|
|
|
|
"""
|
2020-12-11 00:38:09 +00:00
|
|
|
Create a ``Platform``.
|
|
|
|
|
2020-08-17 04:40:47 +01:00
|
|
|
:param arch: :attr:`Platform.arch`
|
|
|
|
:param flags: :attr:`Platform.flags`; if ``None``, default flags for
|
|
|
|
the architecture are used.
|
|
|
|
"""
|
|
|
|
...
|
2023-01-18 23:01:24 +00:00
|
|
|
arch: Final[Architecture]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""Instruction set architecture of this platform."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
flags: Final[PlatformFlags]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""Flags which apply to this platform."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
registers: Final[Sequence[Register]]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""Processor registers on this platform."""
|
|
|
|
|
|
|
|
class Architecture(enum.Enum):
|
2020-12-11 00:38:09 +00:00
|
|
|
"""An ``Architecture`` represents an instruction set architecture."""
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
X86_64 = ...
|
2021-12-03 01:12:25 +00:00
|
|
|
"""The x86-64 architecture, a.k.a. AMD64 or Intel 64."""
|
|
|
|
|
|
|
|
I386 = ...
|
|
|
|
"""The 32-bit x86 architecture, a.k.a. i386 or IA-32."""
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2021-12-02 11:13:51 +00:00
|
|
|
AARCH64 = ...
|
|
|
|
"""The AArch64 architecture, a.k.a. ARM64."""
|
|
|
|
|
2021-12-03 06:21:31 +00:00
|
|
|
ARM = ...
|
|
|
|
"""The 32-bit Arm architecture."""
|
|
|
|
|
2020-11-27 12:06:56 +00:00
|
|
|
PPC64 = ...
|
|
|
|
"""The 64-bit PowerPC architecture."""
|
|
|
|
|
2021-12-03 09:56:19 +00:00
|
|
|
RISCV64 = ...
|
|
|
|
"""The 64-bit RISC-V architecture."""
|
|
|
|
|
|
|
|
RISCV32 = ...
|
|
|
|
"""The 32-bit RISC-V architecture."""
|
|
|
|
|
2021-12-03 10:57:34 +00:00
|
|
|
S390X = ...
|
|
|
|
"""The s390x architecture, a.k.a. IBM Z or z/Architecture."""
|
|
|
|
|
|
|
|
S390 = ...
|
|
|
|
"""The 32-bit s390 architecture, a.k.a. System/390."""
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
UNKNOWN = ...
|
|
|
|
"""
|
|
|
|
An architecture which is not known to drgn. Certain features are not
|
|
|
|
available when the architecture is unknown, but most of drgn will still
|
|
|
|
work.
|
|
|
|
"""
|
|
|
|
|
|
|
|
class PlatformFlags(enum.Flag):
|
|
|
|
"""``PlatformFlags`` are flags describing a :class:`Platform`."""
|
|
|
|
|
|
|
|
IS_64_BIT = ...
|
|
|
|
"""Platform is 64-bit."""
|
|
|
|
|
|
|
|
IS_LITTLE_ENDIAN = ...
|
|
|
|
"""Platform is little-endian."""
|
|
|
|
|
|
|
|
class Register:
|
|
|
|
"""A ``Register`` represents information about a processor register."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
names: Final[Sequence[str]]
|
2021-01-28 23:49:21 +00:00
|
|
|
"""Names of this register."""
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
host_platform: Platform
|
|
|
|
"""The platform of the host which is running drgn."""
|
|
|
|
|
2020-02-21 23:08:37 +00:00
|
|
|
class Language:
|
|
|
|
"""
|
|
|
|
A ``Language`` represents a programming language supported by drgn.
|
|
|
|
|
|
|
|
This class cannot be constructed; there are singletons for the supported
|
|
|
|
languages.
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
name: Final[str]
|
2020-02-21 23:08:37 +00:00
|
|
|
"""Name of the programming language."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
C: ClassVar[Language]
|
2020-02-21 23:08:37 +00:00
|
|
|
"""The C programming language."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
CPP: ClassVar[Language]
|
2022-02-16 20:38:38 +00:00
|
|
|
"""The C++ programming language."""
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
class Object:
|
|
|
|
"""
|
|
|
|
An ``Object`` represents a symbol or value in a program. An object may
|
2020-12-04 21:27:01 +00:00
|
|
|
exist in the memory of the program (a *reference*), it may be a constant or
|
|
|
|
temporary computed value (a *value*), or it may be absent entirely (an
|
2020-12-29 22:41:01 +00:00
|
|
|
*absent* object).
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
All instances of this class have two attributes: :attr:`prog_`, the program
|
|
|
|
that the object is from; and :attr:`type_`, the type of the object.
|
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
|
|
|
Reference objects also have an :attr:`address_` and a :attr:`bit_offset_`.
|
|
|
|
Objects may also have a :attr:`bit_field_size_`.
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
:func:`repr()` of an object returns a Python representation of the object:
|
|
|
|
|
|
|
|
>>> print(repr(prog['jiffies']))
|
|
|
|
Object(prog, 'volatile unsigned long', address=0xffffffffbf005000)
|
|
|
|
|
|
|
|
:class:`str() <str>` returns a "pretty" representation of the object in
|
|
|
|
programming language syntax:
|
|
|
|
|
|
|
|
>>> print(prog['jiffies'])
|
|
|
|
(volatile unsigned long)4326237045
|
|
|
|
|
|
|
|
The output format of ``str()`` can be modified by using the
|
|
|
|
:meth:`format_()` method instead:
|
|
|
|
|
|
|
|
>>> sysname = prog['init_uts_ns'].name.sysname
|
|
|
|
>>> print(sysname)
|
|
|
|
(char [65])"Linux"
|
|
|
|
>>> print(sysname.format_(type_name=False))
|
|
|
|
"Linux"
|
|
|
|
>>> print(sysname.format_(string=False))
|
|
|
|
(char [65]){ 76, 105, 110, 117, 120 }
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
The drgn CLI is set up so that objects are displayed in the "pretty"
|
2020-12-04 21:27:01 +00:00
|
|
|
format instead of with ``repr()`` (the latter is the default behavior
|
|
|
|
of Python's interactive mode). Therefore, it's usually not necessary to
|
2020-02-25 19:43:01 +00:00
|
|
|
call ``print()`` in the drgn CLI.
|
|
|
|
|
|
|
|
Objects support the following operators:
|
|
|
|
|
|
|
|
* Arithmetic operators: ``+``, ``-``, ``*``, ``/``, ``%``
|
|
|
|
* Bitwise operators: ``<<``, ``>>``, ``&``, ``|``, ``^``, ``~``
|
|
|
|
* Relational operators: ``==``, ``!=``, ``<``, ``>``, ``<=``, ``>=``
|
|
|
|
* Subscripting: :meth:`[] <__getitem__>` (Python does not have a unary
|
|
|
|
``*`` operator, so pointers are dereferenced with ``ptr[0]``)
|
2023-11-06 23:48:18 +00:00
|
|
|
* Member access: :meth:`. <__getattr__>` (Python does not have a ``->``
|
|
|
|
operator, so ``.`` is also used to access members of pointers to
|
2020-02-25 19:43:01 +00:00
|
|
|
structures)
|
|
|
|
* The address-of operator: :meth:`drgn.Object.address_of_()` (this is a
|
|
|
|
method because Python does not have a ``&`` operator)
|
|
|
|
* Array length: :meth:`len() <__len__>`
|
|
|
|
|
|
|
|
These operators all have the semantics of the program's programming
|
|
|
|
language. For example, adding two objects from a program written in C
|
|
|
|
results in an object with a type and value according to the rules of C:
|
|
|
|
|
2020-05-15 23:32:25 +01:00
|
|
|
>>> Object(prog, 'unsigned long', 2**64 - 1) + Object(prog, 'int', 1)
|
2020-02-25 19:43:01 +00:00
|
|
|
Object(prog, 'unsigned long', value=0)
|
|
|
|
|
|
|
|
If only one operand to a binary operator is an object, the other operand
|
|
|
|
will be converted to an object according to the language's rules for
|
|
|
|
literals:
|
|
|
|
|
2020-05-15 23:32:25 +01:00
|
|
|
>>> Object(prog, 'char', 0) - 1
|
2020-02-25 19:43:01 +00:00
|
|
|
Object(prog, 'int', value=-1)
|
|
|
|
|
|
|
|
The standard :class:`int() <int>`, :class:`float() <float>`, and
|
|
|
|
:class:`bool() <bool>` functions convert an object to that Python type.
|
|
|
|
Conversion to ``bool`` uses the programming language's notion of
|
|
|
|
"truthiness". Additionally, certain Python functions will automatically
|
|
|
|
coerce an object to the appropriate Python type (e.g., :func:`hex()`,
|
|
|
|
:func:`round()`, and :meth:`list subscripting <object.__getitem__>`).
|
|
|
|
|
|
|
|
Object attributes and methods are named with a trailing underscore to avoid
|
|
|
|
conflicting with structure, union, or class members. The attributes and
|
|
|
|
methods always take precedence; use :meth:`member_()` if there is a
|
|
|
|
conflict.
|
2020-12-11 00:38:09 +00:00
|
|
|
|
|
|
|
Objects are usually obtained directly from a :class:`Program`, but they can
|
|
|
|
be constructed manually, as well (for example, if you got a variable
|
|
|
|
address from a log file).
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
|
2020-12-11 01:44:02 +00:00
|
|
|
@overload
|
2020-02-25 19:43:01 +00:00
|
|
|
def __init__(
|
|
|
|
self,
|
|
|
|
prog: Program,
|
2020-12-11 01:44:02 +00:00
|
|
|
type: Union[str, Type],
|
|
|
|
# This should use numbers.Number, but mypy doesn't support it yet; see
|
|
|
|
# python/mypy#3186. Additionally, once mypy supports recursive types,
|
|
|
|
# we can make the Mapping and Sequence item types stricter; see
|
|
|
|
# python/mypy#731.
|
|
|
|
value: Union[IntegerLike, float, bool, Mapping[str, Any], Sequence[Any]],
|
2020-02-25 19:43:01 +00:00
|
|
|
*,
|
2020-08-13 22:47:59 +01:00
|
|
|
bit_field_size: Optional[IntegerLike] = None,
|
2020-08-17 04:40:47 +01:00
|
|
|
) -> None:
|
|
|
|
"""
|
2020-12-11 01:44:02 +00:00
|
|
|
Create a value object given its type and value.
|
2020-08-17 04:40:47 +01:00
|
|
|
|
2020-12-11 01:44:02 +00:00
|
|
|
:param prog: Program to create the object in.
|
|
|
|
:param type: Type of the object.
|
|
|
|
:param value: Value of the object. See :meth:`value_()`.
|
|
|
|
:param bit_field_size: Size in bits of the object if it is a bit field.
|
|
|
|
The default is ``None``, which means the object is not a bit field.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
@overload
|
|
|
|
def __init__(self, prog: Program, *, value: Union[int, float, bool]) -> None:
|
2020-08-17 04:40:47 +01:00
|
|
|
"""
|
2020-12-11 01:44:02 +00:00
|
|
|
Create a value object from a "literal".
|
|
|
|
|
|
|
|
This is used to emulate a literal number in the source code of the
|
|
|
|
program. The type is deduced from *value* according to the language's
|
|
|
|
rules for literals.
|
|
|
|
|
|
|
|
:param value: Value of the literal.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
@overload
|
|
|
|
def __init__(
|
|
|
|
self,
|
|
|
|
prog: Program,
|
|
|
|
type: Union[str, Type],
|
|
|
|
*,
|
|
|
|
address: IntegerLike,
|
2020-12-11 19:18:54 +00:00
|
|
|
bit_offset: IntegerLike = 0,
|
2020-12-11 01:44:02 +00:00
|
|
|
bit_field_size: Optional[IntegerLike] = None,
|
|
|
|
) -> None:
|
|
|
|
"""
|
|
|
|
Create a reference object.
|
|
|
|
|
|
|
|
:param address: Address of the object in the program.
|
2020-12-11 19:18:54 +00:00
|
|
|
:param bit_offset: Offset in bits from *address* to the beginning of
|
|
|
|
the object.
|
2020-12-11 01:44:02 +00:00
|
|
|
"""
|
|
|
|
...
|
|
|
|
@overload
|
|
|
|
def __init__(
|
|
|
|
self,
|
|
|
|
prog: Program,
|
|
|
|
type: Union[str, Type],
|
|
|
|
*,
|
|
|
|
bit_field_size: Optional[IntegerLike] = None,
|
|
|
|
) -> None:
|
2020-12-29 22:41:01 +00:00
|
|
|
"""Create an absent object."""
|
2020-08-17 04:40:47 +01:00
|
|
|
...
|
2023-01-18 23:01:24 +00:00
|
|
|
prog_: Final[Program]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""Program that this object is from."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
type_: Final[Type]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""Type of this object."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
absent_: Final[bool]
|
2020-12-29 23:06:40 +00:00
|
|
|
"""
|
|
|
|
Whether this object is absent.
|
|
|
|
|
|
|
|
This is ``False`` for all values and references (even if the reference has
|
|
|
|
an invalid address).
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
address_: Final[Optional[int]]
|
2020-12-04 21:27:01 +00:00
|
|
|
"""
|
|
|
|
Address of this object if it is a reference, ``None`` if it is a value or
|
2020-12-29 22:41:01 +00:00
|
|
|
absent.
|
2020-12-04 21:27:01 +00:00
|
|
|
"""
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
bit_offset_: Final[Optional[int]]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Offset in bits from this object's address to the beginning of the object if
|
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
|
|
|
it is a reference, ``None`` otherwise. This can only be non-zero for
|
|
|
|
scalars.
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
bit_field_size_: Final[Optional[int]]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Size in bits of this object if it is a bit field, ``None`` if it is not.
|
|
|
|
"""
|
2023-11-06 23:48:18 +00:00
|
|
|
def __getattr__(self, name: str) -> Object:
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Implement ``self.name``.
|
|
|
|
|
2023-10-23 19:22:28 +01:00
|
|
|
This corresponds to both the member access (``.``) and member access
|
|
|
|
through pointer (``->``) operators in C.
|
|
|
|
|
2023-11-06 23:48:18 +00:00
|
|
|
Note that if *name* is an attribute or method of the :class:`Object`
|
|
|
|
class, then that takes precedence. Otherwise, this is equivalent to
|
2020-02-25 19:43:01 +00:00
|
|
|
:meth:`member_()`.
|
|
|
|
|
|
|
|
>>> print(prog['init_task'].pid)
|
|
|
|
(pid_t)0
|
|
|
|
|
|
|
|
:param name: Attribute name.
|
|
|
|
"""
|
|
|
|
...
|
2020-08-13 22:47:59 +01:00
|
|
|
def __getitem__(self, idx: IntegerLike) -> Object:
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Implement ``self[idx]``. Get the array element at the given index.
|
|
|
|
|
2023-10-23 19:22:28 +01:00
|
|
|
>>> print(prog['init_task'].comm[1])
|
|
|
|
(char)119
|
|
|
|
|
|
|
|
``[0]`` is also the equivalent of the pointer dereference (``*``)
|
|
|
|
operator in C:
|
|
|
|
|
|
|
|
>>> ptr_to_ptr
|
|
|
|
*(void **)0xffff9b86801e2968 = 0xffff9b86801e2460
|
|
|
|
>>> print(ptr_to_ptr[0])
|
|
|
|
(void *)0xffff9b86801e2460
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
This is only valid for pointers and arrays.
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
Negative indices behave as they would in the object's language (as
|
|
|
|
opposed to the Python semantics of indexing from the end of the
|
|
|
|
array).
|
|
|
|
|
|
|
|
:param idx: The array index.
|
|
|
|
:raises TypeError: if this object is not a pointer or array
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def __len__(self) -> int:
|
|
|
|
"""
|
|
|
|
Implement ``len(self)``. Get the number of elements in this object.
|
|
|
|
|
|
|
|
>>> len(prog['init_task'].comm)
|
|
|
|
16
|
|
|
|
|
|
|
|
This is only valid for arrays.
|
|
|
|
|
|
|
|
:raises TypeError: if this object is not an array with complete type
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def value_(self) -> Any:
|
|
|
|
"""
|
|
|
|
Get the value of this object as a Python object.
|
|
|
|
|
|
|
|
For basic types (integer, floating-point, boolean), this returns an
|
|
|
|
object of the directly corresponding Python type (``int``, ``float``,
|
|
|
|
``bool``). For pointers, this returns the address value of the pointer.
|
|
|
|
For enums, this returns an ``int``. For structures and unions, this
|
|
|
|
returns a ``dict`` of members. For arrays, this returns a ``list`` of
|
|
|
|
values.
|
|
|
|
|
|
|
|
:raises FaultError: if reading the object causes a bad memory access
|
|
|
|
:raises TypeError: if this object has an unreadable type (e.g.,
|
|
|
|
``void``)
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def string_(self) -> bytes:
|
|
|
|
"""
|
|
|
|
Read a null-terminated string pointed to by this 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.
|
|
|
|
|
|
|
|
:raises FaultError: if reading the string causes a bad memory access
|
|
|
|
:raises TypeError: if this object is not a pointer or array
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def member_(self, name: str) -> Object:
|
|
|
|
"""
|
|
|
|
Get a member of this object.
|
|
|
|
|
2023-10-23 19:22:28 +01:00
|
|
|
This is valid for structures, unions, classes, and pointers to any of
|
|
|
|
those. If the object is a pointer, it is automatically dereferenced
|
|
|
|
first.
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2023-11-06 23:48:18 +00:00
|
|
|
Normally the dot operator (:meth:`. <__getattr__>`) can be used to
|
2023-10-23 19:22:28 +01:00
|
|
|
accomplish the same thing, but this method can be used if there is a
|
2023-11-06 23:48:18 +00:00
|
|
|
name conflict with an ``Object`` attribute or method.
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
:param name: Name of the member.
|
|
|
|
:raises TypeError: if this object is not a structure, union, class, or
|
|
|
|
a pointer to one of those
|
|
|
|
:raises LookupError: if this object does not have a member with the
|
|
|
|
given name
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def address_of_(self) -> Object:
|
|
|
|
"""
|
|
|
|
Get a pointer to this object.
|
|
|
|
|
|
|
|
This corresponds to the address-of (``&``) operator in C. It is only
|
|
|
|
possible for reference objects, as value objects don't have an address
|
|
|
|
in the program.
|
|
|
|
|
|
|
|
As opposed to :attr:`address_`, this returns an ``Object``, not an
|
|
|
|
``int``.
|
|
|
|
|
|
|
|
:raises ValueError: if this object is a value
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def read_(self) -> Object:
|
|
|
|
"""
|
|
|
|
Read this object (which may be a reference or a value) and return it as
|
|
|
|
a value object.
|
|
|
|
|
|
|
|
This is useful if the object can change in the running program (but of
|
|
|
|
course nothing stops the program from modifying the object while it is
|
|
|
|
being read).
|
|
|
|
|
|
|
|
As opposed to :meth:`value_()`, this returns an ``Object``, not a
|
|
|
|
standard Python type.
|
|
|
|
|
|
|
|
:raises FaultError: if reading this object causes a bad memory access
|
|
|
|
:raises TypeError: if this object has an unreadable type (e.g.,
|
|
|
|
``void``)
|
|
|
|
"""
|
|
|
|
...
|
2021-07-22 10:02:20 +01:00
|
|
|
def to_bytes_(self) -> bytes:
|
|
|
|
"""Return the binary representation of this object's value."""
|
|
|
|
...
|
2021-07-22 03:00:43 +01:00
|
|
|
@classmethod
|
|
|
|
def from_bytes_(
|
|
|
|
cls,
|
|
|
|
prog: Program,
|
|
|
|
type: Union[str, Type],
|
|
|
|
bytes: bytes,
|
|
|
|
*,
|
|
|
|
bit_offset: IntegerLike = 0,
|
|
|
|
bit_field_size: Optional[IntegerLike] = None,
|
|
|
|
) -> Object:
|
|
|
|
"""
|
|
|
|
Return a value object from its binary representation.
|
|
|
|
|
|
|
|
:param prog: Program to create the object in.
|
|
|
|
:param type: Type of the object.
|
|
|
|
:param bytes: Buffer containing value of the object.
|
|
|
|
:param bit_offset: Offset in bits from the beginning of *bytes* to the
|
|
|
|
beginning of the object.
|
|
|
|
:param bit_field_size: Size in bits of the object if it is a bit field.
|
|
|
|
The default is ``None``, which means the object is not a bit field.
|
|
|
|
"""
|
|
|
|
...
|
2020-02-25 19:43:01 +00:00
|
|
|
def format_(
|
|
|
|
self,
|
|
|
|
*,
|
2020-08-13 22:47:59 +01:00
|
|
|
columns: Optional[IntegerLike] = None,
|
2020-02-25 19:43:01 +00:00
|
|
|
dereference: Optional[bool] = None,
|
|
|
|
symbolize: Optional[bool] = None,
|
|
|
|
string: Optional[bool] = None,
|
|
|
|
char: Optional[bool] = None,
|
|
|
|
type_name: Optional[bool] = None,
|
|
|
|
member_type_names: Optional[bool] = None,
|
|
|
|
element_type_names: Optional[bool] = None,
|
|
|
|
members_same_line: Optional[bool] = None,
|
|
|
|
elements_same_line: Optional[bool] = None,
|
|
|
|
member_names: Optional[bool] = None,
|
|
|
|
element_indices: Optional[bool] = None,
|
|
|
|
implicit_members: Optional[bool] = None,
|
|
|
|
implicit_elements: Optional[bool] = None,
|
|
|
|
) -> str:
|
|
|
|
"""
|
|
|
|
Format this object in programming language syntax.
|
|
|
|
|
|
|
|
Various format options can be passed (as keyword arguments) to control
|
|
|
|
the output. Options that aren't passed or are passed as ``None`` fall
|
|
|
|
back to a default. Specifically, ``obj.format_()`` (i.e., with no
|
|
|
|
passed options) is equivalent to ``str(obj)``.
|
|
|
|
|
|
|
|
>>> workqueues = prog['workqueues']
|
|
|
|
>>> print(workqueues)
|
|
|
|
(struct list_head){
|
|
|
|
.next = (struct list_head *)0xffff932ecfc0ae10,
|
|
|
|
.prev = (struct list_head *)0xffff932e3818fc10,
|
|
|
|
}
|
|
|
|
>>> print(workqueues.format_(type_name=False,
|
|
|
|
... member_type_names=False,
|
|
|
|
... member_names=False,
|
|
|
|
... members_same_line=True))
|
|
|
|
{ 0xffff932ecfc0ae10, 0xffff932e3818fc10 }
|
|
|
|
|
|
|
|
:param columns: Number of columns to limit output to when the
|
|
|
|
expression can be reasonably wrapped. Defaults to no limit.
|
|
|
|
:param dereference: If this object is a pointer, include the
|
|
|
|
dereferenced value. This does not apply to structure, union, or
|
|
|
|
class members, or array elements, as dereferencing those could lead
|
|
|
|
to an infinite loop. Defaults to ``True``.
|
|
|
|
:param symbolize: Include a symbol name and offset for pointer objects.
|
|
|
|
Defaults to ``True``.
|
|
|
|
:param string: Format the values of objects with string type as strings.
|
|
|
|
For C, this applies to pointers to and arrays of ``char``, ``signed
|
|
|
|
char``, and ``unsigned char``. Defaults to ``True``.
|
|
|
|
:param char: Format objects with character type as character literals.
|
|
|
|
For C, this applies to ``char``, ``signed char``, and ``unsigned
|
|
|
|
char``. Defaults to ``False``.
|
|
|
|
:param type_name: Include the type name of this object. Defaults to
|
|
|
|
``True``.
|
|
|
|
:param member_type_names: Include the type names of structure, union,
|
|
|
|
and class members. Defaults to ``True``.
|
|
|
|
:param element_type_names: Include the type names of array elements.
|
|
|
|
Defaults to ``False``.
|
|
|
|
:param members_same_line: Place multiple structure, union, and class
|
|
|
|
members on the same line if they fit within the specified
|
|
|
|
number of ``columns``. Defaults to ``False``.
|
|
|
|
:param elements_same_line: Place multiple array elements on the same
|
|
|
|
line if they fit within the specified number of ``columns``.
|
|
|
|
Defaults to ``True``.
|
|
|
|
:param member_names: Include the names of structure, union, and class
|
|
|
|
members. Defaults to ``True``.
|
|
|
|
:param element_indices: Include the indices of array elements. Defaults
|
|
|
|
to ``False``.
|
|
|
|
:param implicit_members: Include structure, union, and class members
|
|
|
|
which have an implicit value (i.e., for C, zero-initialized).
|
|
|
|
Defaults to ``True``.
|
|
|
|
:param implicit_elements: Include array elements which have an implicit
|
|
|
|
value (i.e., for C, zero-initialized). Defaults to ``False``.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def __iter__(self) -> Iterator[Object]: ...
|
|
|
|
def __bool__(self) -> bool: ...
|
|
|
|
def __lt__(self, other: Any) -> bool: ...
|
|
|
|
def __le__(self, other: Any) -> bool: ...
|
|
|
|
def __eq__(self, other: Any) -> bool: ...
|
|
|
|
def __ne__(self, other: Any) -> bool: ...
|
|
|
|
def __gt__(self, other: Any) -> bool: ...
|
|
|
|
def __ge__(self, other: Any) -> bool: ...
|
|
|
|
def __add__(self, other: Any) -> Object: ...
|
|
|
|
def __sub__(self, other: Any) -> Object: ...
|
|
|
|
def __mul__(self, other: Any) -> Object: ...
|
|
|
|
def __truediv__(self, other: Any) -> Object: ...
|
|
|
|
def __mod__(self, other: Any) -> Object: ...
|
|
|
|
def __lshift__(self, other: Any) -> Object: ...
|
|
|
|
def __rshift__(self, other: Any) -> Object: ...
|
|
|
|
def __and__(self, other: Any) -> Object: ...
|
|
|
|
def __xor__(self, other: Any) -> Object: ...
|
|
|
|
def __or__(self, other: Any) -> Object: ...
|
|
|
|
def __radd__(self, other: Any) -> Object: ...
|
|
|
|
def __rsub__(self, other: Any) -> Object: ...
|
|
|
|
def __rmul__(self, other: Any) -> Object: ...
|
|
|
|
def __rtruediv__(self, other: Any) -> Object: ...
|
|
|
|
def __rmod__(self, other: Any) -> Object: ...
|
|
|
|
def __rlshift__(self, other: Any) -> Object: ...
|
|
|
|
def __rrshift__(self, other: Any) -> Object: ...
|
|
|
|
def __rand__(self, other: Any) -> Object: ...
|
|
|
|
def __rxor__(self, other: Any) -> Object: ...
|
|
|
|
def __ror__(self, other: Any) -> Object: ...
|
|
|
|
def __neg__(self) -> Object: ...
|
|
|
|
def __pos__(self) -> Object: ...
|
|
|
|
def __invert__(self) -> Object: ...
|
|
|
|
def __int__(self) -> int: ...
|
|
|
|
def __float__(self) -> float: ...
|
|
|
|
def __index__(self) -> int: ...
|
|
|
|
@overload
|
|
|
|
def __round__(self, ndigits: None = None) -> int: ...
|
|
|
|
@overload
|
|
|
|
def __round__(self, ndigits: int) -> Any: ...
|
|
|
|
def __trunc__(self) -> int: ...
|
|
|
|
def __floor__(self) -> int: ...
|
|
|
|
def __ceil__(self) -> int: ...
|
2022-08-15 10:07:18 +01:00
|
|
|
def _repr_pretty_(self, p: Any, cycle: bool) -> None: ...
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
def NULL(prog: Program, type: Union[str, Type]) -> Object:
|
|
|
|
"""
|
|
|
|
Get an object representing ``NULL`` casted to the given type.
|
|
|
|
|
2020-05-15 23:32:25 +01:00
|
|
|
This is equivalent to ``Object(prog, type, 0)``.
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
:param prog: The program.
|
|
|
|
:param type: The type.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
|
|
|
def cast(type: Union[str, Type], obj: Object) -> Object:
|
|
|
|
"""
|
|
|
|
Get the value of the given object casted to another type.
|
|
|
|
|
|
|
|
Objects with a scalar type (integer, boolean, enumerated, floating-point,
|
|
|
|
or pointer) can be casted to a different scalar type. Other objects can
|
|
|
|
only be casted to the same type. This always results in a value object. See
|
|
|
|
also :func:`drgn.reinterpret()`.
|
|
|
|
|
2024-01-12 23:43:54 +00:00
|
|
|
>>> cast("unsigned int", Object(prog, "float", 2.0))
|
|
|
|
(unsigned int)2
|
|
|
|
|
|
|
|
:param type: Type to cast to.
|
|
|
|
:param obj: Object to cast.
|
2020-02-25 19:43:01 +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
|
|
|
def reinterpret(type: Union[str, Type], obj: Object) -> Object:
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
2024-01-12 23:43:54 +00:00
|
|
|
Get the representation of an object reinterpreted as another type.
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
This reinterprets the raw memory of the object, so an object can be
|
2024-01-12 23:43:54 +00:00
|
|
|
reinterpreted as any other type. Reinterpreting a reference results in a
|
|
|
|
reference, and reinterpreting a value results in a value. See also
|
|
|
|
:func:`drgn.cast()`.
|
|
|
|
|
|
|
|
>>> reinterpret("unsigned int", Object(prog, "float", 2.0))
|
|
|
|
(unsigned int)1073741824
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2024-01-12 23:43:54 +00:00
|
|
|
:param type: Type to reinterpret as.
|
|
|
|
:param obj: Object to reinterpret.
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
|
|
|
def container_of(ptr: Object, type: Union[str, Type], member: str) -> Object:
|
|
|
|
"""
|
|
|
|
Get the containing object of a pointer object.
|
|
|
|
|
|
|
|
This corresponds to the ``container_of()`` macro in C.
|
|
|
|
|
2020-12-16 00:35:18 +00:00
|
|
|
:param ptr: Pointer to member in containing object.
|
|
|
|
:param type: Type of containing object.
|
|
|
|
:param member: Name of member in containing object. May include one or more
|
|
|
|
member references and zero or more array subscripts.
|
|
|
|
:return: Pointer to containing object.
|
|
|
|
:raises TypeError: if *ptr* is not a pointer or *type* is not a structure,
|
|
|
|
union, or class type
|
|
|
|
:raises ValueError: if the member is not byte-aligned (e.g., because it is
|
|
|
|
a bit field)
|
|
|
|
:raises LookupError: if *type* does not have a member with the given name
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
|
|
|
class Symbol:
|
|
|
|
"""
|
|
|
|
A ``Symbol`` represents an entry in the symbol table of a program, i.e., an
|
|
|
|
identifier along with its corresponding address range in the program.
|
|
|
|
"""
|
|
|
|
|
2024-04-26 00:14:18 +01:00
|
|
|
def __init__(
|
|
|
|
self,
|
|
|
|
name: str,
|
|
|
|
address: int,
|
|
|
|
size: int,
|
|
|
|
binding: SymbolBinding,
|
|
|
|
kind: SymbolKind,
|
|
|
|
) -> None:
|
|
|
|
"""
|
|
|
|
Create a ``Symbol``.
|
|
|
|
|
|
|
|
:param name: :attr:`Symbol.name`
|
|
|
|
:param address: :attr:`Symbol.address`
|
|
|
|
:param size: :attr:`Symbol.size`
|
|
|
|
:param binding: :attr:`Symbol.binding`
|
|
|
|
:param kind: :attr:`Symbol.kind`
|
|
|
|
"""
|
|
|
|
...
|
2023-01-18 23:01:24 +00:00
|
|
|
name: Final[str]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""Name of this symbol."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
address: Final[int]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""Start address of this symbol."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
size: Final[int]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""Size of this symbol in bytes."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
binding: Final[SymbolBinding]
|
2021-08-19 22:12:48 +01:00
|
|
|
"""Linkage behavior and visibility of this symbol."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
kind: Final[SymbolKind]
|
2021-08-19 22:12:48 +01:00
|
|
|
"""Kind of entity represented by this symbol."""
|
|
|
|
|
|
|
|
class SymbolBinding(enum.Enum):
|
|
|
|
"""
|
|
|
|
A ``SymbolBinding`` describes the linkage behavior and visibility of a
|
|
|
|
symbol.
|
|
|
|
"""
|
|
|
|
|
|
|
|
UNKNOWN = ...
|
|
|
|
"""Unknown."""
|
|
|
|
|
|
|
|
LOCAL = ...
|
|
|
|
"""Not visible outside of the object file containing its definition."""
|
|
|
|
|
|
|
|
GLOBAL = ...
|
|
|
|
"""Globally visible."""
|
|
|
|
|
|
|
|
WEAK = ...
|
|
|
|
"""Globally visible but may be overridden by a non-weak global symbol."""
|
|
|
|
|
|
|
|
UNIQUE = ...
|
|
|
|
"""
|
|
|
|
Globally visible even if dynamic shared object is loaded locally. See GCC's
|
|
|
|
``-fno-gnu-unique`` `option
|
|
|
|
<https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html>`_.
|
|
|
|
"""
|
|
|
|
|
|
|
|
class SymbolKind(enum.Enum):
|
|
|
|
"""
|
|
|
|
A ``SymbolKind`` describes the kind of entity that a symbol represents.
|
|
|
|
"""
|
|
|
|
|
|
|
|
UNKNOWN = ...
|
|
|
|
"""Unknown or not defined."""
|
|
|
|
|
|
|
|
OBJECT = ...
|
|
|
|
"""Data object (e.g., variable or array)."""
|
|
|
|
|
|
|
|
FUNC = ...
|
|
|
|
"""Function or other executable code."""
|
|
|
|
|
|
|
|
SECTION = ...
|
|
|
|
"""Object file section."""
|
|
|
|
|
|
|
|
FILE = ...
|
|
|
|
"""Source file."""
|
|
|
|
|
|
|
|
COMMON = ...
|
|
|
|
"""Data object in common block."""
|
|
|
|
|
|
|
|
TLS = ...
|
|
|
|
"""Thread-local storage entity."""
|
|
|
|
|
|
|
|
IFUNC = ...
|
|
|
|
"""`Indirect function <https://sourceware.org/glibc/wiki/GNU_IFUNC>`_."""
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
class StackTrace:
|
|
|
|
"""
|
|
|
|
A ``StackTrace`` is a :ref:`sequence <python:typesseq-common>` of
|
|
|
|
:class:`StackFrame`.
|
|
|
|
|
|
|
|
``len(trace)`` is the number of stack frames in the trace. ``trace[0]`` is
|
|
|
|
the innermost stack frame, ``trace[1]`` is its caller, and
|
|
|
|
``trace[len(trace) - 1]`` is the outermost frame. Negative indexing also
|
|
|
|
works: ``trace[-1]`` is the outermost frame and ``trace[-len(trace)]`` is
|
|
|
|
the innermost frame. It is also iterable:
|
|
|
|
|
|
|
|
.. code-block:: python3
|
|
|
|
|
|
|
|
for frame in trace:
|
2020-12-02 19:24:05 +00:00
|
|
|
if frame.name == 'io_schedule':
|
2020-02-25 19:43:01 +00:00
|
|
|
print('Thread is doing I/O')
|
|
|
|
|
|
|
|
:class:`str() <str>` returns a pretty-printed stack trace:
|
|
|
|
|
2020-12-02 19:24:05 +00:00
|
|
|
>>> prog.stack_trace(1)
|
|
|
|
#0 context_switch (kernel/sched/core.c:4339:2)
|
|
|
|
#1 __schedule (kernel/sched/core.c:5147:8)
|
|
|
|
#2 schedule (kernel/sched/core.c:5226:3)
|
|
|
|
#3 do_wait (kernel/exit.c:1534:4)
|
|
|
|
#4 kernel_wait4 (kernel/exit.c:1678:8)
|
|
|
|
#5 __do_sys_wait4 (kernel/exit.c:1706:13)
|
|
|
|
#6 do_syscall_64 (arch/x86/entry/common.c:47:14)
|
|
|
|
#7 entry_SYSCALL_64+0x7c/0x15b (arch/x86/entry/entry_64.S:112)
|
|
|
|
#8 0x4d49dd
|
|
|
|
|
|
|
|
The format is subject to change. The drgn CLI is set up so that stack
|
|
|
|
traces are displayed with ``str()`` by default.
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
prog: Final[Program]
|
2022-08-11 22:42:21 +01:00
|
|
|
"""Program that this stack trace is from."""
|
|
|
|
|
2020-08-13 22:47:59 +01:00
|
|
|
def __getitem__(self, idx: IntegerLike) -> StackFrame: ...
|
2022-10-25 02:36:57 +01:00
|
|
|
def __len__(self) -> int: ...
|
|
|
|
def __iter__(self) -> Iterator[StackFrame]: ...
|
2022-08-15 10:07:18 +01:00
|
|
|
def _repr_pretty_(self, p: Any, cycle: bool) -> None: ...
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
class StackFrame:
|
|
|
|
"""
|
2021-03-10 09:51:33 +00:00
|
|
|
A ``StackFrame`` represents a single *frame* in a thread's call stack.
|
2020-12-02 19:24:05 +00:00
|
|
|
|
|
|
|
:class:`str() <str>` returns a pretty-printed stack frame:
|
|
|
|
|
|
|
|
>>> prog.stack_trace(1)[0]
|
|
|
|
#0 at 0xffffffffb64ac287 (__schedule+0x227/0x606) in context_switch at kernel/sched/core.c:4339:2 (inlined)
|
|
|
|
|
|
|
|
This includes more information than when printing the full stack trace. The
|
|
|
|
format is subject to change. The drgn CLI is set up so that stack frames
|
|
|
|
are displayed with ``str()`` by default.
|
2021-06-02 21:17:41 +01:00
|
|
|
|
|
|
|
The :meth:`[] <.__getitem__>` operator can look up function parameters,
|
|
|
|
local variables, and global variables in the scope of the stack frame:
|
|
|
|
|
|
|
|
>>> prog.stack_trace(1)[0]['prev'].pid
|
|
|
|
(pid_t)1
|
|
|
|
>>> prog.stack_trace(1)[0]['scheduler_running']
|
|
|
|
(int)1
|
2020-12-02 19:24:05 +00:00
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
name: Final[Optional[str]]
|
2020-12-02 19:24:05 +00:00
|
|
|
"""
|
|
|
|
Name of the function at this frame, or ``None`` if it could not be
|
|
|
|
determined.
|
2022-05-05 16:22:34 +01:00
|
|
|
|
|
|
|
The name cannot be determined if debugging information is not available for
|
|
|
|
the function, e.g., because it is implemented in assembly. It may be
|
|
|
|
desirable to use the symbol name or program counter as a fallback:
|
|
|
|
|
|
|
|
.. code-block:: python3
|
|
|
|
|
|
|
|
name = frame.name
|
|
|
|
if name is None:
|
|
|
|
try:
|
|
|
|
name = frame.symbol().name
|
|
|
|
except LookupError:
|
|
|
|
name = hex(frame.pc)
|
2020-12-02 19:24:05 +00:00
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
is_inline: Final[bool]
|
2020-12-02 19:24:05 +00:00
|
|
|
"""
|
|
|
|
Whether this frame is for an inlined call.
|
|
|
|
|
|
|
|
An inline frame shares the same stack frame in memory as its caller.
|
|
|
|
Therefore, it has the same registers (including program counter and thus
|
|
|
|
symbol).
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
interrupted: Final[bool]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
2021-03-10 09:51:33 +00:00
|
|
|
Whether this stack frame was interrupted (for example, by a hardware
|
|
|
|
interrupt, signal, trap, etc.).
|
|
|
|
|
|
|
|
If this is ``True``, then the register values in this frame are the values
|
|
|
|
at the time that the frame was interrupted.
|
2020-05-14 01:11:54 +01:00
|
|
|
|
2021-03-10 09:51:33 +00:00
|
|
|
This is ``False`` if the frame is for a function call, in which case the
|
|
|
|
register values are the values when control returns to this frame. In
|
|
|
|
particular, the program counter is the return address, which is typically
|
|
|
|
the instruction after the call instruction.
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
2020-12-02 19:24:05 +00:00
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
pc: Final[int]
|
2021-03-10 09:51:33 +00:00
|
|
|
"""Program counter at this stack frame."""
|
2022-11-23 00:51:44 +00:00
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
sp: Final[int]
|
2022-11-23 00:51:44 +00:00
|
|
|
"""Stack pointer at this stack frame."""
|
|
|
|
|
2021-06-02 21:17:41 +01:00
|
|
|
def __getitem__(self, name: str) -> Object:
|
|
|
|
"""
|
|
|
|
Implement ``self[name]``. Get the object (variable, function parameter,
|
|
|
|
constant, or function) with the given name in the scope of this frame.
|
|
|
|
|
|
|
|
If the object exists but has been optimized out, this returns an
|
|
|
|
:ref:`absent object <absent-objects>`.
|
|
|
|
|
|
|
|
:param name: Object name.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def __contains__(self, name: str) -> bool:
|
|
|
|
"""
|
|
|
|
Implement ``name in self``. Return whether an object with the given
|
|
|
|
name exists in the scope of this frame.
|
|
|
|
|
|
|
|
:param name: Object name.
|
|
|
|
"""
|
|
|
|
...
|
2022-05-27 00:42:20 +01:00
|
|
|
def locals(self) -> List[str]:
|
|
|
|
"""
|
|
|
|
Get a list of the names of all local objects (local variables, function
|
|
|
|
parameters, local constants, and nested functions) in the scope of this
|
|
|
|
frame.
|
|
|
|
|
|
|
|
Not all names may have present values, but they can be used with the
|
|
|
|
:meth:`[] <.__getitem__>` operator to check.
|
|
|
|
"""
|
|
|
|
...
|
2020-12-02 19:24:05 +00:00
|
|
|
def source(self) -> Tuple[str, int, int]:
|
|
|
|
"""
|
|
|
|
Get the source code location of this frame.
|
|
|
|
|
|
|
|
:return: Location as a ``(filename, line, column)`` triple.
|
|
|
|
:raises LookupError: if the source code location is not available
|
|
|
|
"""
|
|
|
|
...
|
2020-02-25 19:43:01 +00:00
|
|
|
def symbol(self) -> Symbol:
|
|
|
|
"""
|
2020-05-14 01:11:54 +01:00
|
|
|
Get the function symbol at this stack frame.
|
|
|
|
|
2021-03-10 09:51:33 +00:00
|
|
|
This is equivalent to:
|
|
|
|
|
|
|
|
.. code-block:: python3
|
|
|
|
|
|
|
|
prog.symbol(frame.pc - (0 if frame.interrupted else 1))
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
...
|
2021-01-28 23:49:21 +00:00
|
|
|
def register(self, reg: str) -> int:
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
2021-01-28 23:49:21 +00:00
|
|
|
Get the value of the given register at this stack frame.
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2021-01-28 23:49:21 +00:00
|
|
|
:param reg: Register name.
|
|
|
|
:raises ValueError: if the register name is not recognized
|
|
|
|
:raises LookupError: if the register value is not known
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
...
|
|
|
|
def registers(self) -> Dict[str, int]:
|
|
|
|
"""
|
|
|
|
Get the values of all available registers at this stack frame as a
|
|
|
|
dictionary with the register names as keys.
|
|
|
|
"""
|
|
|
|
...
|
2022-08-15 10:07:18 +01:00
|
|
|
def _repr_pretty_(self, p: Any, cycle: bool) -> None: ...
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
class Type:
|
|
|
|
"""
|
|
|
|
A ``Type`` object describes a type in a program. Each kind of type (e.g.,
|
|
|
|
integer, structure) has different attributes (e.g., name, size). Types can
|
|
|
|
also have qualifiers (e.g., constant, atomic). Accessing an attribute which
|
|
|
|
does not apply to a type raises an :exc:`AttributeError`.
|
|
|
|
|
|
|
|
:func:`repr()` of a ``Type`` returns a Python representation of the type:
|
|
|
|
|
|
|
|
>>> print(repr(prog.type('sector_t')))
|
2021-08-02 23:49:29 +01:00
|
|
|
prog.typedef_type(name='sector_t', type=prog.int_type(name='unsigned long', size=8, is_signed=False))
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
:class:`str() <str>` returns a representation of the type in programming
|
|
|
|
language syntax:
|
|
|
|
|
|
|
|
>>> print(prog.type('sector_t'))
|
|
|
|
typedef unsigned long sector_t
|
|
|
|
|
|
|
|
The drgn CLI is set up so that types are displayed with ``str()`` instead
|
|
|
|
of ``repr()`` by default.
|
|
|
|
|
|
|
|
This class cannot be constructed directly. Instead, use one of the
|
|
|
|
:ref:`api-type-constructors`.
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
prog: Final[Program]
|
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
|
|
|
"""Program that this type is from."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
kind: Final[TypeKind]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""Kind of this type."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
primitive: Final[Optional[PrimitiveType]]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
If this is a primitive type (e.g., ``int`` or ``double``), the kind of
|
|
|
|
primitive type. Otherwise, ``None``.
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
qualifiers: Final[Qualifiers]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""Bitmask of this type's qualifier."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
language: Final[Language]
|
2020-02-26 21:22:51 +00:00
|
|
|
"""Programming language of this type."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
name: Final[str]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Name of this type. This is present for integer, boolean, floating-point,
|
2021-02-17 22:56:33 +00:00
|
|
|
and typedef types.
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
tag: Final[Optional[str]]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Tag of this type, or ``None`` if this is an anonymous type. This is present
|
|
|
|
for structure, union, class, and enumerated types.
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
size: Final[Optional[int]]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Size of this type in bytes, or ``None`` if this is an incomplete type. This
|
2021-02-17 22:56:33 +00:00
|
|
|
is present for integer, boolean, floating-point, structure, union, class,
|
|
|
|
and pointer types.
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
length: Final[Optional[int]]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Number of elements in this type, or ``None`` if this is an incomplete type.
|
|
|
|
This is only present for array types.
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
is_signed: Final[bool]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""Whether this type is signed. This is only present for integer types."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
byteorder: Final[str]
|
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
|
|
|
"""
|
|
|
|
Byte order of this type: ``'little'`` if it is little-endian, or ``'big'``
|
|
|
|
if it is big-endian. This is present for integer, boolean, floating-point,
|
|
|
|
and pointer types.
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
type: Final[Type]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Type underlying this type, defined as follows:
|
|
|
|
|
|
|
|
* For typedef types, the aliased type.
|
|
|
|
* For enumerated types, the compatible integer type, which is ``None`` if
|
|
|
|
this is an incomplete type.
|
|
|
|
* For pointer types, the referenced type.
|
|
|
|
* For array types, the element type.
|
|
|
|
* For function types, the return type.
|
|
|
|
|
|
|
|
For other types, this attribute is not present.
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
members: Final[Optional[Sequence[TypeMember]]]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
List of members of this type, or ``None`` if this is an incomplete type.
|
|
|
|
This is present for structure, union, and class types.
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
enumerators: Final[Optional[Sequence[TypeEnumerator]]]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
List of enumeration constants of this type, or ``None`` if this is an
|
|
|
|
incomplete type. This is only present for enumerated types.
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
parameters: Final[Sequence[TypeParameter]]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
List of parameters of this type. This is only present for function types.
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
is_variadic: Final[bool]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Whether this type takes a variable number of arguments. This is only
|
|
|
|
present for function types.
|
|
|
|
"""
|
2021-01-09 01:28:27 +00:00
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
template_parameters: Final[Sequence[TypeTemplateParameter]]
|
2021-01-09 01:28:27 +00:00
|
|
|
"""
|
|
|
|
List of template parameters of this type. This is present for structure,
|
|
|
|
union, class, and function types.
|
|
|
|
"""
|
2020-02-25 19:43:01 +00:00
|
|
|
def type_name(self) -> str:
|
|
|
|
"""Get a descriptive full name of this type."""
|
|
|
|
...
|
|
|
|
def is_complete(self) -> bool:
|
|
|
|
"""
|
|
|
|
Get whether this type is complete (i.e., the type definition is known).
|
|
|
|
This is always ``False`` for void types. It may be ``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 ``True``.
|
|
|
|
"""
|
|
|
|
...
|
2020-08-27 01:25:30 +01:00
|
|
|
def qualified(self, qualifiers: Qualifiers) -> Type:
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Get a copy of this type with different qualifiers.
|
|
|
|
|
|
|
|
Note that the original qualifiers are replaced, not added to.
|
|
|
|
|
|
|
|
:param qualifiers: New type qualifiers.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def unqualified(self) -> Type:
|
|
|
|
"""Get a copy of this type with no qualifiers."""
|
|
|
|
...
|
2020-12-15 21:59:55 +00:00
|
|
|
def member(self, name: str) -> TypeMember:
|
|
|
|
"""
|
|
|
|
Look up a member in this type by name.
|
|
|
|
|
|
|
|
If this type has any unnamed members, this also matches members of
|
|
|
|
those unnamed members, recursively. If the member is found in an
|
|
|
|
unnamed member, :attr:`TypeMember.bit_offset` and
|
|
|
|
:attr:`TypeMember.offset` are adjusted accordingly.
|
|
|
|
|
|
|
|
:param name: Name of the member.
|
|
|
|
:raises TypeError: if this type is not a structure, union, or class
|
|
|
|
type
|
|
|
|
:raises LookupError: if this type does not have a member with the given
|
|
|
|
name
|
|
|
|
"""
|
|
|
|
...
|
2020-12-15 23:51:11 +00:00
|
|
|
def has_member(self, name: str) -> bool:
|
|
|
|
"""
|
|
|
|
Return whether this type has a member with the given name.
|
|
|
|
|
|
|
|
If this type has any unnamed members, this also matches members of
|
|
|
|
those unnamed members, recursively.
|
|
|
|
|
|
|
|
:param name: Name of the member.
|
|
|
|
:raises TypeError: if this type is not a structure, union, or class
|
|
|
|
type
|
|
|
|
"""
|
2022-08-15 10:07:18 +01:00
|
|
|
def _repr_pretty_(self, p: Any, cycle: bool) -> None: ...
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
class TypeMember:
|
|
|
|
"""
|
|
|
|
A ``TypeMember`` represents a member of a structure, union, or class type.
|
|
|
|
"""
|
|
|
|
|
|
|
|
def __init__(
|
|
|
|
self,
|
2020-12-18 19:01:29 +00:00
|
|
|
object_or_type: Union[Object, Type, Callable[[], Union[Object, Type]]],
|
2020-02-25 19:43:01 +00:00
|
|
|
name: Optional[str] = None,
|
|
|
|
bit_offset: int = 0,
|
2020-08-17 04:40:47 +01:00
|
|
|
) -> None:
|
|
|
|
"""
|
2020-12-11 00:38:09 +00:00
|
|
|
Create a ``TypeMember``.
|
|
|
|
|
2020-12-18 19:01:29 +00:00
|
|
|
:param object_or_type: One of:
|
|
|
|
|
|
|
|
1. :attr:`TypeMember.object` as an :class:`Object`.
|
|
|
|
2. :attr:`TypeMember.type` as a :class:`Type`. In this case,
|
|
|
|
``object`` is set to an absent object with that type.
|
|
|
|
3. A callable that takes no arguments and returns one of the above.
|
|
|
|
It is called when ``object`` or ``type`` is first accessed, and
|
|
|
|
the result is cached.
|
2020-08-17 04:40:47 +01:00
|
|
|
:param name: :attr:`TypeMember.name`
|
|
|
|
:param bit_offset: :attr:`TypeMember.bit_offset`
|
|
|
|
"""
|
|
|
|
...
|
2023-01-18 23:01:24 +00:00
|
|
|
object: Final[Object]
|
2020-12-18 19:01:29 +00:00
|
|
|
"""
|
|
|
|
Member as an :class:`Object`.
|
|
|
|
|
|
|
|
This is the default initializer for the member, or an absent object if the
|
|
|
|
member has no default initializer. (However, the DWARF specification as of
|
|
|
|
version 5 does not actually support default member initializers, so this is
|
|
|
|
usually absent.)
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
type: Final[Type]
|
2020-12-18 19:01:29 +00:00
|
|
|
"""
|
|
|
|
Member type.
|
|
|
|
|
|
|
|
This is a shortcut for ``TypeMember.object.type``.
|
|
|
|
"""
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
name: Final[Optional[str]]
|
2020-08-17 04:40:47 +01:00
|
|
|
"""Member name, or ``None`` if the member is unnamed."""
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
bit_offset: Final[int]
|
2020-08-17 04:40:47 +01:00
|
|
|
"""Offset of the member from the beginning of the type in bits."""
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
offset: Final[int]
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Offset of the member from the beginning of the type in bytes. If the offset
|
|
|
|
is not byte-aligned, accessing this attribute raises :exc:`ValueError`.
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
bit_field_size: Final[Optional[int]]
|
2020-12-25 09:53:23 +00:00
|
|
|
"""
|
|
|
|
Size in bits of this member if it is a bit field, ``None`` if it is not.
|
2020-12-18 19:01:29 +00:00
|
|
|
|
|
|
|
This is a shortcut for ``TypeMember.object.bit_field_size_``.
|
2020-12-25 09:53:23 +00:00
|
|
|
"""
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
class TypeEnumerator:
|
|
|
|
"""
|
|
|
|
A ``TypeEnumerator`` represents a constant in an enumerated type.
|
|
|
|
|
|
|
|
Its name and value may be accessed as attributes or unpacked:
|
|
|
|
|
|
|
|
>>> prog.type('enum pid_type').enumerators[0].name
|
|
|
|
'PIDTYPE_PID'
|
|
|
|
>>> name, value = prog.type('enum pid_type').enumerators[0]
|
|
|
|
>>> value
|
|
|
|
0
|
|
|
|
"""
|
|
|
|
|
2020-08-17 04:40:47 +01:00
|
|
|
def __init__(self, name: str, value: int) -> None:
|
|
|
|
"""
|
2020-12-11 00:38:09 +00:00
|
|
|
Create a ``TypeEnumerator``.
|
|
|
|
|
2020-08-17 04:40:47 +01:00
|
|
|
:param name: :attr:`TypeEnumerator.name`
|
|
|
|
:param value: :attr:`TypeEnumerator.value`
|
|
|
|
"""
|
|
|
|
...
|
2023-01-18 23:01:24 +00:00
|
|
|
name: Final[str]
|
2020-08-17 04:40:47 +01:00
|
|
|
"Enumerator name."
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
value: Final[int]
|
2020-08-17 04:40:47 +01:00
|
|
|
"Enumerator value."
|
2020-02-25 19:43:01 +00:00
|
|
|
def __len__(self) -> int: ...
|
|
|
|
def __getitem__(self, idx: int) -> Any: ...
|
|
|
|
def __iter__(self) -> Iterator[Any]: ...
|
|
|
|
|
|
|
|
class TypeParameter:
|
|
|
|
"""
|
|
|
|
A ``TypeParameter`` represents a parameter of a function type.
|
|
|
|
"""
|
|
|
|
|
|
|
|
def __init__(
|
2020-12-18 19:01:29 +00:00
|
|
|
self,
|
|
|
|
default_argument_or_type: Union[
|
|
|
|
Object, Type, Callable[[], Union[Object, Type]]
|
|
|
|
],
|
|
|
|
name: Optional[str] = None,
|
2020-08-17 04:40:47 +01:00
|
|
|
) -> None:
|
|
|
|
"""
|
2020-12-11 00:38:09 +00:00
|
|
|
Create a ``TypeParameter``.
|
|
|
|
|
2020-12-18 19:01:29 +00:00
|
|
|
:param default_argument_or_type: One of:
|
|
|
|
|
|
|
|
1. :attr:`TypeParameter.default_argument` as an :class:`Object`.
|
|
|
|
2. :attr:`TypeParameter.type` as a :class:`Type`. In this case,
|
|
|
|
``default_argument`` is set to an absent object with that type.
|
|
|
|
3. A callable that takes no arguments and returns one of the above.
|
|
|
|
It is called when ``default_argument`` or ``type`` is first
|
|
|
|
accessed, and the result is cached.
|
2020-08-17 04:40:47 +01:00
|
|
|
:param name: :attr:`TypeParameter.name`
|
|
|
|
"""
|
|
|
|
...
|
2023-01-18 23:01:24 +00:00
|
|
|
default_argument: Final[Object]
|
2020-12-18 19:01:29 +00:00
|
|
|
"""
|
|
|
|
Default argument for parameter.
|
|
|
|
|
|
|
|
If the parameter does not have a default argument, then this is an absent
|
|
|
|
object.
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
Neither GCC nor Clang emits debugging information for default arguments
|
2021-02-17 10:16:23 +00:00
|
|
|
(as of GCC 10 and Clang 11), and drgn does not yet parse it, so this is
|
|
|
|
usually absent.
|
2020-12-18 19:01:29 +00:00
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
type: Final[Type]
|
2020-12-18 19:01:29 +00:00
|
|
|
"""
|
|
|
|
Parameter type.
|
|
|
|
|
|
|
|
This is the same as ``TypeParameter.default_argument.type_``.
|
|
|
|
"""
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
name: Final[Optional[str]]
|
2020-08-17 04:40:47 +01:00
|
|
|
"""Parameter name, or ``None`` if the parameter is unnamed."""
|
2020-02-25 19:43:01 +00:00
|
|
|
|
2021-01-09 01:28:27 +00:00
|
|
|
class TypeTemplateParameter:
|
|
|
|
"""
|
|
|
|
A ``TypeTemplateParameter`` represents a template parameter of a structure,
|
|
|
|
union, class, or function type.
|
|
|
|
"""
|
|
|
|
|
|
|
|
def __init__(
|
|
|
|
self,
|
|
|
|
argument: Union[Type, Object, Callable[[], Union[Type, Object]]],
|
|
|
|
name: Optional[str] = None,
|
|
|
|
is_default: bool = False,
|
|
|
|
) -> None:
|
|
|
|
"""
|
|
|
|
Create a ``TypeTemplateParameter``.
|
|
|
|
|
|
|
|
:param argument: One of:
|
|
|
|
|
|
|
|
1. :attr:`TypeTemplateParameter.argument` as a :class:`Type` if the
|
|
|
|
parameter is a type template parameter.
|
|
|
|
2. :attr:`TypeTemplateParameter.argument` as a non-absent
|
|
|
|
:class:`Object` if the parameter is a non-type template
|
|
|
|
parameter.
|
|
|
|
3. A callable that takes no arguments and returns one of the above.
|
|
|
|
It is called when ``argument`` is first accessed, and the result
|
|
|
|
is cached.
|
|
|
|
:param name: :attr:`TypeTemplateParameter.name`
|
|
|
|
:param is_default: :attr:`TypeTemplateParameter.is_default`
|
|
|
|
"""
|
|
|
|
...
|
2023-01-18 23:01:24 +00:00
|
|
|
argument: Final[Union[Type, Object]]
|
2021-01-09 01:28:27 +00:00
|
|
|
"""
|
|
|
|
Template argument.
|
|
|
|
|
|
|
|
If this is a type template parameter, then this is a :class:`Type`. If this
|
|
|
|
is a non-type template parameter, then this is an :class:`Object`.
|
|
|
|
"""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
name: Final[Optional[str]]
|
2021-01-09 01:28:27 +00:00
|
|
|
"""Template parameter name, or ``None`` if the parameter is unnamed."""
|
|
|
|
|
2023-01-18 23:01:24 +00:00
|
|
|
is_default: Final[bool]
|
2021-01-09 01:28:27 +00:00
|
|
|
"""
|
|
|
|
Whether :attr:`argument` is the default for the template parameter.
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
There are two ways to interpret this:
|
|
|
|
|
|
|
|
1. The argument was omitted entirely and thus defaulted to the
|
|
|
|
default argument.
|
|
|
|
2. The (specified or defaulted) argument is the same as the default
|
|
|
|
argument.
|
|
|
|
|
|
|
|
Compilers are inconsistent about which interpretation they use.
|
|
|
|
|
|
|
|
GCC added this information in version 4.9. Clang added it in version 11
|
|
|
|
(and only when emitting DWARF version 5). If the program was compiled
|
|
|
|
by an older version, this is always false.
|
|
|
|
"""
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
class TypeKind(enum.Enum):
|
|
|
|
"""A ``TypeKind`` represents a kind of type."""
|
|
|
|
|
|
|
|
VOID = ...
|
|
|
|
"""Void type."""
|
|
|
|
|
|
|
|
INT = ...
|
|
|
|
"""Integer type."""
|
|
|
|
|
|
|
|
BOOL = ...
|
|
|
|
"""Boolean type."""
|
|
|
|
|
|
|
|
FLOAT = ...
|
|
|
|
"""Floating-point type."""
|
|
|
|
|
|
|
|
COMPLEX = ...
|
|
|
|
"""Complex type."""
|
|
|
|
|
|
|
|
STRUCT = ...
|
|
|
|
"""Structure type."""
|
|
|
|
|
|
|
|
UNION = ...
|
|
|
|
"""Union type."""
|
|
|
|
|
|
|
|
CLASS = ...
|
|
|
|
"""Class type."""
|
|
|
|
|
|
|
|
ENUM = ...
|
|
|
|
"""Enumerated type."""
|
|
|
|
|
|
|
|
TYPEDEF = ...
|
|
|
|
"""Type definition (a.k.a. alias) type."""
|
|
|
|
|
|
|
|
POINTER = ...
|
|
|
|
"""Pointer type."""
|
|
|
|
|
|
|
|
ARRAY = ...
|
|
|
|
"""Array type."""
|
|
|
|
|
|
|
|
FUNCTION = ...
|
|
|
|
"""Function type."""
|
|
|
|
|
2024-06-04 21:13:35 +01:00
|
|
|
class TypeKindSet(collections.abc.Set[TypeKind]):
|
|
|
|
"""
|
|
|
|
Immutable set of :class:`TypeKind`\\ s.
|
|
|
|
|
|
|
|
>>> kinds = TypeKindSet({TypeKind.STRUCT, TypeKind.CLASS})
|
|
|
|
>>> TypeKind.STRUCT in kinds
|
|
|
|
True
|
|
|
|
>>> TypeKind.INT in kinds
|
|
|
|
False
|
|
|
|
>>> for kind in kinds:
|
|
|
|
... print(kind)
|
|
|
|
...
|
|
|
|
TypeKind.STRUCT
|
|
|
|
TypeKind.CLASS
|
|
|
|
"""
|
|
|
|
|
|
|
|
def __contains__(self, __x: object) -> bool: ...
|
|
|
|
def __iter__(self) -> Iterator[TypeKind]: ...
|
|
|
|
def __len__(self) -> int: ...
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
class PrimitiveType(enum.Enum):
|
|
|
|
"""A ``PrimitiveType`` represents a primitive type known to drgn."""
|
|
|
|
|
|
|
|
C_VOID = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_CHAR = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_SIGNED_CHAR = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_UNSIGNED_CHAR = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_SHORT = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_UNSIGNED_SHORT = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_INT = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_UNSIGNED_INT = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_LONG = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_UNSIGNED_LONG = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_LONG_LONG = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_UNSIGNED_LONG_LONG = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_BOOL = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_FLOAT = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_DOUBLE = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_LONG_DOUBLE = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_SIZE_T = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
C_PTRDIFF_T = ...
|
2020-08-17 04:40:47 +01:00
|
|
|
""
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
class Qualifiers(enum.Flag):
|
|
|
|
"""``Qualifiers`` are modifiers on types."""
|
|
|
|
|
2020-08-27 01:25:30 +01:00
|
|
|
NONE = ...
|
|
|
|
"""No qualifiers."""
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
CONST = ...
|
|
|
|
"""Constant type."""
|
|
|
|
|
|
|
|
VOLATILE = ...
|
|
|
|
"""Volatile type."""
|
|
|
|
|
|
|
|
RESTRICT = ...
|
|
|
|
"""`Restrict <https://en.cppreference.com/w/c/language/restrict>`_ type."""
|
|
|
|
|
|
|
|
ATOMIC = ...
|
|
|
|
"""Atomic type."""
|
|
|
|
|
|
|
|
# type_or_obj is positional-only.
|
|
|
|
def sizeof(type_or_obj: Union[Type, Object]) -> int:
|
|
|
|
"""
|
|
|
|
Get the size of a :class:`Type` or :class:`Object` in bytes.
|
|
|
|
|
|
|
|
:param type_or_obj: Entity to get the size of.
|
|
|
|
:raises TypeError: if the type does not have a size (e.g., because it is
|
|
|
|
incomplete or void)
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2020-12-16 00:35:18 +00:00
|
|
|
def offsetof(type: Type, member: str) -> int:
|
|
|
|
"""
|
|
|
|
Get the offset (in bytes) of a member in a :class:`Type`.
|
|
|
|
|
|
|
|
This corresponds to |offsetof()|_ in C.
|
|
|
|
|
|
|
|
.. |offsetof()| replace:: ``offsetof()``
|
|
|
|
.. _offsetof(): https://en.cppreference.com/w/cpp/types/offsetof
|
|
|
|
|
|
|
|
:param type: Structure, union, or class type.
|
|
|
|
:param member: Name of member. May include one or more member references
|
|
|
|
and zero or more array subscripts.
|
|
|
|
:raises TypeError: if *type* is not a structure, union, or class type
|
|
|
|
:raises ValueError: if the member is not byte-aligned (e.g., because it is
|
|
|
|
a bit field)
|
|
|
|
:raises LookupError: if *type* does not have a member with the given name
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
class FaultError(Exception):
|
|
|
|
"""
|
|
|
|
This error is raised when a bad memory access is attempted (i.e., when
|
|
|
|
accessing a memory address which is not valid in a program).
|
|
|
|
"""
|
|
|
|
|
2021-05-01 01:03:16 +01:00
|
|
|
def __init__(self, message: str, address: int) -> None:
|
2020-08-17 04:40:47 +01:00
|
|
|
"""
|
2021-05-01 01:03:16 +01:00
|
|
|
:param message: :attr:`FaultError.message`
|
2020-08-17 04:40:47 +01:00
|
|
|
:param address: :attr:`FaultError.address`
|
|
|
|
"""
|
|
|
|
...
|
2021-05-01 01:03:16 +01:00
|
|
|
message: str
|
|
|
|
"""Error message."""
|
2020-02-25 19:43:01 +00:00
|
|
|
address: int
|
2020-08-17 04:40:47 +01:00
|
|
|
"""Address that couldn't be accessed."""
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
class MissingDebugInfoError(Exception):
|
|
|
|
"""
|
|
|
|
This error is raised when one or more files in a program do not have debug
|
|
|
|
information.
|
|
|
|
"""
|
|
|
|
|
|
|
|
...
|
|
|
|
|
2020-12-29 22:41:01 +00:00
|
|
|
class ObjectAbsentError(Exception):
|
|
|
|
"""This error is raised when attempting to use an absent object."""
|
2020-12-04 21:27:01 +00:00
|
|
|
|
|
|
|
...
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
class OutOfBoundsError(Exception):
|
|
|
|
"""
|
|
|
|
This error is raised when attempting to access beyond the bounds of a value
|
|
|
|
object.
|
|
|
|
"""
|
|
|
|
|
|
|
|
...
|
2020-04-18 23:10:29 +01:00
|
|
|
|
2021-06-07 18:56:15 +01:00
|
|
|
_elfutils_version: str
|
2020-04-18 23:10:29 +01:00
|
|
|
_with_libkdumpfile: bool
|
|
|
|
|
2023-11-13 15:38:10 +00:00
|
|
|
def _linux_helper_direct_mapping_offset(__prog: Program) -> int: ...
|
2020-08-20 19:58:17 +01:00
|
|
|
def _linux_helper_read_vm(
|
|
|
|
prog: Program, pgtable: Object, address: IntegerLike, size: IntegerLike
|
|
|
|
) -> bytes: ...
|
2023-06-03 07:40:38 +01:00
|
|
|
def _linux_helper_follow_phys(
|
|
|
|
prog: Program, pgtable: Object, address: IntegerLike
|
|
|
|
) -> int: ...
|
2022-12-14 01:10:22 +00:00
|
|
|
def _linux_helper_xa_load(xa: Object, index: IntegerLike) -> Object: ...
|
2021-12-21 22:39:50 +00:00
|
|
|
def _linux_helper_per_cpu_ptr(ptr: Object, cpu: IntegerLike) -> Object:
|
|
|
|
"""
|
|
|
|
Return the per-CPU pointer for a given CPU.
|
|
|
|
|
|
|
|
>>> prog["init_net"].loopback_dev.pcpu_refcnt
|
|
|
|
(int *)0x2c980
|
|
|
|
>>> per_cpu_ptr(prog["init_net"].loopback_dev.pcpu_refcnt, 7)
|
|
|
|
*(int *)0xffff925e3ddec980 = 4
|
|
|
|
|
|
|
|
:param ptr: Per-CPU pointer, i.e., ``type __percpu *``. For global
|
|
|
|
variables, it's usually easier to use :func:`per_cpu()`.
|
|
|
|
:param cpu: CPU number.
|
|
|
|
:return: ``type *`` object.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2023-11-16 21:27:21 +00:00
|
|
|
def _linux_helper_cpu_curr(__prog: Program, __cpu: IntegerLike) -> Object: ...
|
|
|
|
def _linux_helper_idle_task(__prog: Program, __cpu: IntegerLike) -> Object: ...
|
2022-10-04 00:08:53 +01:00
|
|
|
def _linux_helper_task_cpu(task: Object) -> int:
|
|
|
|
"""
|
|
|
|
Return the CPU number that the given task last ran on.
|
|
|
|
|
|
|
|
:param task: ``struct task_struct *``
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2023-01-16 14:03:58 +00:00
|
|
|
def _linux_helper_idr_find(idr: Object, id: IntegerLike) -> Object: ...
|
2023-11-16 21:27:21 +00:00
|
|
|
def _linux_helper_find_pid(__ns: Object, __pid: IntegerLike) -> Object: ...
|
2020-08-20 19:58:17 +01:00
|
|
|
def _linux_helper_pid_task(pid: Object, pid_type: IntegerLike) -> Object:
|
2020-08-15 18:27:02 +01:00
|
|
|
"""
|
|
|
|
Return the ``struct task_struct *`` containing the given ``struct pid *``
|
|
|
|
of the given type.
|
2020-08-20 19:58:17 +01:00
|
|
|
|
|
|
|
:param pid: ``struct pid *``
|
|
|
|
:param pid_type: ``enum pid_type``
|
|
|
|
:return: ``struct task_struct *``
|
2020-08-15 18:27:02 +01:00
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2023-11-16 21:27:21 +00:00
|
|
|
def _linux_helper_find_task(__ns: Object, __pid: IntegerLike) -> Object: ...
|
|
|
|
def _linux_helper_kaslr_offset(__prog: Program) -> int: ...
|
|
|
|
def _linux_helper_pgtable_l5_enabled(__prog: Program) -> bool: ...
|