602 lines
No EOL
23 KiB
ReStructuredText
602 lines
No EOL
23 KiB
ReStructuredText
Debugging
|
|
=========
|
|
|
|
This page details various ways to debug LLDB itself and other LLDB tools. If
|
|
you want to know how to use LLDB in general, please refer to
|
|
:doc:`/use/tutorial`.
|
|
|
|
As LLDB is generally split into 2 tools, ``lldb`` and ``lldb-server``
|
|
(``debugserver`` on Mac OS), the techniques shown here will not always apply to
|
|
both. With some knowledge of them all, you can mix and match as needed.
|
|
|
|
In this document we refer to the initial ``lldb`` as the "debugger" and the
|
|
program being debugged as the "inferior".
|
|
|
|
Building For Debugging
|
|
----------------------
|
|
|
|
To build LLDB with debugging information add the following to your CMake
|
|
configuration:
|
|
|
|
::
|
|
|
|
-DCMAKE_BUILD_TYPE=Debug \
|
|
-DLLDB_EXPORT_ALL_SYMBOLS=ON
|
|
|
|
Note that the ``lldb`` you will use to do the debugging does not itself need to
|
|
have debug information.
|
|
|
|
Then build as you normally would according to :doc:`/resources/build`.
|
|
|
|
If you are going to debug in a way that doesn't need debug info (printf, strace,
|
|
etc.) we recommend adding ``LLVM_ENABLE_ASSERTIONS=ON`` to Release build
|
|
configurations. This will make LLDB fail earlier instead of continuing with
|
|
invalid state (assertions are enabled by default for Debug builds).
|
|
|
|
Debugging ``lldb``
|
|
------------------
|
|
|
|
The simplest scenario is where we want to debug a local execution of ``lldb``
|
|
like this one:
|
|
|
|
::
|
|
|
|
./bin/lldb test_program
|
|
|
|
LLDB is like any other program, so you can use the same approach.
|
|
|
|
::
|
|
|
|
./bin/lldb -- ./bin/lldb /tmp/test.o
|
|
|
|
That's it. At least, that's the minimum. There's nothing special about LLDB
|
|
being a debugger that means you can't attach another debugger to it like any
|
|
other program.
|
|
|
|
What can be an issue is that both debuggers have command line interfaces which
|
|
makes it very confusing which one is which:
|
|
|
|
::
|
|
|
|
(the debugger)
|
|
(lldb) run
|
|
Process 1741640 launched: '<...>/bin/lldb' (aarch64)
|
|
Process 1741640 stopped and restarted: thread 1 received signal: SIGCHLD
|
|
|
|
(the inferior)
|
|
(lldb) target create "/tmp/test.o"
|
|
Current executable set to '/tmp/test.o' (aarch64).
|
|
|
|
Another issue is that when you resume the inferior, it will not print the
|
|
``(lldb)`` prompt because as far as it knows it hasn't changed state. A quick
|
|
way around that is to type something that is clearly not a command and hit
|
|
enter.
|
|
|
|
::
|
|
|
|
(lldb) Process 1742266 stopped and restarted: thread 1 received signal: SIGCHLD
|
|
Process 1742266 stopped
|
|
* thread #1, name = 'lldb', stop reason = signal SIGSTOP
|
|
frame #0: 0x0000ffffed5bfbf0 libc.so.6`__GI___libc_read at read.c:26:10
|
|
(lldb) c
|
|
Process 1742266 resuming
|
|
notacommand
|
|
error: 'notacommand' is not a valid command.
|
|
(lldb)
|
|
|
|
You could just remember whether you are in the debugger or the inferior but
|
|
it's more for you to remember, and for interrupt based events you simply may not
|
|
be able to know.
|
|
|
|
Here are some better approaches. First, you could use another debugger like GDB
|
|
to debug LLDB. Perhaps an IDE like Xcode or Visual Studio Code. Something which
|
|
runs LLDB under the hood so you don't have to type in commands to the debugger
|
|
yourself.
|
|
|
|
Or you could change the prompt text for the debugger and/or inferior.
|
|
|
|
::
|
|
|
|
$ ./bin/lldb -o "settings set prompt \"(lldb debugger) \"" -- \
|
|
./bin/lldb -o "settings set prompt \"(lldb inferior) \"" /tmp/test.o
|
|
<...>
|
|
(lldb) settings set prompt "(lldb debugger) "
|
|
(lldb debugger) run
|
|
<...>
|
|
(lldb) settings set prompt "(lldb inferior) "
|
|
(lldb inferior)
|
|
|
|
If you want spacial separation you can run the inferior in one terminal then
|
|
attach to it in another. Remember that while paused in the debugger, the inferior
|
|
will not respond to input so you will have to ``continue`` in the debugger
|
|
first.
|
|
|
|
::
|
|
|
|
(in terminal A)
|
|
$ ./bin/lldb /tmp/test.o
|
|
|
|
(in terminal B)
|
|
$ ./bin/lldb ./bin/lldb --attach-pid $(pidof lldb)
|
|
|
|
Placing Breakpoints
|
|
*******************
|
|
|
|
Generally you will want to hit some breakpoint in the inferior ``lldb``. To place
|
|
that breakpoint you must first stop the inferior.
|
|
|
|
If you're debugging from another window this is done with ``process interrupt``.
|
|
The inferior will stop, you place the breakpoint and then ``continue``. Go back
|
|
to the inferior and input the command that should trigger the breakpoint.
|
|
|
|
If you are running debugger and inferior in the same window, input ``ctrl+c``
|
|
instead of ``process interrupt`` and then folllow the rest of the steps.
|
|
|
|
If you are doing this with ``lldb-server`` and find your breakpoint is never
|
|
hit, check that you are breaking in code that is actually run by
|
|
``lldb-server``. There are cases where code only used by ``lldb`` ends up
|
|
linked into ``lldb-server``, so the debugger can break there but the breakpoint
|
|
will never be hit.
|
|
|
|
Debugging ``lldb-server``
|
|
-------------------------
|
|
|
|
Note: If you are on MacOS you are likely using ``debugserver`` instead of
|
|
``lldb-server``. The spirit of these instructions applies but the specifics will
|
|
be different.
|
|
|
|
We suggest you read :doc:`/use/remote` before attempting to debug ``lldb-server``
|
|
as working out exactly what you want to debug requires that you understand its
|
|
various modes and behaviour. While you may not be literally debugging on a
|
|
remote target, think of your host machine as the "remote" in this scenario.
|
|
|
|
The ``lldb-server`` options for your situation will depend on what part of it
|
|
or mode you are interested in. To work out what those are, recreate the scenario
|
|
first without any extra debugging layers. Let's say we want to debug
|
|
``lldb-server`` during the following command:
|
|
|
|
::
|
|
|
|
$ ./bin/lldb /tmp/test.o
|
|
|
|
We can treat ``lldb-server`` as we treated ``lldb`` before, running it under
|
|
``lldb``. The equivalent to having ``lldb`` launch the ``lldb-server`` for us is
|
|
to start ``lldb-server`` in the ``gdbserver`` mode.
|
|
|
|
The following commands recreate that, while debugging ``lldb-server``:
|
|
|
|
::
|
|
|
|
$ ./bin/lldb -- ./bin/lldb-server gdbserver :1234 /tmp/test.o
|
|
(lldb) target create "./bin/lldb-server"
|
|
Current executable set to '<...>/bin/lldb-server' (aarch64).
|
|
<...>
|
|
Process 1742485 launched: '<...>/bin/lldb-server' (aarch64)
|
|
Launched '/tmp/test.o' as process 1742586...
|
|
|
|
(in another terminal)
|
|
$ ./bin/lldb /tmp/test.o -o "gdb-remote 1234"
|
|
|
|
Note that the first ``lldb`` is the one debugging ``lldb-server``. The second
|
|
``lldb`` is debugging ``/tmp/test.o`` and is only used to trigger the
|
|
interesting code path in ``lldb-server``.
|
|
|
|
This is another case where you may want to layout your terminals in a
|
|
predictable way, or change the prompt of one or both copies of ``lldb``.
|
|
|
|
If you are debugging a scenario where the ``lldb-server`` starts in ``platform``
|
|
mode, but you want to debug the ``gdbserver`` mode you'll have to work out what
|
|
subprocess it's starting for the ``gdbserver`` part. One way is to look at the
|
|
list of runninng processes and take the command line from there.
|
|
|
|
In theory it should be possible to use LLDB's
|
|
``target.process.follow-fork-mode`` or GDB's ``follow-fork-mode`` to
|
|
automatically debug the ``gdbserver`` process as it's created. However this
|
|
author has not been able to get either to work in this scenario so we suggest
|
|
making a more specific command wherever possible instead.
|
|
|
|
Another option is to let ``lldb-server`` start up, then attach to the process
|
|
that's interesting to you. It's less automated and won't work if the bug occurs
|
|
during startup. However it is a good way to know you've found the right one,
|
|
then you can take its command line and run that directly.
|
|
|
|
Output From ``lldb-server``
|
|
***************************
|
|
|
|
As ``lldb-server`` often launches subprocesses, output messages may be hidden
|
|
if they are emitted from the child processes.
|
|
|
|
You can tell it to enable logging using the ``--log-channels`` option. For
|
|
example ``--log-channels "posix ptrace"``. However that is not passed on to the
|
|
child processes.
|
|
|
|
The same goes for ``printf``. If it's called in a child process you won't see
|
|
the output.
|
|
|
|
In these cases consider interactive debugging ``lldb-server`` or
|
|
working out a more specific command such that it does not have to spawn a
|
|
subprocess. For example if you start with ``platform`` mode, work out what
|
|
``gdbserver`` mode process it spawns and run that command instead.
|
|
|
|
Another option if you have ``strace`` available is to trace the whole process
|
|
tree and inspect the logs after the session has ended. ::
|
|
|
|
$ strace -ff -o log -p $(pidof lldb-server)
|
|
|
|
This will log all syscalls made by ``lldb-server`` and processes that it forks.
|
|
``-ff`` tells ``strace`` to trace child processes and write the results to a
|
|
separate file for each process, named using the prefix given by ``-o``.
|
|
|
|
Search the log files for specific terms to find the process you're interested
|
|
in. For example, to find a process that acted as a ``gdbserver`` instance::
|
|
|
|
$ grep "gdbserver" log.*
|
|
log.<N>:execve("<...>/lldb-server", [<...> "gdbserver", <...>) = 0
|
|
|
|
Remote Debugging
|
|
----------------
|
|
|
|
If you want to debug part of LLDB running on a remote machine, the principals
|
|
are the same but we will have to start debug servers, then attach debuggers to
|
|
those servers.
|
|
|
|
In the example below we're debugging an ``lldb-server`` ``gdbserver`` mode
|
|
command running on a remote machine.
|
|
|
|
For simplicity we'll use the same ``lldb-server`` as the debug server
|
|
and the inferior, but it doesn't need to be that way. You can use ``gdbserver``
|
|
(as in, GDB's debug server program) or a system installed ``lldb-server`` if you
|
|
suspect your local copy is not stable. As is the case in many of these
|
|
scenarios.
|
|
|
|
::
|
|
|
|
$ <...>/bin/lldb-server gdbserver 0.0.0.0:54322 -- \
|
|
<...>/bin/lldb-server gdbserver 0.0.0.0:54321 -- /tmp/test.o
|
|
|
|
Now we have a debug server listening on port 54322 of our remote (``0.0.0.0``
|
|
means it's listening for external connections). This is where we will connect
|
|
``lldb`` to, to debug the second ``lldb-server``.
|
|
|
|
To trigger behaviour in the second ``lldb-server``, we will connect a second
|
|
``lldb`` to port 54321 of the remote.
|
|
|
|
This is the final configuration:
|
|
|
|
::
|
|
|
|
Host | Remote
|
|
--------------------------------------------|--------------------
|
|
lldb A debugs lldb-server on port 54322 -> | lldb-server A
|
|
| (which runs)
|
|
lldb B debugs /tmp/test.o on port 54321 -> | lldb-server B
|
|
| (which runs)
|
|
| /tmp/test.o
|
|
|
|
You would use ``lldb A`` to place a breakpoint in the code you're interested in,
|
|
then ``lldb B`` to trigger ``lldb-server B`` to go into that code and hit the
|
|
breakpoint. ``lldb-server A`` is only here to let us debug ``lldb-server B``
|
|
remotely.
|
|
|
|
Debugging The Remote Protocol
|
|
-----------------------------
|
|
|
|
LLDB mostly follows the `GDB Remote Protocol <https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html>`_
|
|
. Where there are differences it tries to handle both LLDB and GDB behaviour.
|
|
|
|
LLDB does have extensions to the protocol which are documented in
|
|
`lldb-gdb-remote.txt <https://github.com/llvm/llvm-project/blob/main/lldb/docs/lldb-gdb-remote.txt>`_
|
|
and `lldb/docs/lldb-platform-packets.txt <https://github.com/llvm/llvm-project/blob/main/lldb/docs/lldb-platform-packets.txt>`_.
|
|
|
|
Logging Packets
|
|
***************
|
|
|
|
If you just want to observe packets, you can enable the ``gdb-remote packets``
|
|
log channel.
|
|
|
|
::
|
|
|
|
(lldb) log enable gdb-remote packets
|
|
(lldb) run
|
|
lldb < 1> send packet: +
|
|
lldb history[1] tid=0x264bfd < 1> send packet: +
|
|
lldb < 19> send packet: $QStartNoAckMode#b0
|
|
lldb < 1> read packet: +
|
|
|
|
You can do this on the ``lldb-server`` end as well by passing the option
|
|
``--log-channels "gdb-remote packets"``. Then you'll see both sides of the
|
|
connection.
|
|
|
|
Some packets may be printed in a nicer way than others. For example XML packets
|
|
will print the literal XML, some binary packets may be decoded. Others will just
|
|
be printed unmodified. So do check what format you expect, a common one is hex
|
|
encoded bytes.
|
|
|
|
You can enable this logging even when you are connecting to an ``lldb-server``
|
|
in platform mode, this protocol is used for that too.
|
|
|
|
Debugging Packet Exchanges
|
|
**************************
|
|
|
|
Say you want to make ``lldb`` send a packet to ``lldb-server``, then debug
|
|
how the latter builds its response. Maybe even see how ``lldb`` handles it once
|
|
it's sent back.
|
|
|
|
That all takes time, so LLDB will likely time out and think the remote has gone
|
|
away. You can change the ``plugin.process.gdb-remote.packet-timeout`` setting
|
|
to prevent this.
|
|
|
|
Here's an example, first we'll start an ``lldb-server`` being debugged by
|
|
``lldb``. Placing a breakpoint on a packet handler we know will be hit once
|
|
another ``lldb`` connects.
|
|
|
|
::
|
|
|
|
$ lldb -- lldb-server gdbserver :1234 -- /tmp/test.o
|
|
<...>
|
|
(lldb) b GDBRemoteCommunicationServerCommon::Handle_qSupported
|
|
Breakpoint 1: where = <...>
|
|
(lldb) run
|
|
<...>
|
|
|
|
Next we connect another ``lldb`` to this, with a timeout of 5 minutes:
|
|
|
|
::
|
|
|
|
$ lldb /tmp/test.o
|
|
<...>
|
|
(lldb) settings set plugin.process.gdb-remote.packet-timeout 300
|
|
(lldb) gdb-remote 1234
|
|
|
|
Doing so triggers the breakpoint in ``lldb-server``, bringing us back into
|
|
``lldb``. Now we've got 5 minutes to do whatever we need before LLDB decides
|
|
the connection has failed.
|
|
|
|
::
|
|
|
|
* thread #1, name = 'lldb-server', stop reason = breakpoint 1.1
|
|
frame #0: 0x0000aaaaaacc6848 lldb-server<...>
|
|
lldb-server`lldb_private::process_gdb_remote::GDBRemoteCommunicationServerCommon::Handle_qSupported:
|
|
-> 0xaaaaaacc6848 <+0>: sub sp, sp, #0xc0
|
|
<...>
|
|
(lldb)
|
|
|
|
Once you're done simply ``continue`` the ``lldb-server``. Back in the other
|
|
``lldb``, the connection process will continue as normal.
|
|
|
|
::
|
|
|
|
Process 2510266 stopped
|
|
* thread #1, name = 'test.o', stop reason = signal SIGSTOP
|
|
frame #0: 0x0000fffff7fcd100 ld-2.31.so`_start
|
|
ld-2.31.so`_start:
|
|
-> 0xfffff7fcd100 <+0>: mov x0, sp
|
|
<...>
|
|
(lldb)
|
|
|
|
Reducing Bugs
|
|
-------------
|
|
|
|
This section covers reducing a bug that happens in LLDB itself, or where you
|
|
suspect that LLDB causes something else to behave abnormally.
|
|
|
|
Since bugs vary wildly, the advice here is general and incomplete. Let your
|
|
instincts guide you and don't feel the need to try everything before reporting
|
|
an issue or asking for help. This is simply inspiration.
|
|
|
|
Reduction
|
|
*********
|
|
|
|
The first step is to reduce uneeded compexity where it is cheap to do so. If
|
|
something is easily removed or frozen to a cerain value, do so. The goal is to
|
|
keep the failure mode the same, with fewer dependencies.
|
|
|
|
This includes, but is not limited to:
|
|
|
|
* Removing test cases that don't crash.
|
|
* Replacing dynamic lookups with constant values.
|
|
* Replace supporting functions with stubs that do nothing.
|
|
* Moving the test case to less unqiue system. If your machine has an exotic
|
|
extension, try it on a readily available commodity machine.
|
|
* Removing irrelevant parts of the test program.
|
|
* Reproducing the issue without using the LLDB test runner.
|
|
* Converting a remote debuging scenario into a local one.
|
|
|
|
Now we hopefully have a smaller reproducer than we started with. Next we need to
|
|
find out what components of the software stack might be failing.
|
|
|
|
Some examples are listed below with suggestions for how to investigate them.
|
|
|
|
* Debugger
|
|
|
|
* Use a `released version of LLDB <https://github.com/llvm/llvm-project/releases>`_.
|
|
|
|
* If on MacOS, try the system ``lldb``.
|
|
|
|
* Try GDB or any other system debugger you might have e.g. Microsoft Visual
|
|
Studio.
|
|
|
|
* Kernel
|
|
|
|
* Start a virtual machine running a different version. ``qemu-system`` is
|
|
useful here.
|
|
|
|
* Try a different physical system running a different version.
|
|
|
|
* Remember that for most kernels, userspace crashing the kernel is always a
|
|
kernel bug. Even if the userspace program is doing something unconventional.
|
|
So it could be a bug in the application and the kernel.
|
|
|
|
* Compiler and compiler options
|
|
|
|
* Try other versions of the same compiler or your system compiler.
|
|
|
|
* Emit older versions of DWARF info, particularly DWARFv4 to v5, some tools
|
|
did/do not understand the new constructs.
|
|
|
|
* Reduce optimisation options as much as possible.
|
|
|
|
* Try all the language modes e.g. C++17/20 for C++.
|
|
|
|
* Link against LLVM's libcxx if you suspect a bug involving the system C++
|
|
library.
|
|
|
|
* For languages other than C/C++ e.g. Rust, try making an equivalent program
|
|
in C/C++. LLDB tends to try to fit other languages into a C/C++ mould, so
|
|
porting the program can make triage and reporting much easier.
|
|
|
|
* Operating system
|
|
|
|
* Use docker to try various versions of Linux.
|
|
|
|
* Use ``qemu-system`` to emulate other operating systems e.g. FreeBSD.
|
|
|
|
* Architecture
|
|
|
|
* Use `QEMU user space emulation <https://www.qemu.org/docs/master/user/main.html>`_
|
|
to quickly test other architectures. Note that ``lldb-server`` cannot be used
|
|
with this as the ptrace APIs are not emulated.
|
|
|
|
* If you need to test a big endian system use QEMU to emulate s390x (user
|
|
space emulation for just ``lldb``, ``qemu-system`` for testing
|
|
``lldb-server``).
|
|
|
|
.. note:: When using QEMU you may need to use the built in GDB stub, instead of
|
|
``lldb-server``. For example if you wanted to debug ``lldb`` running
|
|
inside ``qemu-user-s390x`` you would connect to the GDB stub provided
|
|
by QEMU.
|
|
|
|
The same applies if you want to see how ``lldb`` would debug a test
|
|
program that is running on s390x. It's not totally accurate because
|
|
you're not using ``lldb-server``, but this is fine for features that
|
|
are mostly implemented in ``lldb``.
|
|
|
|
If you are running a full system using ``qemu-system``, you likely
|
|
want to connect to the ``lldb-server`` running within the userspace
|
|
of that system.
|
|
|
|
If your test program is bare metal (meaning it requires no supporting
|
|
operating system) then connect to the built in GDB stub. This can be
|
|
useful when testing embedded systems or kernel debugging.
|
|
|
|
Reducing Ptrace Related Bugs
|
|
****************************
|
|
|
|
This section is written Linux specific but the same can likely be done on
|
|
other Unix or Unix like operating systems.
|
|
|
|
Sometimes you will find ``lldb-server`` doing something with ptrace that causes
|
|
a problem. Your reproducer involves running ``lldb`` as well, this is not going
|
|
to go over well with kernel and is generally more difficult to explain if you
|
|
want to get help with it.
|
|
|
|
If you think you can get your point across without this, no need. If you're
|
|
pretty sure you have for example found a Linux Kernel bug, doing this greatly
|
|
increases the chances it'll get fixed.
|
|
|
|
We'll remove the LLDB dependency by making a smaller standalone program that
|
|
does the same actions. Starting with a skeleton program that forks and debugs
|
|
the inferior process.
|
|
|
|
The program presented `here <https://eli.thegreenplace.net/2011/01/23/how-debuggers-work-part-1>`_
|
|
(`source <https://github.com/eliben/code-for-blog/blob/master/2011/simple_tracer.c>`_)
|
|
is a great starting point. There is also an AArch64 specific example in
|
|
`the LLDB examples folder <https://github.com/llvm/llvm-project/tree/main/lldb/examples/ptrace_example.c>`_.
|
|
|
|
For either, you'll need to modify that to fit your architecture. A tip for this
|
|
is to take any constants used in it, find in which function(s) they are used in
|
|
LLDB and then you'll find the equivalent constants in the same LLDB functions
|
|
for your architecture.
|
|
|
|
Once that is running as expected we can convert ``lldb-server``'s into calls in
|
|
this program. To get a log of those, run ``lldb-server`` with
|
|
``--log-channels "posix ptrace"``. You'll see output like:
|
|
|
|
::
|
|
|
|
$ lldb-server gdbserver :1234 --log-channels "posix ptrace" -- /tmp/test.o
|
|
1694099878.829990864 <...> ptrace(16896, 2659963, 0x0000000000000000, 0x000000000000007E, 0)=0x0
|
|
1694099878.830722332 <...> ptrace(16900, 2659963, 0x0000FFFFD14BF7CC, 0x0000FFFFD14BF7D0, 16)=0x0
|
|
1694099878.831967115 <...> ptrace(16900, 2659963, 0x0000FFFFD14BF66C, 0x0000FFFFD14BF630, 16)=0xffffffffffffffff
|
|
1694099878.831982136 <...> ptrace() failed: Invalid argument
|
|
Launched '/tmp/test.o' as process 2659963...
|
|
|
|
Each call is logged with its parameters and its result as the ``=`` on the end.
|
|
|
|
From here you will need to use a combination of the `ptrace documentation <https://man7.org/linux/man-pages/man2/ptrace.2.html>`_
|
|
and Linux Kernel headers (``uapi/linux/ptrace.h`` mainly) to figure out what
|
|
the calls are.
|
|
|
|
The most important parameter is the first, which is the request number. In the
|
|
example above ``16896``, which is hex ``0x4200``, is ``PTRACE_SETOPTIONS``.
|
|
|
|
Luckily, you don't usually have to figure out all those early calls. Our
|
|
skeleton program will be doing all that, successfully we hope.
|
|
|
|
What you should do is record just the interesting bit to you. Let's say
|
|
something odd is happening when you read the ``tpidr`` register (this is an
|
|
AArch64 register, just for example purposes).
|
|
|
|
First, go to the ``lldb-server`` terminal and press enter a few times to put
|
|
some blank lines after the last logging output.
|
|
|
|
Then go to your ``lldb`` and:
|
|
|
|
::
|
|
|
|
(lldb) register read tpidr
|
|
tpidr = 0x0000fffff7fef320
|
|
|
|
You'll see this from ``lldb-server``:
|
|
|
|
::
|
|
|
|
<...> ptrace(16900, 2659963, 0x0000FFFFD14BF6CC, 0x0000FFFFD14BF710, 8)=0x0
|
|
|
|
If you don't see that, it may be because ``lldb`` has cached it. The easiest way
|
|
to clear that cache is to step. Remember that some registers are read every
|
|
step, so you'll have to adjust depending on the situation.
|
|
|
|
Assuming you've got that line, you would look up what ``116900`` is. This is
|
|
``0x4204`` in hex, which is ``PTRACE_GETREGSET``. As we expected.
|
|
|
|
The following parameters are not as we might expect because what we log is a bit
|
|
different from the literal ptrace call. See your platform's definition of
|
|
``PtraceWrapper`` for the exact form.
|
|
|
|
The point of all this is that by doing a single action you can get a few
|
|
isolated ptrace calls and you can then fill in the blanks and write
|
|
equivalent calls in the skeleton program.
|
|
|
|
The final piece of this is likely breakpoints. Assuming your bug does not
|
|
require a hardware breakpoint, you can get software breakpoints by inserting
|
|
a break instruction into the inferior's code at compile time. Usually by using
|
|
an architecture specific assembly statement, as you will need to know exactly
|
|
how many instructions to overwrite later.
|
|
|
|
Doing it this way instead of exactly copying what LLDB does will save a few
|
|
ptrace calls. The AArch64 example program shows how to do this.
|
|
|
|
* The inferior contains ``BRK #0`` then ``NOP``.
|
|
* 2 4 byte instructins means 8 bytes of data to replace, which matches the
|
|
minimum size you can write with ``PTRACE_POKETEXT``.
|
|
* The inferior runs to the ``BRK``, which brings us into the debugger.
|
|
* The debugger reads ``PC`` and writes ``NOP`` then ``NOP`` to the location
|
|
pointed to by ``PC``.
|
|
* The debugger then single steps the inferior to the next instruction
|
|
(this is not required in this specific scenario, you could just continue but
|
|
it is included because this more cloesly matches what ``lldb`` does).
|
|
* The debugger then continues the inferior.
|
|
* The inferior exits, and the whole program exits.
|
|
|
|
Using this technique you can emulate the usual "run to main, do a thing" type
|
|
reproduction steps.
|
|
|
|
Finally, that "thing" is the ptrace calls you got from the ``lldb-server`` logs.
|
|
Add those to the debugger function and you now have a reproducer that doesn't
|
|
need any part of LLDB.
|
|
|
|
Debugging Tests
|
|
---------------
|
|
|
|
See :doc:`/resources/test`. |