Commit Graph

15 Commits

Author SHA1 Message Date
Michał Górny 011791dda4 [lldb] [Process/FreeBSDRemote] Fix clang-formatting on ppc commit 2021-02-14 22:34:25 +01:00
Michał Górny bd03f6df51 [lldb] [Process/FreeBSDRemote] Introduce powerpc support
Introduce a minimal support for the 32-bit powerpc platform.  This
includes support for GPR and FPR registers.  I also needed to add
software breakpoint opcode for PPC32/PPC64 (big endian), and to fix
offsets in RegisterInfos_powerpc.h (used only by FreeBSD register
context to be globally unique rather than relative to each struct).

Differential Revision: https://reviews.llvm.org/D95947
2021-02-09 21:10:45 +01:00
Michał Górny 8244fc505d [lldb] [Process/FreeBSDRemote] Introduce mips64 support
Introduce mips64 support to match the legacy FreeBSD plugin. Similarly
to the legacy plugin, the code does not support FPU registers at the
moment.  The support for them will be submitted separately as it
requires changes to the register context shared by both plugins.

This also includes software single-stepping support that is moved from
the Linux plugin into a common Utility class.  The FreeBSD code also
starts explicitly ignoring EINVAL from PT_CLEARSTEP since this is easier
to implement than checking whether hardware single-stepping were used.

Differential Revision: https://reviews.llvm.org/D95802
2021-02-08 18:27:26 +01:00
Michał Górny 9d029362d1 [lldb] [Process/FreeBSDRemote] Introduce arm (32-bit) support
Introduce a NativeRegisterContextFreeBSD for 32-bit ARM platform.
This includes support for GPR + VFP registers as exposed by FreeBSD's
ptrace(2) API.  Hardware breakpoints or watchpoints are not supported
due to missing kernel support.  The code is roughly based on the arm64
context.

It also includes an override for GetSoftwareBreakpointTrapOpcode() based
on the matching code in the PlatformFreeBSD plugin.

Differential Revision: https://reviews.llvm.org/D95696
2021-01-31 19:52:08 +01:00
Michał Górny f43c0707f6 [lldb] [Process/FreeBSDRemote] Introduce arm64 support
Introduce arm64 support in the FreeBSDRemote plugin.  The code
is roughly based on Linux and reuses the same POSIX RegisterInfos
(but the buffers need to be a few bytes larger due to stricter struct
member alignment in FreeBSD structures -- luckily, they do not affect
the actual member offsets).  It supports reading and writing
general-purpose and FPU registers.  SVE and hardware watchpoint support
is missing due to the limitations of FreeBSD ptrace(2) API.

Differential Revision: https://reviews.llvm.org/D95297
2021-01-31 19:52:08 +01:00
Michał Górny 37f99a5606 [lldb] [unittests] Filter FreeBSD through CMake rather than #ifdef 2020-12-17 13:55:42 +01:00
Michał Górny 56440359d0 [lldb] [unittests] Add tests for NetBSD register offsets/sizes
Differential Revision: https://reviews.llvm.org/D93299
2020-12-17 13:55:42 +01:00
Michał Górny 8aea95f3cb [lldb] Reland "Use translated full ftag values"
Translate between abridged and full ftag values in order to expose
the latter in the gdb-remote protocol while the former are used by
FXSAVE/XSAVE...  This matches the gdb behavior.

The Shell/Register tests now rely on the new behavior, and therefore
are run on non-Darwin systems only.  The Python (API) test relies
on the legacy behavior, and is run on Darwin only.

Differential Revision: https://reviews.llvm.org/D91504
2020-11-21 17:11:38 +01:00
David Spickett 32541685b2 [lldb][AArch64/Linux] Show memory tagged memory regions
This extends the "memory region" command to
show tagged regions on AArch64 Linux when the MTE
extension is enabled.

(lldb) memory region the_page
[0x0000fffff7ff8000-0x0000fffff7ff9000) rw-
memory tagging: enabled

This is done by adding an optional "flags" field to
the qMemoryRegion packet. The only supported flag is
"mt" but this can be extended.

This "mt" flag is read from /proc/{pid}/smaps on Linux,
other platforms will leave out the "flags" field.

