JakeHillion/drgn
1
0
Fork 0
mirror of https://github.com/JakeHillion/drgn.git synced 2024-12-22 17:23:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
5b18f6eb2a
drgn/libdrgn/arch_ppc64_defs.py

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

25 lines
977 B
Python
Raw Normal View History

libdrgn: rework architecture definition files Currently, register definitions are split across two files: arch_foo.defs lists the names of registers, and arch_foo.c defines the layout used to store registers in memory. The main rationale for this was that the layout could be processed entirely by the C preprocessor, but the register names needed an AWK script that we wanted to keep minimal. But since commit af6f5a887d25 ("libdrgn: replace gen_arch.awk with gen_arch_inc_strswitch.py"), arch_foo.defs is processed by a Python script. Let's define both the register names and the register layout in a new file, arch_foo_defs.py, which is processed by gen_arch_inc_strswitch.py This has a few benefits: * It puts all of the register definitions for an architecture in one place. * It is easier to maintain than preprocessor magic. (It also makes it trivial to support registers that don't exist in DWARF, which would've been harder to do with our preprocessor code.) * It gets rid of our DSL in favor of Python (which also lets us reduce repetition for the ppc64 definitions). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-11 16:32:24 +01:00
# Copyright (c) Meta Platforms, Inc. and affiliates.
Relicense drgn from GPLv3+ to LGPLv2.1+ drgn is currently licensed as GPLv3+. Part of the long term vision for drgn is that other projects can use it as a library providing programmatic interfaces for debugger functionality. A more permissive license is better suited to this goal. We decided on LGPLv2.1+ as a good balance between software freedom and permissiveness. All contributors not employed by Meta were contacted via email and consented to the license change. The only exception was the author of commit c4fbf7e5896c ("libdrgn: fix for compilation error"), who did not respond. That commit reverted a single line of code to one originally written by me in commit 640b1c011df8 ("libdrgn: embed DWARF index in DWARF info cache"). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-11-02 00:05:16 +00:00
# SPDX-License-Identifier: LGPL-2.1-or-later
libdrgn: rework architecture definition files Currently, register definitions are split across two files: arch_foo.defs lists the names of registers, and arch_foo.c defines the layout used to store registers in memory. The main rationale for this was that the layout could be processed entirely by the C preprocessor, but the register names needed an AWK script that we wanted to keep minimal. But since commit af6f5a887d25 ("libdrgn: replace gen_arch.awk with gen_arch_inc_strswitch.py"), arch_foo.defs is processed by a Python script. Let's define both the register names and the register layout in a new file, arch_foo_defs.py, which is processed by gen_arch_inc_strswitch.py This has a few benefits: * It puts all of the register definitions for an architecture in one place. * It is easier to maintain than preprocessor magic. (It also makes it trivial to support registers that don't exist in DWARF, which would've been harder to do with our preprocessor code.) * It gets rid of our DSL in favor of Python (which also lets us reduce repetition for the ppc64 definitions). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-11 16:32:24 +01:00
REGISTERS = [
*[DrgnRegister(f"r{i}") for i in range(32)],
libdrgn: ppc64: fix DWARF link register confusion The usage of the link register in DWARF is a little confusing. On entry to a function, the link register contains the address that should be returned to. However, for DWARF, the link register is usually used as the CFI return_address_register, which means that in an unwound frame, it will contain the same thing as the program counter. I initially thought that this was a mistake, believing that the link register should contain the _next_ return address. However, after a return (with the blr instruction), the link register will indeed contain the same address as the program counter. This is consistent with our documentation of register values for function call frames: "the register values are the values when control returns to this frame". So, rename our internal "ra" register to "lr", expose it to the API, and add a little more documentation to the ppc64 initial register code. Fixes: 221a21870459 ("libdrgn: add powerpc stack trace support") Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-22 02:39:29 +01:00
DrgnRegister("lr"),
libdrgn: rework architecture definition files Currently, register definitions are split across two files: arch_foo.defs lists the names of registers, and arch_foo.c defines the layout used to store registers in memory. The main rationale for this was that the layout could be processed entirely by the C preprocessor, but the register names needed an AWK script that we wanted to keep minimal. But since commit af6f5a887d25 ("libdrgn: replace gen_arch.awk with gen_arch_inc_strswitch.py"), arch_foo.defs is processed by a Python script. Let's define both the register names and the register layout in a new file, arch_foo_defs.py, which is processed by gen_arch_inc_strswitch.py This has a few benefits: * It puts all of the register definitions for an architecture in one place. * It is easier to maintain than preprocessor magic. (It also makes it trivial to support registers that don't exist in DWARF, which would've been harder to do with our preprocessor code.) * It gets rid of our DSL in favor of Python (which also lets us reduce repetition for the ppc64 definitions). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-11 16:32:24 +01:00
*[DrgnRegister(f"cr{i}") for i in range(8)],
]
# There are two conflicting definitions of DWARF register numbers after 63. The
# original definition appears to be "64-bit PowerPC ELF Application Binary
# Interface Supplement" [1]. The GNU toolchain instead uses its own that was
# later codified in "Power Architecture 64-Bit ELF V2 ABI Specification" [2].
# We use the latter.
#
# 1: https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html
# 2: https://openpowerfoundation.org/specifications/64bitelfabi/
REGISTER_LAYOUT = [
libdrgn: ppc64: fix DWARF link register confusion The usage of the link register in DWARF is a little confusing. On entry to a function, the link register contains the address that should be returned to. However, for DWARF, the link register is usually used as the CFI return_address_register, which means that in an unwound frame, it will contain the same thing as the program counter. I initially thought that this was a mistake, believing that the link register should contain the _next_ return address. However, after a return (with the blr instruction), the link register will indeed contain the same address as the program counter. This is consistent with our documentation of register values for function call frames: "the register values are the values when control returns to this frame". So, rename our internal "ra" register to "lr", expose it to the API, and add a little more documentation to the ppc64 initial register code. Fixes: 221a21870459 ("libdrgn: add powerpc stack trace support") Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-22 02:39:29 +01:00
DrgnRegisterLayout("lr", size=8, dwarf_number=65),
libdrgn: rework architecture definition files Currently, register definitions are split across two files: arch_foo.defs lists the names of registers, and arch_foo.c defines the layout used to store registers in memory. The main rationale for this was that the layout could be processed entirely by the C preprocessor, but the register names needed an AWK script that we wanted to keep minimal. But since commit af6f5a887d25 ("libdrgn: replace gen_arch.awk with gen_arch_inc_strswitch.py"), arch_foo.defs is processed by a Python script. Let's define both the register names and the register layout in a new file, arch_foo_defs.py, which is processed by gen_arch_inc_strswitch.py This has a few benefits: * It puts all of the register definitions for an architecture in one place. * It is easier to maintain than preprocessor magic. (It also makes it trivial to support registers that don't exist in DWARF, which would've been harder to do with our preprocessor code.) * It gets rid of our DSL in favor of Python (which also lets us reduce repetition for the ppc64 definitions). Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-06-11 16:32:24 +01:00
*[DrgnRegisterLayout(f"r{i}", size=8, dwarf_number=i) for i in range(32)],
*[DrgnRegisterLayout(f"cr{i}", size=8, dwarf_number=68 + i) for i in range(8)],
]
Add StackFrame.sp We have some generic helpers that we'd like to add (for example, #210) that need to know the stack pointer of a frame. These shouldn't need to hard-code register names for different architectures. Add a generic shortcut, StackFrame.sp. Signed-off-by: Omar Sandoval <osandov@osandov.com>
2022-11-23 00:51:44 +00:00
STACK_POINTER_REGISTER = "r1"
Reference in New Issue Copy Permalink