| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Formatting needs to be done only once. Ran check-lldb and nothing changes.
Reviewers: clayborg, davide
Reviewed By: clayborg, davide
Subscribers: zturner, davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D40519
llvm-svn: 319132
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This method doesn't modify anything in the object it's called on so we
can mark it const to make it usable in a const context.
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40517
llvm-svn: 319095
|
| |
|
|
|
|
|
|
| |
This was a temporary thing, until llvm has proper support for formatting
time. That time has come, so we can remove the relevant code. There
should be no change in the format of the time.
llvm-svn: 319048
|
| |
|
|
|
|
|
|
|
|
| |
New android ndk linker started adding more flags to the produced
binaries, which causes older dynamic linkers display warnings to stderr
about unsupported flags. This interferes with our stderr tests.
Extend the hasChattyStderr function to catch these targets as well.
llvm-svn: 319028
|
| |
|
|
|
|
|
|
| |
SetFileOffset.
Differential revision: https://reviews.llvm.org/D40458
llvm-svn: 318981
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We've had a single function responsible for splitting a core segment
into notes, and parsing the notes themselves, bearing in mind variations
between 4 supported OS types. This commit splits that code into 5
pieces:
- (os-independent) code for splitting a segment into individual notes
- per-os function for parsing the notes into thread information
Reviewers: clayborg, krytarowski, emaste, alexandreyy, kettenis
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40311
llvm-svn: 318903
|
| |
|
|
|
|
| |
I saw a bunch of style errors so this fixes them.
llvm-svn: 318886
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: labath, abidh, clayborg, ki.stfu
Reviewed By: labath, abidh, clayborg, ki.stfu
Subscribers: clayborg, ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D40022
llvm-svn: 318846
|
| |
|
|
| |
llvm-svn: 318833
|
| |
|
|
| |
llvm-svn: 318832
|
| |
|
|
|
|
|
|
| |
TargetOptions struct.
The Reciprocals field was moved to CodeGenOptions. I don't think lldb was really using this field so I'm just removing the mention.
llvm-svn: 318664
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D40216
llvm-svn: 318631
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D40211
llvm-svn: 318626
|
| |
|
|
| |
llvm-svn: 318580
|
| |
|
|
| |
llvm-svn: 318579
|
| |
|
|
| |
llvm-svn: 318577
|
| |
|
|
|
|
|
| |
This sketching can be resurrected if anybody needs it, although
I doubt is relevant these days.
llvm-svn: 318576
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
DWO/DWP should not be indexed directly.
Instead, the corresponding base file should be used.
This diff adds an assert to DWARFCompileUnit::Index
and adjusts the methods
SymbolFileDWARF::FindCompleteObjCDefinitionTypeForDIE,
SymbolFileDWARF::GetObjCMethodDIEOffsets accordingly.
Differential revision: https://reviews.llvm.org/D39825
llvm-svn: 318554
|
| |
|
|
|
|
| |
It was broken by r318489.
llvm-svn: 318504
|
| |
|
|
| |
llvm-svn: 318500
|
| |
|
|
|
|
| |
<rdar://problem/32505028>
llvm-svn: 318496
|
| |
|
|
|
|
|
|
| |
The parameters were just passed in the wrong order.
<rdar://problem/35150446>
llvm-svn: 318495
|
| |
|
|
|
|
| |
way to just dump the compile unit full paths and optionally their support files with the new "dump-files"command.
llvm-svn: 318424
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Implement core dump debugging for PPC64le.
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere, krytarowski, clayborg, labath, lbianc, nemanjai, gut, anajuliapc, mgorny, kbarton, lldb-commits
Differential Revision: https://reviews.llvm.org/D39681
Patch by Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br>
llvm-svn: 318399
|
| |
|
|
|
|
|
|
|
|
| |
so it has the same padding as the kernel's definition
which is written in terms of uint128_t. Original patch
by Ryan Mansfield.
<rdar://problem/35468499>
llvm-svn: 318357
|
| |
|
|
| |
llvm-svn: 318348
|
| |
|
|
|
|
|
|
|
|
| |
break. The alignas(__uint128_t) is not recognized with MSVC
it looks like. Zachary, is there a similar type on windows?
I suppose I can go with alignas(16) here but I'd prefer to
specify the type alignment that I want & let the ABI dictate
how much padding is required.
llvm-svn: 318262
|
| |
|
|
|
|
|
|
|
| |
a Mach-O file load command correctly, patch by Ryan
Mansfield.
<rdar://problem/35468499>
llvm-svn: 318260
|
| |
|
|
|
|
| |
move and LibCxxBitset.cpp addition.
llvm-svn: 318218
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D39578
llvm-svn: 318164
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: jingham, EricWF
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D39966
llvm-svn: 318145
|
| |
|
|
| |
llvm-svn: 318079
|
| |
|
|
| |
llvm-svn: 318052
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The rationale here is that ArchSpec is used throughout the codebase,
including in places which should not depend on the rest of the code in
the Core module.
This commit touches many files, but most of it is just renaming of
#include lines. In a couple of cases, I removed the #include ArchSpec
line altogether, as the file was not using it. In one or two places,
this necessitated adding other #includes like lldb-private-defines.h.
llvm-svn: 318048
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In D39387, I was quick to jump to conclusion that ArchSpec has no
external dependencies. It turns there still was one call to
HostInfo::GetArchitecture left -- for implementing the "systemArch32"
architecture and friends.
Since GetAugmentedArchSpec is the place we handle these "incomplete"
triples that don't specify os or vendor and "systemArch" looks very much
like an incomplete triple, I move its handling there.
After this ArchSpec *really* does not have external dependencies, and
I'll move it to the Utility module as a follow-up.
Reviewers: zturner, clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39896
llvm-svn: 318046
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Despite it's name, GetTemplateArgument was only really working for Type
template arguments. This adds the ability to retrieve integral arguments
as well (which I've needed for the std::bitset data formatter).
I've done this by splitting the function into three pieces. The idea is
that one first calls GetTemplateArgumentKind (first function) to
determine the what kind of a parameter this is. Based on that, one can
then use specialized functions to retrieve the correct value. Currently,
I only implement two of these: GetTypeTemplateArgument and
GetIntegralTemplateArgument.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39844
llvm-svn: 318040
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
JIT for LLDB"
This commit really did not introduce any functional changes (for most
people) but it turns out it's not for the reason we thought it was.
The reason wasn't that Orc is a perfect drop-in replacement for MCJIT,
but it was because we were never using Orc in the first place, as it was
not initialized.
Orc's initialization relies on a global constructor in the LLVMOrcJIT.a.
Since this archive does not expose any symbols referenced from other
object files, it does not get linked into liblldb when linking against
llvm components statically. However, in an LLVM_LINK_LLVM_DYLIB=On
build, LLVMOrcJit.a is linked into libLLVM.so using --whole-archive, so
the global constructor does end up firing.
The result of using Orc jit is pr34194, where lldb fails to evaluate
even very simple expressions. This bug can be reproduced in
non-LLVM_LINK_LLVM_DYLIB builds by making sure Orc jit is linked into
liblldb, for example by #including
llvm/ExecutionEngine/OrcMCJITReplacement.h in IRExecutionUnit.cpp (and
adding OrcJIT as a dependency to the relevant CMakeLists.txt file). The
bug reproduces (at least) on linux and osx.
The root cause of the bug seems to be related to relocation processing.
It seems Orc processes relocations earlier than the system it is
replacing. This means the relocation processing happens before we have
had a chance to remap section load addresses to reflect their address in
the target process memory, so they end up pointing to locations in the
lldb's address space instead.
I am not sure whether this is a bug in Orc jit, or in how we are using
it from lldb, but in any case it is preventing us from using Orc right
now. Reverting this fixes LLVM_LINK_LLVM_DYLIB build, and makes it clear
that we are in fact *not* using Orc, and we never really were.
This reverts commit r279327.
llvm-svn: 318039
|
| |
|
|
|
|
| |
debug info.
llvm-svn: 317945
|
| |
|
|
|
|
|
|
|
|
| |
FindCompleteObjCDefinitionType is not used anywhere and there is no implementation of it, only a declaration.
Test plan: make check-lldb
Differential revision: https://reviews.llvm.org/D39884
llvm-svn: 317919
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit removes the concrete_frame_idx member from
NativeRegisterContext and related functions, which was always set to
zero and never used.
I also change the native thread class to store a NativeRegisterContext
as a unique_ptr (documenting the ownership) and make sure it is always
initialized (most of the code was already blindly dereferencing the
register context pointer, assuming it would always be present -- this
makes its treatment consistent).
Reviewers: eugene, clayborg, krytarowski
Subscribers: aemerson, sdardis, nemanjai, javed.absar, arichardson, kristof.beyls, kbarton, uweigand, alexandreyy, lldb-commits
Differential Revision: https://reviews.llvm.org/D39837
llvm-svn: 317881
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These tests used to log the error message and return plain bool mainly
because at the time they we written, we did not have a nice way to
assert on llvm::Error values. That is no longer true, so replace this
pattern with a more idiomatic approach.
As a part of this patch, I also move the formatting of
GDBRemoteCommunication::PacketResult values out of the test code, as
that can be useful elsewhere.
Reviewers: zturner, eugene
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D39790
llvm-svn: 317795
|
| |
|
|
|
|
|
| |
I am planning to make changes to this piece of code, so I wrote this
test to add more coverage to it first.
llvm-svn: 317792
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These functions used to return bool to signify whether they were able to
retrieve the data. This is redundant because the ArchSpec and ByteOrder
already have their own "invalid" states, *and* because both of the
current implementations (linux, netbsd) can always provide a valid
result.
This allows us to simplify bits of the code handling these values.
Reviewers: eugene, krytarowski
Subscribers: javed.absar, lldb-commits
Differential Revision: https://reviews.llvm.org/D39733
llvm-svn: 317779
|
| |
|
|
|
|
|
| |
r317561 exposed an interesting bug (pr35228) in handling of simultaneous
watchpoint hits. Disabling the test until we can get that fixed.
llvm-svn: 317683
|
| |
|
|
|
|
|
|
|
|
| |
The thread name was not followed by a space, which meant it was glued to
the log message. I also align the name as we do that with other log
fields. I align it to 16 chars instead of llvm::max_thread_name(), as
that can be 64 on darwin, which is rather long. If anybody feels
differently about that, we can change it.
llvm-svn: 317679
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This test was failing in various configurations on linux in a fairly
unpredictible way. The success depended on whether the c++ abi library
was linked in statically or not and how well was the linker able to
strip parts of it. This introduces additional code to the "dummmy" test
executable, which ensures that all parts of the library needed to
evaluate the expressions are always present.
Reviewers: clayborg
Subscribers: srhines, tatyana-krasnukha, davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D39727
llvm-svn: 317678
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A couple of members of these data structures have been renamed in recent
months. This makes sure they still work with the latest libc++ version.
Reviewers: jingham, EricWF
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39602
llvm-svn: 317624
|
| |
|
|
| |
llvm-svn: 317574
|
| |
|
|
|
|
|
|
| |
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D39545
llvm-svn: 317563
|
| |
|
|
|
|
|
| |
We only support API>=16 now, so we don't need to check the API level of
the android device.
llvm-svn: 317562
|