| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
Fix alignment UB in some Mach exception-handling logic.
This lets us build lldb and debugserver with UBSan in trapping mode, and
get further along in the testing process before a trap is encountered.
rdar://35923991
llvm-svn: 320127
|
|
|
|
|
|
| |
Thanks to Jim Ingham for providing the explanation!
llvm-svn: 320126
|
|
|
|
|
|
|
| |
r319938 was not NFC, because it got the preprocessor guard wrong. Check
WITH_FBS and WITH_BKS before defining SplitEventData.
llvm-svn: 319943
|
|
|
|
| |
llvm-svn: 319938
|
|
|
|
| |
llvm-svn: 319937
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
<rdar://problem/32505028>
llvm-svn: 318496
|
|
|
|
|
|
|
|
| |
to match the changes Saleem Abdulrasool committed in r311579. Fixes
a testsuite failure now that the testsuite expects a 16 bit return
value for thsi reg.
llvm-svn: 311627
|
|
|
|
|
|
|
|
|
| |
This refactoring changes two significant things about how the debugserver build system works:
(1) debugserver will include all appropriate architecture support, so we can now build arm or ppc debugservers
(2) debugserver can be built by itself, so you don't have to configure all of LLDB in order to generate debugserver.
llvm-svn: 308377
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch refactors the CMake build system's support for building debugserver to allow us to build the majority of debugserver's sources into the debugserverCommon library which can then be reused by unit tests.
The first unit test I've written tests debug server's ability to accept incoming connections from LLDB. The test forks the process, and one side creates a listening socket using debugserver's socket API, the other side creates a transmitting socket using LLDB's TCPSocket class.
I have no clue where to even start getting this connected into the LLDB Xcode project, so for now these tests are CMake-only.
Reviewers: zturner, labath, jasonmolenda
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31357
llvm-svn: 300111
|
|
|
|
|
|
| |
<rdar://problem/31359720>
llvm-svn: 299345
|
|
|
|
|
|
| |
<rdar://problem/31335814>
llvm-svn: 299040
|
|
|
|
|
|
| |
This is another similar cleanup to other changes I've been making to simplify the AVX code in debugserver.
llvm-svn: 297880
|
|
|
|
|
|
| |
This patch modifies the Get/Set Register Value/Context functions for Intel to not duplicate code for reading non-AVX registers. This is similar to other transformations I've been making to the AVX register handling code.
llvm-svn: 297787
|
|
|
|
|
|
| |
I had mixed up the logic during patch review. This resolves the test failure reading YMM registers on Darwin.
llvm-svn: 297774
|
|
|
|
|
|
| |
I did this cleanup in the x86_64, but missed it in the i386 code. This just simplifies the calls to thread_get_state.
llvm-svn: 297691
|
|
|
|
|
|
|
|
| |
This patch consolidates the DEBUG_FPU_REGS code for i386 and x86_64 to take advantage of the fact that the non-AVX members of the avx register state structure overlap with the standard fpu register state structure.
This reduces the amount of code required to set debug values into the register state structures because the register state structures are stored in a union.
llvm-svn: 297688
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The first Sandybridge iMacs with AVX support shipped in Spring 2011 with Snow Leopard as their OS. Unfortunately due to a kernel bug debugging AVX code was not really possible until 10.7.4.
The old code here checked the kernel build number to determine when to support AVX, but that code was incorrect. It verified that the kernel build number was greater than xnu-2020, which is the build of the kernel that had the fix for 10.8. The fix was also back ported to 10.7.4. Which means all publicly available OS builds 10.7.4 and later have working AVX support.
This new patch verifies that the host OS is greater than or equal to 10.7.4 by checking that the build number is greater than or equal to 11Exx.
The patch also removes the HasAVX assembly blob in favor of querying the kernel via sysctl for the hardware features.
Using sysctl is slower, however since the code is executed once and the result cached it is a better approach because it is possible for the kernel to disable AVX support on hardware that supports it, so listening to the kernel is a better approach for the debugger to take.
Reviewers: jasonmolenda, spyffe
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30918
llvm-svn: 297685
|
|
|
|
| |
llvm-svn: 297228
|
|
|
|
| |
llvm-svn: 294221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms.
This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, mehdi_amini, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29288
llvm-svn: 294202
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds accurate dependency specifications to the mail LLDB libraries and tools.
In all cases except lldb-server, these dependencies are added in addition to existing dependencies (making this low risk), and I performed some code cleanup along the way.
For lldb-server I've cleaned up the LLVM dependencies down to just the minimum actually required. This is more than lldb-server actually directly references, and I've left a todo in the code to clean that up.
Reviewers: labath, zturner
Subscribers: lldb-commits, danalbert, srhines, ki.stfu, mgorny, jgosnell
Differential Revision: https://reviews.llvm.org/D29333
llvm-svn: 293686
|
|
|
|
| |
llvm-svn: 293161
|
|
|
|
|
|
|
|
|
|
|
|
| |
requires that this private framework be available - and it is not
available earlier than macOS 10.12 - to build lldb), dlopen the
framework binary on demand in debugserver. We're already using
dlsym() to look up all the symbols so there is no need to use weak
linking here.
<rdar://problem/30158797>
llvm-svn: 293135
|
|
|
|
|
|
| |
debugserver-mini can't use Foundation so disable that code there.
llvm-svn: 293098
|
|
|
|
| |
llvm-svn: 293020
|
|
|
|
| |
llvm-svn: 290687
|
|
|
|
|
|
|
|
| |
30 seconds to match the old springboard timeout; the launcher
should time out before that and we will hopefully get back
an informative error message instead of timing out ourselves.
llvm-svn: 290163
|
|
|
|
|
|
| |
In LLVM's CMake we have a convention that components have both a build and an install target. Making LLDB follow this convention will allow LLDB to take advantage of the LLVM_DISTRIBUTION_COMPONENTS build option from LLVM.
llvm-svn: 289879
|
|
|
|
|
|
| |
to match other timeouts.
llvm-svn: 289023
|
|
|
|
|
|
| |
<rdar://problem/28476369>
llvm-svn: 282632
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds a CMake option LLDB_BUILD_FRAMEWORK, which builds libLLDB as a macOS framework instead of as a *nix shared library.
With this patch any LLDB executable that has the INCLUDE_IN_FRAMEWORK option set will be built into the Framework's resources directory, and a symlink to the exeuctable will be placed under the build directory's bin folder. Creating the symlinks allows users to run commands from the build directory without altering the workflow.
The framework generated by this patch passes the LLDB test suite, but has not been tested beyond that. It is not expected to be fully ready to ship, but it is a first step.
With this patch binaries that are placed inside the framework aren't being properly installed. Fixing that would increase the patch size significantly, so I'd like to do that in a follow-up.
Reviewers: zturner, tfiala
Subscribers: beanz, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D24749
llvm-svn: 282110
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
|
|
|
|
|
|
|
|
|
|
|
|
| |
Take 2, with missing cmake line fixed. Build tested on
Ubuntu 14.04 with clang-3.6.
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: clayborg, jingham
llvm-svn: 279202
|
|
|
|
|
|
| |
This reverts commit 1d885845d1451e7b232f53fba2e36be67aadabd8.
llvm-svn: 279200
|
|
|
|
|
|
|
|
|
| |
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: clayborg, jingham
llvm-svn: 279198
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D23070
llvm-svn: 278142
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D22985
llvm-svn: 277351
|
|
|
|
| |
llvm-svn: 274743
|
|
|
|
|
|
|
|
|
|
|
|
| |
os name and version # from the mach-o binary as it scans the
header/load commands from memory and sends the details back
in the jGetLoadedDynamicLibrariesInfos response. lldb isn't
using these fields yet but I have a suspicion I'm going to
need them soon.
<rdar://problem/25251243>
llvm-svn: 274725
|
|
|
|
|
|
|
|
|
|
|
|
| |
to find the solibs loaded in a process. Support two new ways of
sending the jGetLoadedDynamicLibrariesInfos packet to debugserver
and add a new jGetSharedCacheInfo packet. Update the documentation
for these packets as well. The changes to lldb to use these will
be a separate commit.
<rdar://problem/25251243>
llvm-svn: 274718
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds the ability to customize the debugserver codesign process via cmake cache variable. The
user can set the codesign indentity (with the default being the customary lldb_codesign), and if
the identity is set to a empty string, the codesign step is skipped completely.
We needed the last feature to enable building lldb on buildservers which do not have the right
certificates installed.
Reviewers: sas, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20623
llvm-svn: 270832
|
|
|
|
|
|
|
| |
before comparing the value of it.
<rdar://problem/26333564>
llvm-svn: 270015
|
|
|
|
|
|
|
|
|
|
|
| |
information on iOS devices
The __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED macro is only defined on OS X, so the check as written compiled the code out for iOS
The right thing to do is compile the code out for older OSX versions, but leave iOS alone
rdar://26333564
llvm-svn: 270004
|
|
|
|
|
|
| |
<rdar://problem/26256049>
llvm-svn: 269373
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
($T packets) for one \x03 interrupt. The problem was that when a \x03 byte is sent to debugserver while the process is running, and up calling:
rnb_err_t
RNBRemote::HandlePacket_stop_process (const char *p)
{
if (!DNBProcessInterrupt(m_ctx.ProcessID()))
HandlePacket_last_signal (NULL);
return rnb_success;
}
In the call to DNBProcessInterrupt we did:
nub_bool_t
DNBProcessInterrupt(nub_process_t pid)
{
MachProcessSP procSP;
if (GetProcessSP (pid, procSP))
return procSP->Interrupt();
return false;
}
This would always return false. It would cause HandlePacket_stop_process to always call "HandlePacket_last_signal (NULL);" which would send an extra stop reply packet _if_ the process is stopped. On a machine with enough cores, it would call DNBProcessInterrupt(...) and then HandlePacket_last_signal(NULL) so quickly that it will never send out an extra stop reply packet. But if the machine is slow enough or doesn't have enough cores, it could cause the call to HandlePacket_last_signal() to actually succeed and send an extra stop reply packet. This would cause problems up in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() where it would get the first stop reply packet and then possibly return or execute an async packet. If it returned, then the next packet that was sent will get the second stop reply as its response. If it executes an async packet, the async packet will get the wrong response.
To fix this I did the following:
1 - in debugserver, I fixed "bool MachProcess::Interrupt()" to return true if it sends the signal so we avoid sending the stop reply twice on slower machines
2 - Added a log line to RNBRemote::HandlePacket_stop_process() to say if we ever send an extra stop reply so we will see this in the darwin console output if this does happen
3 - Added response validators to StringExtractorGDBRemote so that we can verify some responses to some packets.
4 - Added validators to packets that often follow stop reply packets like the "m" packet for memory reads, JSON packets since "jThreadsInfo" is often sent immediately following a stop reply.
5 - Modified GDBRemoteCommunicationClient::SendPacketAndWaitForResponseNoLock() to validate responses. Any "StringExtractorGDBRemote &response" that contains a valid response verifier will verify the response and keep looking for correct responses up to 3 times. This will help us get back on track if we do get extra stop replies. If a StringExtractorGDBRemote does not have a response validator, it will accept any packet in response.
6 - In GDBRemoteCommunicationClient::SendPacketAndWaitForResponse we copy the response validator from the "response" argument over into m_async_response so that if we send the packet by interrupting the running process, we can validate the response we actually get in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse()
7 - Modified GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() to always check for an extra stop reply packet for 100ms when the process is interrupted. We were already doing this because we might interrupt a process with a \x03 packet, yet the process was in the process of stopping due to another reason. This race condition could cause an extra stop reply packet because the GDB remote protocol says if a \x03 packet is sent while the process is stopped, we should send a stop reply packet back. Now we always check for an extra stop reply packet when we manually interrupt a process.
The issue was showing up when our IDE would attempt to set a breakpoint while the process is running and this would happen:
--> \x03
<-- $T<stop reply 1>
--> z0,AAAAA,BB (set breakpoint)
<-- $T<stop reply 1> (incorrect extra stop reply packet)
--> c
<-- OK (response from z0 packet)
Now all packet traffic was off by one response. Since we now have a validator on the response for "z" packets, we do this:
--> \x03
<-- $T<stop reply 1>
--> z0,AAAAA,BB (set breakpoint)
<-- $T<stop reply 1> (Ignore this because this can't be the response to z0 packets)
<-- OK -- (we are back on track as this is a valid response to z0)
...
As time goes on we should add more packet validators.
<rdar://problem/22859505>
llvm-svn: 265086
|
|
|
|
| |
llvm-svn: 261768
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D16662
llvm-svn: 259098
|
|
|
|
|
|
|
|
|
|
|
|
| |
previous release. Most of the diffs are duplication in the xcode
project file caused by adding a "debugserver-mini" target. Jim
Ingham added support for a new SPI needed to request app launches
on iOS. Greg Clayton added code to indicate the platform of the
binary (macosx, ios, watchos, tvos) based on Mach-O load commands.
Jason Molenda added code so debugserver will identify when it is
running on a tvos/watchos device to lldb.
llvm-svn: 251091
|