| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
The long-term goal here is to get rid of the functions
GetArgumentAtIndex() and GetQuoteCharAtIndex(), instead
replacing them with operator based access and range-based for
enumeration. There are a lot of callsites, though, so the
changes will be done incrementally, starting with this one.
Differential Revision: https://reviews.llvm.org/D26883
llvm-svn: 287597
|
|
|
|
|
|
|
|
| |
This is to fix a regression in remote-linux lldb-server connections.
We were wrongly passing a copy of uri and expecting a stringRef back.
llvm-svn: 287542
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
32/64 bit elf core files
Summary:
The floating-point and SSE registers could be present in the elf-core
file in the note NT_FPREGSET for 64 bit ones, and in the note
NT_PRXFPREG for 32 bit ones.
The entire note is a binary blob matching the layout of the x87 save
area that gets generated by the FXSAVE instruction (see Intel developers
manual for more information).
This CL mainly modifies the RegisterRead function in
RegisterContextPOSIXCore_x86_64 for it to return the correct data both
for GPR and FPR/SSE registers, and return false (meaning "this register
is not available") for other registers.
I added a test to TestElfCore.py that tests reading FPR/SSE registers
both from a 32 and 64 bit elf-core file and I have inluded the source
which I used to generate the core files.
I tried to also add support for the AVX registers, because this info could
also be present in the elf-core file (note NT_X86_XSTATE - that is the result of
the newer XSAVE instruction). Parsing the contents from the file is
easy. The problem is that the ymm registers are split into two halves
and they are in different places in the note. For making this work one
would either make a "hacky" approach, because there won't be
any other way with the current state of the register contexts - they
assume that "this register is of size N and at offset M" and
don't have the notion of discontinuos registers.
Reviewers: labath
Subscribers: emaste, lldb-commits
Differential Revision: https://reviews.llvm.org/D26300
llvm-svn: 287506
|
|
|
|
| |
llvm-svn: 287412
|
|
|
|
| |
llvm-svn: 287409
|
|
|
|
|
|
| |
This patch updates a bunch of places where add_dependencies was being explicitly called to add dependencies on intrinsics_gen to instead use the DEPENDS named parameter. This cleanup is needed for a patch I'm working on to add a dependency debugging mode to the build system.
llvm-svn: 287408
|
|
|
|
| |
llvm-svn: 287401
|
|
|
|
|
|
|
|
| |
members of the community
That's All, Folks
llvm-svn: 287397
|
|
|
|
|
|
| |
Also document that it handles same, and add some tests.
llvm-svn: 287386
|
|
|
|
| |
llvm-svn: 287376
|
|
|
|
|
|
|
|
| |
This concludes the changes I originally tried to make and then
had to back out. This way if anything is still broken, it
should be easier to bisect it back to a more specific changeset.
llvm-svn: 287367
|
|
|
|
|
|
|
|
|
|
|
| |
The scanning algorithm had a few little subtleties that I
overlooked, but this patch should fix everything.
I still haven't changed the function to take a StringRef since
that has some trickle down effect and is mostly mechanical,
I just wanted to get the tricky part as isolated as possible.
llvm-svn: 287354
|
|
|
|
|
|
|
| |
This reverts commit r287315, as it introduces a bug that breaks
many things.
llvm-svn: 287320
|
|
|
|
|
|
|
|
|
|
| |
This argument was only used in one place in the codebase, and
it was in a non-critical log statement and can be easily
substituted for an equally meaningful field instead. The
payoff of computing this value is not worth the added
complexity.
llvm-svn: 287315
|
|
|
|
|
|
|
|
| |
Apparently these two enormous functions were dead. Which is
good, since one was largely a copy of another function with
only a few minor tweaks.
llvm-svn: 287308
|
|
|
|
|
|
|
|
|
| |
Originally I converted this entire function and all dependents
to use StringRef, but there were some test failures that
were tricky to track down, as this is a complicated function.
So I'm starting over, this time in smaller increments.
llvm-svn: 287307
|
|
|
|
|
|
|
| |
This resubmits r287279 with a fix for the original issue, which
was a trivial typo.
llvm-svn: 287282
|
|
|
|
|
|
|
| |
This reverts commit r287279, which breaks some register
tests on Linux.
llvm-svn: 287281
|
|
|
|
|
|
|
|
| |
In the process, found some functions that were duplicates of
existing StringRef member functions. So deleted those functions
and used the StringRef functions instead.
llvm-svn: 287279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix step-over when SymbolContext.function is missing and symbol is present.
With targets from our build configuration,
ThreadPlanStepOverRange::IsEquivalentContext fails to fire for relevant frames,
leading to ShouldStop() returning true prematurely.
The frame's SymbolContext, and m_addr_context have:
- comp_unit set and matching
- function = nullptr
- symbol set and matching (but this is never checked)
My naive guess is that the context should be equivalent in this case :-)
Reviewers: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D26804
llvm-svn: 287274
|
|
|
|
|
|
|
| |
This one is fairly trivial and only really involves changing
function signatures and a few simple call-sites.
llvm-svn: 287266
|
|
|
|
|
|
| |
All tests pass on Linux and Windows.
llvm-svn: 287259
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was a bit tricky, especially for things like
OptionValueArray and OptionValueDictionary since they do some
funky string parsing. Rather than try to re-write line-by-line
I tried to make the StringRef usage idiomatic, even though
it meant often re-writing from scratch large blocks of code
in a different way while keeping true to the original intent.
The finished code is a big improvement though, and often much
shorter than the original code. All tests and unit tests
pass on Windows and Linux.
llvm-svn: 287242
|
|
|
|
| |
llvm-svn: 287212
|
|
|
|
| |
llvm-svn: 287208
|
|
|
|
| |
llvm-svn: 287190
|
|
|
|
|
|
|
|
|
| |
Also significantly reduced the indentation level by use of
early returns, and simplified some of the logic by using
StringRef functions such as consumeInteger() and getAsInteger()
instead of strtoll, etc.
llvm-svn: 287189
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26721
llvm-svn: 287188
|
|
|
|
| |
llvm-svn: 287158
|
|
|
|
| |
llvm-svn: 287157
|
|
|
|
| |
llvm-svn: 287155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.
Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.
Differential Revision: https://reviews.llvm.org/D26698
llvm-svn: 287152
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the cross-platform minidump plugin working, the Windows-specific one is no longer needed. This eliminates the unnecessary code.
This does not eliminate the Windows-specific tests, as they hit a few cases the general tests don't. (The Windows-specific tests are currently passing.) I'll look into a separate patch to make sure we're not doing too much duplicate testing.
After that I might do a little re-org in the Windows plugin, as there was some factoring there (Common & Live) that probably isn't necessary anymore.
Differential Revision: https://reviews.llvm.org/D26697
llvm-svn: 287113
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
All usages have been replaced by appropriate std::chrono funcionality, and the
class is now unused. The only used part of the cpp file is the DumpTimePoint
function, which I have moved into the only caller (CommandObjectTarget.cpp).
Reviewers: clayborg, zturner
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D26451
llvm-svn: 287096
|
|
|
|
| |
llvm-svn: 287095
|
|
|
|
| |
llvm-svn: 287055
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26618
llvm-svn: 287017
|
|
|
|
| |
llvm-svn: 287016
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fix uninitialized members.
Reviewers: jingham
Subscribers: jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D26528
llvm-svn: 286947
|
|
|
|
|
|
|
|
|
|
|
|
| |
memory cache subsystem so we're reading only the 4 bytes
needed to check for the magic word at the start of a mach-o
binary instead of the default 512 block. It can be a small
performance help to reduce the size of memory reads from
possibly unmapped memory.
<rdar://problem/29256385>
llvm-svn: 286926
|
|
|
|
| |
llvm-svn: 286916
|
|
|
|
| |
llvm-svn: 286915
|
|
|
|
|
|
|
|
| |
On Windows, where we use Python 3 for testing, we have to be more explicit about converting between binary and string representations. I believe this should still work for Python 2, but I don't have a convenient way to try it out.
Differential Revision: https://reviews.llvm.org/D26643
llvm-svn: 286909
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
binary.
This was a regression that was caused by svn revision 269877:
commit 1ded4a2a25d60dd2c81bd432bcf63b6ded58e5d6
Author: Saleem Abdulrasool <compnerd@compnerd.org>
Date: Wed May 18 01:59:10 2016 +0000
remove use of Mutex in favour of std::{,recursive_}mutex
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@269877 91177308-0d34-0410-b5e6-96231b3b80d8
This change actually changed the Platform::m_mutex to be non-recursive which caused the regression.
<rdar://problem/29094384>
llvm-svn: 286908
|
|
|
|
| |
llvm-svn: 286906
|
|
|
|
|
|
|
|
|
|
| |
With this patch LLDB_VERSION_STRING replaces "lldb version x.x.x" if it is set. This allows builds to not display the open source version numbers if the people making the distribution overrides the LLDB_VERSION_STRING.
Since LLDB_VERSION_STRING is always overridden on Darwin, this means the first line of lldb -version on Darwin is:
lldb-360.99.0 (<repo path> revision <revision>)
llvm-svn: 286899
|
|
|
|
| |
llvm-svn: 286782
|
|
|
|
| |
llvm-svn: 286747
|
|
|
|
| |
llvm-svn: 286745
|
|
|
|
| |
llvm-svn: 286744
|