These two tests, TestSkinnyCorefile.py and TestStackCorefile.py,
require a new debugserver on darwin systems to run correctly; for now,
skip them if the system debugserver is in use. There's no easy way to
test if the debugserver being used supports either of these memory
region info features. For end users, the fallback will be a full
corefile and that's not the worst thing, but for the tests it is a
problem.
Add a field to the qMemoryRegionInfo packet where the remote stub
can describe the type of memory -- heap, stack. Keep track of
memory regions that are stack memory in lldb. Add a new "--style
stack" to process save-core to request that only stack memory be
included in the corefile.
Differential Revision: https://reviews.llvm.org/D107625
Remove the DarwinLog and qStructuredDataPlugins support
from debugserver. The DarwinLog plugin was never debugged
fully and made reliable, and the underlying private APIs
it uses have migrated since 2016 so none of them exist
any longer.
Differential Revision: https://reviews.llvm.org/D106324
rdar://75073283
Add a new feature to process save-core on Darwin systems -- for
lldb to create a user process corefile with only the dirty (modified
memory) pages included. All of the binaries that were used in the
corefile are assumed to still exist on the system for the duration
of the use of the corefile. A new --style option to process save-core
is added, so a full corefile can be requested if portability across
systems, or across time, is needed for this corefile.
debugserver can now identify the dirty pages in a memory region
when queried with qMemoryRegionInfo, and the size of vm pages is
given in qHostInfo.
Create a new "all image infos" LC_NOTE for Mach-O which allows us
to describe all of the binaries that were loaded in the process --
load address, UUID, file path, segment load addresses, and optionally
whether code from the binary was executing on any thread. The old
"read dyld_all_image_infos and then the in-memory Mach-O load
commands to get segment load addresses" no longer works when we
only have dirty memory.
rdar://69670807
Differential Revision: https://reviews.llvm.org/D88387
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D103084
A debugserver launched x86_64 cannot control an arm64/arm64e
process on an Apple Silicon system. Warn when this situation
has happened and return an error for the most common case of
attach. I think there will be refinements to this in the
future, but start out by making it easy to spot the problem
when it happens.
rdar://76630595
Having this 4MB buffer with a compile-time initialized string forced it
into the DATA section and it took up 4MB of space in the binary, which
accounts for like 80% of debugserver's footprint on disk. Change it to
BSS and strcpy in the initial value at runtime instead.
<rdar://problem/73503892>
Debugging app launch/attach failures can be difficult because of
all of the messages logged to the console on a darwin system;
emitting specific messages around critical API calls can make it
easier to narrow the search for the console messages related to
the failure.
<rdar://problem/67220442>
Differential revision: https://reviews.llvm.org/D94357
Adds a command line option that makes debugserver propagate the SIGSEGV
signal to the target process.
Motivation: I'm one of the maintainers of Delve [1] a debugger for Go.
We use debugserver as our backend on macOS and one of the most often
reported bugs is that, on macOS, we don't propagate SIGSEGV back to the
target process [2]. Sometimes some programs will actually cause a
SIGSEGV, by design, and then handle it. Those programs can not be
debugged at all.
Since catching signals isn't very important for a Go debugger I'd much
rather have a command line option in debugserver that causes it to let
SIGSEGV go directly to the target process.
[1] https://github.com/go-delve/delve/
[2] https://github.com/go-delve/delve/issues/852
Differential revision: https://reviews.llvm.org/D89315
If our process terminates due to an unhandled signal, we are supposed to get the
signal code via WTERMSIG. However, we instead try to get the exit status via
WEXITSTATUS which just ends up always calculating signal code 0 (at least on the
macOS implementation where it just shifts the signal code bits away and we're
left with only 0 bits).
The exit status calculation on the LLDB side also seems a bit off as it claims
an exit status that is just the signal code (instead of for example 128 + signal
code), but that will be another patch.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D86336
This patch is similar in spirit to https://reviews.llvm.org/D84480,
but does the maccatalyst/macosx disambiguation. I also took the
opportunity to factor out the gdb-remote packet log scanning used by
several testcases into lldbutil functions.
rdar://problem/66059257
Differential Revision: https://reviews.llvm.org/D84576
Set the correct os type in the arch triple when running macOS.
Debugserver currently always assumes macOS == x86_64. This patch
generalizes the support to make sure it works on a different
architecture.
Differential Revision: https://reviews.llvm.org/D82394
If the error message from qLaunchSucess included a gdb RSP
metacharacter, it could crash lldb. Apply the binary
escaping to the string before sending it to lldb; lldb
promiscuously applies the binary escaping protocol on
packets it receives.
Also fix a small bug in cstring_to_asciihex_string where
a high bit character (eg utf-8 chars) would not be
quoted correctly due to signed char fun.
Differential Revision: https://reviews.llvm.org/D79614
rdar://problem/62873581
The SIP debugserver was calling in attach_failed_due_to_sip
haven't worked for a while; remove them. To check this
properly we'd need debugsever to call out to codesign(1) to
inspect the entitlements, or the equivalant API,
and I'm not interested in adding that at this point. SIP
is has been the default on macOS for a couple of releases
and it's expected behavior now.
<rdar://problem/59198052>
The developer mode check is now working.
Add another check for user id mismatch, e.g. a regular user
trying to attach to something running as root, and describe
the problem for the user.
Explicitly check for a request to attach to a pid that doesn't
exist, to attach to a pid that is already being debugged, unify the
SIP process check, and an attempt at checking if developer mode is
enabled on the system (which isn't working in debugserver, for some
reason; I can't get the authorization record which should be an
unprivileged operation and works in a standalone program I wrote).
I'll debug the developer mode check later, but I wanted to land it
along with everything else; right now it will claim that developer
mode is always enabled so it's harmless to include as-is.
The changes are minor; primarily debugserver needs to go through
accessor functions/macros when changing pc/fp/sp/lr, and debugserver
needs to clear any existing pointer auth bits from values in two
cases. debugserver can fetch the number of bits used for addressing
from a sysctl, and will include that in the qHostInfo reply. Update
qHostInfo documentation to document it.
Instead of using a magic return error code from debugserver to
indicate that an attach failed because of SIP being enabled in
RNBRemote::HandlePacket_v, use the extended error reporting that
Pavel added to lldb/lldb-server in https://reviews.llvm.org/D45573
<rdar://problem/39398385>
llvm-svn: 369990
Adrian's changes to support Catalyst processes and my
changes to support debugserver running on an arm64_32
device (Apple Watch Series 4, which uses an IPL32 model
on arm64 cpus).
llvm-svn: 368118
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.
Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.
I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.
Differential revision: https://reviews.llvm.org/D60508
llvm-svn: 358135
Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.
Differential revision: https://reviews.llvm.org/D57990
llvm-svn: 353764
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Using compare is verbose, bug prone and potentially inefficient (because
of early termination). Replace relevant call sites with the (in)equality
operator.
llvm-svn: 349972
on Darwin systems and libcompression has been in the OS for over
three years.
Remove use of / linking to zlib. We'll always have libcompression
available now.
Create a scratch buffer via compression_encode_scratch_buffer_size()
and use it in calls to compression_encode_buffer() to avoid
compression_encode_buffer having to malloc & free a scratch buffer
on each call.
Tested by forcing compression to be enabled on macos native (normally
only enabled on iOS et al devices), running the testsuite.
<rdar://problem/41601084>
llvm-svn: 349553
This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:
run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD
Differential revision: https://reviews.llvm.org/D55584
llvm-svn: 349215
This patch removes the comments following the header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
Differential revision: https://reviews.llvm.org/D54385
llvm-svn: 346625
Summary:
In one of the 2 places the LC_BUILD_VERSION load command is handled, there
is a bug preventing us from actually handling them (the address where to
read the load command was not updated). This patch factors reading the
deployment target load commands into a helper and adds testing for the 2
code paths calling the helper.
The testing is a little bit complicated because the only times those load
commands matter is when debugging a simulator process. I added a new
decorator to check that a specific SDK is available. The actual testing was
fairly easy once I knew how to run a simulated process.
Reviewers: jasonmolenda, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D45298
llvm-svn: 329374
were originally written by Chris Bieneman, they've undergone a
number of changes since then.
Also including the debugserver bridgeos support, another arm
environment that runs Darwin akin to ios. These codepaths are
activated when running in a bridgeos environment which we're not
set up to test today.
There's additional (small) lldb changes to handle bridgeos binaries
that still need to be merged up.
Tested on a darwin system with avx512 hardware and without.
<rdar://problem/36424951>
llvm-svn: 326756
been specified yet (either by the user, or by one of the lldb
extensions like qHostInfo or qProcessInfo), and the target.xml
includes a <architecture> tag specifying x86_64, set the architecture
appropriately.
I'm not sure what we can expect to see in the <architecture> tag, so
I'm only doing this for x86_64 right now where I've seen "i386:x86_64"
used. I've seen a target.xml from a jtag board that sends just "arm"
because it doesn't know more specifically what type of board it is
connected to...
<rdar://problem/29908970>
llvm-svn: 322339
Null-checking functions which aren't marked weak_import is a no-op
(the compiler rewrites the check to 'true'), regardless of whether a
library providing its definition is weak-linked. If the deployment
target is greater than the minimum requirement, the availability markup
on APIs does not lower to weak_import.
Remove no-op null checks to clean up the code and silence warnings.
Differential Revision: https://reviews.llvm.org/D40812
llvm-svn: 319936
Jason Molenda