The dyld SPI used by debugserver (_dyld_process_info_create) has become
much slower in macOS BigSur 11.3 causing a significant performance
regression when attaching. This commit mitigates that by caching the
result when calling the SPI to compute the platform.
Differential revision: https://reviews.llvm.org/D102833
Fix the logic to find the app bundle in a path by correctly accounting
for paths containing multiple occurrences of `.app`. The new logic will
correctly extract `com.app.Foo.app` from `com.app.Foo.app/com.app.Foo`.
rdar://74666208
Differential revision: https://reviews.llvm.org/D97441
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
Use the newly added spawnattr API, posix_spawnattr_setarchpref_np, to
select a slice preferences per cpu and subcpu types, instead of just cpu
with posix_spawnattr_setarchpref_np.
rdar://16094957
Differential revision: https://reviews.llvm.org/D92712
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
Link against CarouselServices on watchos, recognize the
WatchComplicationLaunch launch flag option when that framework
is available.
<rdar://problem/62473967>, <rdar://problem/61230088>
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
This patch basically moves the disambiguation code from a place where
it was complicated to implement straight to where the load command is
parsed, which has the neat side affect of actually supporting all call
sites!
rdar://problem/66011909
Differential Revision: https://reviews.llvm.org/D84480
This patch fixes debugserver incorrectly returning the SDK version
instead of the minimum deployment target version.
rdar://problem/65001691
Differential Revision: https://reviews.llvm.org/D83443
This reverts commit 0da0437b2a to unbreak
the following tests:
lldb-api.tools/lldb-server.TestAppleSimulatorOSType.py
lldb-api.tools/lldb-server.TestGdbRemoteAttach.py
lldb-api.tools/lldb-server.TestGdbRemoteProcessInfo.py
lldb-api.tools/lldb-server.TestGdbRemoteRegisterState.py
lldb-api.tools/lldb-server.TestGdbRemoteThreadsInStopReply.py
lldb-api.tools/lldb-server.TestLldbGdbServer.py
debugserver and lldb
This patch improves the heuristics for correctly identifying simulator binaries on Darwin and adds support for simulators running on Apple Silicon.
rdar://problem/64046344
Differential Revision: https://reviews.llvm.org/D82616
MachProcess.mm uses a TARGET_OS_ macro without directly including
TargetConditionals.h. This currently works as we get the header
as an indirect dependency, but might not in the future.
I just spent some time investigating an internal regression
caused by a similar issue, so I audited the codebase for such
cases.
Update CallBoardSystemServiceOpenApplication to unconditionally log
the NSError's localizedDescription to Console on app launch failure
(as it was already doing), and also to log the NSError object's
full description to the console, which may contain additional nested
error messages. I'm experimenting to find cases where we will get
more detailed information from app launch failures and will start
by logging both to the console.
<rdar://problem/62709160>
Starting with iOS 13 simulator binaries are identified with an
explicit platform in the new LC_BUILD_VERSION load command.
On older deployment targets using the LC_VERSION_MIN load commands,
this patch detects when an ios process runs on a macOS host and
updates the target triple with the "simulator" environment
accordingly.
(Patch re-applied with bugfix this time).
This is part of https://bugs.swift.org/browse/SR-11971
rdar://problem/58438125
Differential Revision: https://reviews.llvm.org/D75696
Starting with iOS 13 simulator binaries are identified with an
explicit platform in the new LC_BUILD_VERSION load command.
On older deployment targets using the LC_VERSION_MIN load commands,
this patch detects when an ios process runs on a macOS host and
updates the target triple with the "simulator" environment
accordingly.
(Patch re-applied without modifications, the bot failure was unrelated).
This is part of https://bugs.swift.org/browse/SR-11971
rdar://problem/58438125
Differential Revision: https://reviews.llvm.org/D75696
Starting with iOS 13 simulator binaries are identified with an
explicit platform in the new LC_BUILD_VERSION load command.
On older deployment targets using the LC_VERSION_MIN load commands,
this patch detects when an ios process runs on a macOS host and
updates the target triple with the "simulator" environment
accordingly.
This is part of https://bugs.swift.org/browse/SR-11971
rdar://problem/58438125
Differential Revision: https://reviews.llvm.org/D75696
The debugserver profile thread used to suspend itself between samples with
a usleep. When you detach or kill, MachProcess::Clear would delay replying
to the incoming packet until pthread_join of the profile thread returned.
If you are unlucky or the suspend delay is long, it could take longer than
the packet timeout for pthread_join to return. Then you would get an error
about detach not succeeding from lldb - even though in fact the detach was
successful...
I replaced the usleep with PThreadEvents entity. Then we just call a timed
WaitForEventBits, and when debugserver wants to stop the profile thread, it
can set the event bit, and the sleep will exit immediately.
Differential Revision: https://reviews.llvm.org/D75004
When launching an inferior in a new terminal window via AppleScript
and the darwin-debug helper program, we could often end up with the
inferior process having a too-high suspend count, and it would never
resume execution.
lldb tries to wait until darwin-debug has finished its work and has
launched the inferior (WaitForProcessToSIGSTOP) but this wasn't
working correctly - and cannot be made to work.
This patch removes WaitForProcessToSIGSTOP, adds a special tiny
segment to the darwin-debug executable so it can be identified as
that binary (ExecExtraSuspend), and adds code to debugserver to
detect this segment. When debugserver sees this segment, it notes
that the next exec will be done with a launch-suspended flag. When
the next exec happens, debugserver forces an extra task_resume when
we resume the inferior.
An alternative approach would be if lldb could detect when the
inferior has been launched by darwin-debug unambiguously; monitoring
when the unix socket between darwin-debug and lldb was closed would
have been a reasonable way to do this too.
<rdar://problem/29760580>
Differential Revision: https://reviews.llvm.org/D72963
When lldb requests an app launch through FrontBoard/BackBoard,
we get back an NSError object if there was a problem with an
integer error code and a descriptive text string. debugserver
would log the descriptive text string to the console, but it
would only save the error code value, ask for the
much-less-specific name of that error code, and send that very
generic error word back to lldb.
This patch saves the longer description of the failure when
available, and sends that to lldb. If unavailable, it falls
back to sending up the generic description of the error code
as it was doing before.
This only impacts the iOS on-device debugserver.
<rdar://problem/49953304>
Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`.
Reviewers: shafik, JDevlieghere, labath
Reviewed By: labath
Subscribers: arphaman, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72161
plugin.
Unfortunately the test is currently XFAILed because of missing changes
to the clang driver.
Differential Revision: https://reviews.llvm.org/D67124
llvm-svn: 370931
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
unused IsSBProcess method, and have IsFBSProcess
return false if we don't have API that we can use to
make that determination, so we'll try other API
if we can.
llvm-svn: 354289
to a process so we'll always get messages in the console logs.
Also make the "is frontboard process" / "is backboard process"
determination lazy, specifically take it out of the
MachProcess::AttachForDebug codepath when we are attaching to a
process, to simplify attaching.
<rdar://problem/47982516>
<rdar://problem/48060134>
llvm-svn: 354181
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
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
reads an ObjectFileMachO's string table in one chunk. Originally
this was commented out because binaries in the system's shared cache
all share a mega-string table and so reading the entire mega-strtab
for each binary was a performance problem.
In the reinstated code, I add a check that the binary we're reading
from memory is not in the shared cache (there isn't a constant in
<mach-o/loader.h> for this bit yet; we hardcode the value in one
other place in ObjectFileMachO alread). For binaries that we're
reading out of memory that are NOT in the shared cache, reading
the string table in one chunk is a big performance improvement.
Also have debugserver send up the flags value for binaries in its
response to the jGetLoadedDynamicLibrariesInfos request.
NFC.
<rdar://problem/33604496>
llvm-svn: 341511
The toolchain in Xcode 10 uses a new LC_BUILD_VERSION entry to identify
simulator binaries. Add support for reading those to debugserver.
The exisitng test testing that code is currently failling when run
with Xcode 10, no need for a new test.
llvm-svn: 334784
When I merged the 2 codepaths that return an OS type, I hade
checked that the places accepting 'iphoneos' would also accept
'ios', but then I got it backwards and return 'iphoneos'.
We use this value to build triples, and there 'iphoneos' is
invalid.
This also makes the test slightly simpler.
llvm-svn: 330877
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
Jonas Devlieghere