2021-11-21 23:59:44 +00:00
|
|
|
# Copyright (c) Meta Platforms, Inc. and affiliates.
|
2021-04-03 09:10:35 +01:00
|
|
|
# SPDX-License-Identifier: GPL-3.0-or-later
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
"""
|
|
|
|
libdrgn bindings
|
|
|
|
|
|
|
|
Don't use this module directly. Instead, use the drgn package.
|
|
|
|
"""
|
|
|
|
|
|
|
|
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,
|
|
|
|
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,
|
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):
|
|
|
|
from typing_extensions import Protocol
|
|
|
|
else:
|
|
|
|
from typing import Protocol
|
|
|
|
|
|
|
|
# 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: ...
|
|
|
|
|
2020-08-13 23:27:20 +01:00
|
|
|
Path = Union[str, bytes, os.PathLike[str], os.PathLike[bytes]]
|
|
|
|
"""
|
|
|
|
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.
|
|
|
|
"""
|
|
|
|
|
2020-08-17 04:40:47 +01:00
|
|
|
def __init__(self, platform: Optional[Platform] = None) -> None:
|
|
|
|
"""
|
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.
|
|
|
|
"""
|
|
|
|
...
|
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.
|
|
|
|
|
|
|
|
For the Linux kernel, this is :attr:`Language.C`. For userspace programs,
|
|
|
|
this is determined from the language of ``main`` in the program, falling
|
|
|
|
back to :attr:`Language.C`. This heuristic may change in the future.
|
|
|
|
"""
|
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.
|
|
|
|
|
|
|
|
: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.
|
|
|
|
|
|
|
|
``thread`` may be a thread ID (as defined by `gettid(2)
|
|
|
|
<http://man7.org/linux/man-pages/man2/gettid.2.html>`_), 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`
|
|
|
|
|
|
|
|
``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.
|
|
|
|
"""
|
|
|
|
...
|
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.
|
|
|
|
|
|
|
|
:param tid: Thread ID (as defined by `gettid(2)
|
|
|
|
<http://man7.org/linux/man-pages/man2/gettid.2.html>`_).
|
|
|
|
:raises LookupError: if no thread has the given thread ID
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
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.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def add_type_finder(
|
|
|
|
self, fn: Callable[[TypeKind, str, Optional[str]], Type]
|
|
|
|
) -> None:
|
|
|
|
"""
|
|
|
|
Register a callback for finding types in the program.
|
|
|
|
|
|
|
|
Callbacks are called in reverse order of the order they were added
|
|
|
|
until the type is found. So, more recently added callbacks take
|
|
|
|
precedence.
|
|
|
|
|
|
|
|
:param fn: Callable taking a :class:`TypeKind`, name, and filename:
|
|
|
|
``(kind, name, filename)``. The filename should be matched with
|
|
|
|
:func:`filename_matches()`. This should return a :class:`Type`.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
def add_object_finder(
|
|
|
|
self, fn: Callable[[Program, str, FindObjectFlags, Optional[str]], Object]
|
|
|
|
) -> None:
|
|
|
|
"""
|
|
|
|
Register a callback for finding objects in the program.
|
|
|
|
|
|
|
|
Callbacks are called in reverse order of the order they were added
|
|
|
|
until the object is found. So, more recently added callbacks take
|
|
|
|
precedence.
|
|
|
|
|
|
|
|
:param fn: Callable taking a 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`.
|
|
|
|
"""
|
|
|
|
...
|
2020-08-13 23:27:20 +01:00
|
|
|
def set_core_dump(self, path: Path) -> 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()`.
|
|
|
|
|
|
|
|
:param path: Core dump file path.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
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).
|
|
|
|
"""
|
|
|
|
|
|
|
|
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
|
|
|
|
2021-11-19 00:46:59 +00:00
|
|
|
class Thread:
|
|
|
|
"""A thread in a program."""
|
|
|
|
|
|
|
|
tid: int
|
|
|
|
"""
|
|
|
|
Thread ID (as defined by `gettid(2)
|
|
|
|
<http://man7.org/linux/man-pages/man2/gettid.2.html>`_).
|
|
|
|
"""
|
|
|
|
object: Object
|
|
|
|
"""
|
|
|
|
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.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2020-08-13 23:27:20 +01:00
|
|
|
def program_from_core_dump(path: Path) -> 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.
|
|
|
|
|
|
|
|
:param path: Core dump file path.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
|
|
|
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.
|
|
|
|
"""
|
|
|
|
...
|
2020-02-25 19:43:01 +00:00
|
|
|
arch: Architecture
|
|
|
|
"""Instruction set architecture of this platform."""
|
|
|
|
|
|
|
|
flags: PlatformFlags
|
|
|
|
"""Flags which apply to this platform."""
|
|
|
|
|
|
|
|
registers: Sequence[Register]
|
|
|
|
"""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 = ...
|
|
|
|
"""The x86-64 architecture, a.k.a. AMD64."""
|
|
|
|
|
2020-11-27 12:06:56 +00:00
|
|
|
PPC64 = ...
|
|
|
|
"""The 64-bit PowerPC architecture."""
|
|
|
|
|
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."""
|
|
|
|
|
2021-01-28 23:49:21 +00:00
|
|
|
names: Sequence[str]
|
|
|
|
"""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.
|
|
|
|
"""
|
|
|
|
|
|
|
|
name: str
|
|
|
|
"""Name of the programming language."""
|
|
|
|
|
|
|
|
C: Language
|
|
|
|
"""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]``)
|
|
|
|
* Member access: :meth:`. <__getattribute__>` (Python does not have a
|
|
|
|
``->`` operator, so ``.`` is also used to access members of pointers to
|
|
|
|
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
|
|
|
...
|
2020-02-25 19:43:01 +00:00
|
|
|
prog_: Program
|
|
|
|
"""Program that this object is from."""
|
|
|
|
|
|
|
|
type_: Type
|
|
|
|
"""Type of this object."""
|
|
|
|
|
2020-12-29 23:06:40 +00:00
|
|
|
absent_: bool
|
|
|
|
"""
|
|
|
|
Whether this object is absent.
|
|
|
|
|
|
|
|
This is ``False`` for all values and references (even if the reference has
|
|
|
|
an invalid address).
|
|
|
|
"""
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
address_: 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
|
|
|
|
|
|
|
bit_offset_: Optional[int]
|
|
|
|
"""
|
|
|
|
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
|
|
|
"""
|
|
|
|
|
|
|
|
bit_field_size_: Optional[int]
|
|
|
|
"""
|
|
|
|
Size in bits of this object if it is a bit field, ``None`` if it is not.
|
|
|
|
"""
|
2020-04-20 20:37:55 +01:00
|
|
|
def __getattribute__(self, name: str) -> Object:
|
2020-02-25 19:43:01 +00:00
|
|
|
"""
|
|
|
|
Implement ``self.name``.
|
|
|
|
|
|
|
|
If *name* is an attribute of the :class:`Object` class, then this
|
|
|
|
returns that attribute. Otherwise, it is equivalent to
|
|
|
|
: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.
|
|
|
|
|
|
|
|
>>> print(prog['init_task'].comm[0])
|
|
|
|
(char)115
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
This is valid for structures, unions, and pointers to either.
|
|
|
|
|
|
|
|
Normally the dot operator (``.``) can be used to accomplish the same
|
|
|
|
thing, but this method can be used if there is a name conflict with an
|
|
|
|
Object member or method.
|
|
|
|
|
|
|
|
: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: ...
|
|
|
|
|
|
|
|
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()`.
|
|
|
|
|
|
|
|
:param type: The type to cast to.
|
|
|
|
:param obj: The object to cast.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
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
|
|
|
"""
|
|
|
|
Get a copy of the given object reinterpreted as another type and/or byte
|
|
|
|
order.
|
|
|
|
|
|
|
|
This reinterprets the raw memory of the object, so an object can be
|
|
|
|
reinterpreted as any other type. However, value objects with a scalar type
|
|
|
|
cannot be reinterpreted, as their memory layout in the program is not
|
|
|
|
known. Reinterpreting a reference results in a reference, and
|
|
|
|
reinterpreting a value results in a value. See also :func:`drgn.cast()`.
|
|
|
|
|
|
|
|
:param type: The type to reinterpret as.
|
|
|
|
:param obj: The object to reinterpret.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
|
|
|
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.
|
|
|
|
"""
|
|
|
|
|
|
|
|
name: str
|
|
|
|
"""Name of this symbol."""
|
|
|
|
|
|
|
|
address: int
|
|
|
|
"""Start address of this symbol."""
|
|
|
|
|
|
|
|
size: int
|
|
|
|
"""Size of this symbol in bytes."""
|
|
|
|
|
2021-08-19 22:12:48 +01:00
|
|
|
binding: SymbolBinding
|
|
|
|
"""Linkage behavior and visibility of this symbol."""
|
|
|
|
|
|
|
|
kind: SymbolKind
|
|
|
|
"""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
|
|
|
"""
|
|
|
|
|
2020-08-13 22:47:59 +01:00
|
|
|
def __getitem__(self, idx: IntegerLike) -> StackFrame: ...
|
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
|
|
|
"""
|
|
|
|
|
|
|
|
name: Optional[str]
|
|
|
|
"""
|
|
|
|
Name of the function at this frame, or ``None`` if it could not be
|
|
|
|
determined.
|
|
|
|
"""
|
|
|
|
|
|
|
|
is_inline: bool
|
|
|
|
"""
|
|
|
|
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
|
|
|
"""
|
|
|
|
|
2021-03-10 09:51:33 +00:00
|
|
|
interrupted: 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
|
|
|
|
2021-03-10 09:51:33 +00:00
|
|
|
pc: int
|
|
|
|
"""Program counter 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.
|
|
|
|
"""
|
|
|
|
...
|
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.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
|
|
|
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`.
|
|
|
|
"""
|
|
|
|
|
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
|
|
|
prog: Program
|
|
|
|
"""Program that this type is from."""
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
kind: TypeKind
|
|
|
|
"""Kind of this type."""
|
|
|
|
|
|
|
|
primitive: Optional[PrimitiveType]
|
|
|
|
"""
|
|
|
|
If this is a primitive type (e.g., ``int`` or ``double``), the kind of
|
|
|
|
primitive type. Otherwise, ``None``.
|
|
|
|
"""
|
|
|
|
|
|
|
|
qualifiers: Qualifiers
|
|
|
|
"""Bitmask of this type's qualifier."""
|
|
|
|
|
2020-02-26 21:22:51 +00:00
|
|
|
language: Language
|
|
|
|
"""Programming language of this type."""
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
name: str
|
|
|
|
"""
|
|
|
|
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
|
|
|
"""
|
|
|
|
|
|
|
|
tag: Optional[str]
|
|
|
|
"""
|
|
|
|
Tag of this type, or ``None`` if this is an anonymous type. This is present
|
|
|
|
for structure, union, class, and enumerated types.
|
|
|
|
"""
|
|
|
|
|
|
|
|
size: Optional[int]
|
|
|
|
"""
|
|
|
|
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
|
|
|
"""
|
|
|
|
|
|
|
|
length: Optional[int]
|
|
|
|
"""
|
|
|
|
Number of elements in this type, or ``None`` if this is an incomplete type.
|
|
|
|
This is only present for array types.
|
|
|
|
"""
|
|
|
|
|
|
|
|
is_signed: bool
|
|
|
|
"""Whether this type is signed. This is only present for integer types."""
|
|
|
|
|
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: str
|
|
|
|
"""
|
|
|
|
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.
|
|
|
|
"""
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
type: Type
|
|
|
|
"""
|
|
|
|
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.
|
|
|
|
"""
|
|
|
|
|
|
|
|
members: Optional[Sequence[TypeMember]]
|
|
|
|
"""
|
|
|
|
List of members of this type, or ``None`` if this is an incomplete type.
|
|
|
|
This is present for structure, union, and class types.
|
|
|
|
"""
|
|
|
|
|
|
|
|
enumerators: Optional[Sequence[TypeEnumerator]]
|
|
|
|
"""
|
|
|
|
List of enumeration constants of this type, or ``None`` if this is an
|
|
|
|
incomplete type. This is only present for enumerated types.
|
|
|
|
"""
|
|
|
|
|
|
|
|
parameters: Sequence[TypeParameter]
|
|
|
|
"""
|
|
|
|
List of parameters of this type. This is only present for function types.
|
|
|
|
"""
|
|
|
|
|
|
|
|
is_variadic: bool
|
|
|
|
"""
|
|
|
|
Whether this type takes a variable number of arguments. This is only
|
|
|
|
present for function types.
|
|
|
|
"""
|
2021-01-09 01:28:27 +00:00
|
|
|
|
|
|
|
template_parameters: Sequence[TypeTemplateParameter]
|
|
|
|
"""
|
|
|
|
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
|
|
|
|
"""
|
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`
|
|
|
|
"""
|
|
|
|
...
|
2020-12-18 19:01:29 +00:00
|
|
|
object: Object
|
|
|
|
"""
|
|
|
|
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.)
|
|
|
|
"""
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
type: 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
|
|
|
|
|
|
|
name: 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
|
|
|
|
|
|
|
bit_offset: 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
|
|
|
|
|
|
|
offset: int
|
|
|
|
"""
|
|
|
|
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`.
|
|
|
|
"""
|
|
|
|
|
2020-12-25 09:53:23 +00:00
|
|
|
bit_field_size: Optional[int]
|
|
|
|
"""
|
|
|
|
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`
|
|
|
|
"""
|
|
|
|
...
|
2020-02-25 19:43:01 +00:00
|
|
|
name: str
|
2020-08-17 04:40:47 +01:00
|
|
|
"Enumerator name."
|
2020-02-25 19:43:01 +00:00
|
|
|
|
|
|
|
value: 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`
|
|
|
|
"""
|
|
|
|
...
|
2020-12-18 19:01:29 +00:00
|
|
|
default_argument: Object
|
|
|
|
"""
|
|
|
|
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
|
|
|
"""
|
|
|
|
|
2020-02-25 19:43:01 +00:00
|
|
|
type: 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
|
|
|
|
|
|
|
name: 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`
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
argument: Union[Type, Object]
|
|
|
|
"""
|
|
|
|
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`.
|
|
|
|
"""
|
|
|
|
|
|
|
|
name: Optional[str]
|
|
|
|
"""Template parameter name, or ``None`` if the parameter is unnamed."""
|
|
|
|
|
|
|
|
is_default: bool
|
|
|
|
"""
|
|
|
|
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."""
|
|
|
|
|
|
|
|
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
|
|
|
|
|
2020-08-20 19:58:17 +01:00
|
|
|
def _linux_helper_read_vm(
|
|
|
|
prog: Program, pgtable: Object, address: IntegerLike, size: IntegerLike
|
|
|
|
) -> bytes: ...
|
|
|
|
def _linux_helper_radix_tree_lookup(root: Object, index: IntegerLike) -> Object:
|
2020-08-15 18:27:02 +01:00
|
|
|
"""
|
2020-08-20 19:58:17 +01:00
|
|
|
Look up the entry at a given index in a radix tree.
|
2020-08-15 18:27:02 +01:00
|
|
|
|
2020-08-20 19:58:17 +01:00
|
|
|
:param root: ``struct radix_tree_root *``
|
|
|
|
:param index: Entry index.
|
|
|
|
:return: ``void *`` found entry, or ``NULL`` if not found.
|
2020-08-15 18:27:02 +01:00
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
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.
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2021-12-22 00:03:25 +00:00
|
|
|
def _linux_helper_idle_task(prog: Program, cpu: IntegerLike) -> Object:
|
2021-12-21 22:40:57 +00:00
|
|
|
"""
|
|
|
|
Return the idle thread (PID 0, a.k.a swapper) for the given CPU.
|
|
|
|
|
2021-12-22 00:03:25 +00:00
|
|
|
>>> idle_task(prog, 1).comm
|
2021-12-21 22:40:57 +00:00
|
|
|
(char [16])"swapper/1"
|
|
|
|
|
|
|
|
:param cpu: CPU number.
|
|
|
|
:return: ``struct task_struct *``
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2020-08-20 19:58:17 +01:00
|
|
|
def _linux_helper_idr_find(idr: Object, id: IntegerLike) -> Object:
|
2020-08-15 18:27:02 +01:00
|
|
|
"""
|
2020-08-20 19:58:17 +01:00
|
|
|
Look up the entry with the given ID in an IDR.
|
2020-08-15 18:27:02 +01:00
|
|
|
|
2020-08-20 19:58:17 +01:00
|
|
|
:param idr: ``struct idr *``
|
|
|
|
:param id: Entry ID.
|
|
|
|
:return: ``void *`` found entry, or ``NULL`` if not found.
|
2020-08-15 18:27:02 +01:00
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2020-08-20 19:58:17 +01:00
|
|
|
def _linux_helper_find_pid(
|
|
|
|
prog_or_ns: Union[Program, Object], pid: IntegerLike
|
|
|
|
) -> Object:
|
2020-08-15 18:27:02 +01:00
|
|
|
"""
|
2020-08-20 19:58:17 +01:00
|
|
|
Return the ``struct pid *`` for the given PID number.
|
2020-08-15 18:27:02 +01:00
|
|
|
|
2020-08-20 19:58:17 +01:00
|
|
|
:param prog_or_ns: ``struct pid_namespace *`` object, or :class:`Program`
|
|
|
|
to use initial PID namespace.
|
|
|
|
:return: ``struct pid *``
|
2020-08-15 18:27:02 +01:00
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
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
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2020-08-20 19:58:17 +01:00
|
|
|
def _linux_helper_find_task(
|
|
|
|
prog_or_ns: Union[Program, Object], pid: IntegerLike
|
|
|
|
) -> Object:
|
2020-08-15 18:27:02 +01:00
|
|
|
"""
|
2020-08-20 19:58:17 +01:00
|
|
|
Return the task with the given PID.
|
2020-08-15 18:27:02 +01:00
|
|
|
|
2020-08-20 19:58:17 +01:00
|
|
|
:param prog_or_ns: ``struct pid_namespace *`` object, or :class:`Program`
|
|
|
|
to use initial PID namespace.
|
|
|
|
:return: ``struct task_struct *``
|
2020-08-15 18:27:02 +01:00
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2020-08-20 19:58:17 +01:00
|
|
|
def _linux_helper_kaslr_offset(prog: Program) -> int:
|
2020-08-15 18:27:02 +01:00
|
|
|
"""
|
|
|
|
Get the kernel address space layout randomization offset (zero if it is
|
|
|
|
disabled).
|
|
|
|
"""
|
|
|
|
...
|
|
|
|
|
2020-08-20 19:58:17 +01:00
|
|
|
def _linux_helper_pgtable_l5_enabled(prog: Program) -> bool:
|
|
|
|
"""Return whether 5-level paging is enabled."""
|
2020-08-15 18:27:02 +01:00
|
|
|
...
|