Where this "mt" flag is received "memory region" will
show that it is enabled. If it is not or the target
doesn't support memory tagging, the line is not shown.
(since majority of the time tagging will not be enabled)

Testing is added for the existing /proc/{pid}/maps
parsing and the new smaps parsing.
Minidump parsing has been updated where needed,
though it only uses maps not smaps.

Target specific tests can be run with QEMU and I have
added MTE flags to the existing helper scripts.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D87442
2020-11-20 11:21:59 +00:00
Mikhail Goncharov 193a9b374e Revert "[lldb] Use translated full ftag values"
This reverts commit c43abf0436.

Test commands/register/register/register_command/TestRegisters.py fails.
Buildbot http://lab.llvm.org:8011/#/changes/4149
2020-11-19 15:24:59 +01:00
Michał Górny c43abf0436 [lldb] Use translated full ftag values
Translate between abridged and full ftag values in order to expose
the latter in the gdb-remote protocol while the former are used by
FXSAVE/XSAVE...  This matches the gdb behavior.

Differential Revision: https://reviews.llvm.org/D91504
2020-11-19 13:23:12 +01:00
Michał Górny d8ff269f67 [lldb] Add explicit 64-bit fip/fdp registers on x86_64
The FXSAVE/XSAVE data can have two different layouts on x86_64.  When
called as FXSAVE/XSAVE..., the Instruction Pointer and Address Pointer
registers are reported using a 16-bit segment identifier and a 32-bit
offset.  When called as FXSAVE64/XSAVE64..., they are reported using
a complete 64-bit offsets instead.

LLDB has historically followed GDB and unconditionally used to assume
the 32-bit layout, with the slight modification of possibly
using a 32-bit segment register (i.e. extending the register into
the reserved 16 upper bits).  When the underlying operating system used
FXSAVE64/XSAVE64..., the pointer was split into two halves,
with the upper half repored as the segment registers.  While
reconstructing the full address was possible on the user end (and e.g.
the FPU register tests did that), it certainly was not the most
convenient option.

Introduce a two additional 'fip' and 'fdp' registers that overlap
with 'fiseg'/'fioff' and 'foseg'/'foff' respectively, and report
the complete 64-bit address.

Differential Revision: https://reviews.llvm.org/D91497
2020-11-19 13:23:12 +01:00
Michał Górny 6adb55877c [lldb] [Process/FreeBSDRemote] Access debug registers via offsets
Use offset-based method to access x86 debug registers.  This also
involves adding a test for the correctness of these offsets, and making
GetDR() method of NativeRegisterContextWatchpoint_x86 public to avoid
duplicate code.

Differential Revision: https://reviews.llvm.org/D91268
2020-11-16 13:03:01 +01:00
Michał Górny e520487bf4 [lldb] [Process/FreeBSDRemote] Access FPR via RegisterInfo offsets
Use offset-based method to access base x87 FPU registers, using offsets
relative to the position of 'struct FPR', as determined by the location
of first register in it (fctrl).  Change m_fpr to use a fixed-size array
matching FXSAVE size (512 bytes).  Add unit tests for verifying
RegisterInfo offsets and sizes against the FXSAVE layout.

Differential Revision: https://reviews.llvm.org/D91248
2020-11-16 13:03:01 +01:00
Michał Górny 58abbf821c [lldb] [Process/FreeBSDRemote] Access GPR via reginfo offsets
Read and write registers from m_gpr using offsets from RegisterInfo
rather than explicit switch-case.  This eliminates a lot of redundant
code, and avoids mistakes such as type mismatches seen recently (wrt
segment registers).  The same logic will be extended to other register
sets in the future.

Make m_gpr an uint8_t std::array to ease accesses.  Ideally, we could
avoid including <machine/reg.h> entirely in the future and instead
get the correct GPR size from Utility/RegisterContextFreeBSD_* somehow.

While at it, modify register set logic to use an explicit enum with
llvm::Optional<>, making the code cleaner and at the same time enabling
compiler warnings for unhandled sets.

Since now we're fully relying on 'struct GPR' defined
in Utility/RegisterContextFreeBSD_* being entirely in sync with
the system structure, add unit tests to verify the field offsets
and sizes.

Differential Revision: https://reviews.llvm.org/D91216
2020-11-16 12:19:37 +01:00