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
- Remove unused plists that were referenced (but unused) by Xcode.
- Move all debugserver plists unders tools/debugserver/resources.
- Add the ability to distinguish between com.apple.security.cs.debugger
and com.apple.private.cs.debugger.
rdar://66082043
Differential revision: https://reviews.llvm.org/D94320
Add stN aliases for the FPU (stmmN) registers on MacOSX. This should
improve compatibility between MacOSX and other platforms, and partially
fix x86*-fp-write tests without having to duplicate them. Note that
the tests are currently still broken due to ftag incompatibility.
Differential Revision: https://reviews.llvm.org/D91847
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
On x86_64, when you hit a __builtin_debugtrap instruction, you
can continue past this in the debugger. This patch has debugserver
recognize the specific instruction used for __builtin_debugtrap
and advance the pc past it, so that the user can continue execution
once they've hit one of these.
In the patch discussion, we were in agreement that it would be better
to have this knowledge up in lldb instead of depending on each
stub rewriting the pc behind the debugger's back, but that's a
larger scale change for another day.
<rdar://problem/65521634>
Differential revision: https://reviews.llvm.org/D91238
the xcode project file for debugserver exists only to make my
life easier when I'm working only on debugserver and don't need
to build the rest of llvm/lldb. It had many build configurations
to reflect our old lldb xcode project file, which is long gone.
Removing them to simplify the configurations.
Specifically dropping CustomSwift-Debug, DebugClang, DebugPresubmission,
CustomSwift-Release, BuildAndIntegration. Keeping Debug & Release.
Link against CarouselServices on watchos, recognize the
WatchComplicationLaunch launch flag option when that framework
is available.
<rdar://problem/62473967>, <rdar://problem/61230088>
Extract a function for turning `eLaunchFlavorDefault` into a concreate `eLaunchFlavor` value.
This new function encapsulates the few compile time variables involved, and also prevents clang unused code diagnostics.
Differential Revision: https://reviews.llvm.org/D87327
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 configures LLDB.framework to build as a flat unversioned
framework on non-macOS Darwin targets, which have never supported the
macOS framework layout.
This patch also renames the 'IOS' cmake variable to 'APPLE_EMBEDDED' to
reflect the fact that lldb is built for several different kinds of embedded
Darwin targets, not just iOS.
Differential Revision: https://reviews.llvm.org/D85770
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
On an iOS device, if debugserver is left to figure out how to launch
the binary provided, it looks at the filename to see if it contains
".app" and asks FrontBoard to launch it. However, if this is actually
a command line app with the characters ".app" in the name, it would
end up trying to launch that via the FrontBoard calls even though it
needed to be launched via posix_spawn. For instance, a command line
program called com.application.tester.
Jim suggested this patch where we only send binaries that end in ".app"
to FrontBoard.
Often debugsever is invoked with a --launch command line argument to
specify the launch method, and none of this code is hit in that
instance.
<rdar://problem/65297100>
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
These were found by Clang's new -Wsuggest-override.
This patch doesn't touch any code in unittests/, since much of it intentionally doesn't use override to avoid massive warning spam from -Winconsistent-missing-override due to the use of MOCK_*** macros.
Differential Revision: https://reviews.llvm.org/D83847
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
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
This brings over functionality from the xcodeproject that went missing during the CMake transition.
rdar://problem/63840635
Differential Revision: https://reviews.llvm.org/D81300
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
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.
Similar to
com.apple.debugserver.plist & com.apple.debugserver.internal.plist
com.apple.debugserver.applist.plist & com.apple.debugserver.applist.internal.plist
add a variant of the posix plist.
<rdar://problem/62995567>
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>
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>
Summary:
Compiling ObjC++ with Clang modules is usually not working well and compiling
the small debugserver with modules is not worth the trouble.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: mgorny, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74891
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
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.
Differential revision: https://reviews.llvm.org/D74743
Look up the -arch flags to pass to the mig invocation from an
optionally-defined MIG_ARCHS variable. We can't use CMAKE_OSX_ARCHS
because the {i,tv,watch}OS builds don't use this mechanism to achieve
fat builds (they build each slice separately & then lipo them together).
This supercedes the mig -arch/-isysroot fix from
510758dae2.
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.
Unify the interface for enabling and disabling breakpoints with their
watchpoint counterpart. This allows both to go through
DoHardwareBreakpointAction.
Differential revision: https://reviews.llvm.org/D72981
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
This extract the common functionality of enabling and disabling hardware
watchpoints into a single function.
Differential revision: https://reviews.llvm.org/D72971
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
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.
Use TARGET_TRIPLE instead of LLVM_DEFAULT_TARGET_TRIPLE, as the latter
isn't exported by LLVMConfig.cmake, which means arch detection fails if
lldb is built separately from llvm.
When building standalone, `LLVM_DEFAULT_TARGET_TRIPLE` may be undefined.
Matching against an empty string does not work as desired in CMake, so,
fallback to the old behaviour, defaulting `LLDB_DEBUGSERVER_ARCH` to
`CMAKE_OSX_ARCHITECTURES`.
`LLVM_DEFAULT_TARGET_TRIPLE` is a cached variable, which means that it
may actually be unset. Furthermore, in standalone builds, the variable
may be fully undefined. Apply the regular expression over the empty
string in such a case. This should improve the state of the green
dragon bot.
The debugserver build needs to conditionally include files depending on the
target architecture.
Switch on the architecture specified by LLVM_DEFAULT_TARGET_TRIPLE, as
the llvm and swift build systems use this variable to identify the
target (the latter, indirectly, through LLVM_HOST_TRIPLE).
It would be possible to switch on CMAKE_OSX_ARCHITECTURES, but the swift
build does not provide it, preferring instead to pass arch-specific
CFLAGS etc explicitly. Switching on LLVM_HOST_TRIPLE is also an option,
but it breaks down when cross-compiling.
Differential Revision: https://reviews.llvm.org/D69523
debugserver had been using an instruction that would work
for armv7 or aarch64 processes, but we don't have armv7 code
running on arm64 devices any more so this is unnecessary.
<rdar://problem/56133118>
llvm-svn: 374264
Summary:
We mark debugserver_vers.c as a generated file in CMake. This means that when we run `ninja clean` we end up deleting that file,
but any following `ninja` invocation will fail due to the file missing. The file can't be generated as `ninja` doesn't know it has to
rerun CMake to create the file. Turns out that marking the output of configure_file as generated is wrong as explained in this bug report:
https://gitlab.kitware.com/cmake/cmake/issues/18032
This patch just removes that property. The only side effect of this seems to be that this file maybe shows up in your IDE when
opening our CMake project, but that seems like a small sacrifice.
This patch can be quickly tested by running `ninja clean ; ninja lldbDebugserverCommon`. Before this patch the build will fail
due to debugserver_vers.c missing.
Reviewers: JDevlieghere, labath
Reviewed By: labath
Subscribers: mgorny, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68376
llvm-svn: 373723
When not running under a TTY the output is buffered and not flushed
before debugserver exits which makes it impossible to parse the version
string. This adds a -V/--version command that just prints the version to
stdout and exits with an exit code zero.
Differential revision: https://reviews.llvm.org/D68156
llvm-svn: 373127
r366433 broke support for the system debugserver. Although the change
was well-intended, it (presumably) unintentionally removed the logic to
copy over the debugserver. As a result, even with
LLDB_USE_SYSTEM_DEBUGSERVER enabled, we ended up building, signing and
using the just-built debugserver.
This patch partially recovers the old behavior: when
LLDB_USE_SYSTEM_DEBUGSERVER is set we don't build debugserver and just
copy over the system one.
Differential revision: https://reviews.llvm.org/D67991
llvm-svn: 372786
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
Jonas Devlieghere