| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D40745
llvm-svn: 319599
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLDB.framework gets loaded into Xcode and other
frameworks, and this is inserting a signal handler into
the process even when lldb isn't used. I have a bunch
of reports of this SignalHandler blowing out the stack,
which renders crash reports for the crash useless.
And in any case libraries really shouldn't be installing
signal handlers.
I only turned this off for APPLE platforms, I'll let
the maintainers of other platforms decide what policy
they want to have w.r.t. this.
llvm-svn: 319598
|
|
|
|
| |
llvm-svn: 319597
|
|
|
|
|
|
| |
These asserts are no-ops, and are supplanted by -Wcovered-switch.
llvm-svn: 319596
|
|
|
|
| |
llvm-svn: 319595
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have found LLDB commonly looks up lldb::user_id_t 0xffffffff failing to find
its DIE. One would rather expect LLDB_INVALID_UID == 0xffffffffffffffff in such
case.
DWARFASTParserClang.cpp:495
492 type_sp.reset(
493 new Type(die.GetID(), dwarf, type_name_const_str, byte_size, NULL,
494 DIERef(encoding_uid).GetUID(dwarf), encoding_data_type,
495 &decl, clang_type, resolve_state));
encoding_uid = (DWARFFormValue) {m_cu = 0x0, m_form = 0, m_value = {value = {uval = 0, sval = 0, cstr = 0x0}, data = 0x0}}
-> DIERef::DIERef(const DWARFFormValue &form_value = {m_cu = 0x0, m_form = 0, m_value = {value = {uval = 0, sval = 0, cstr = 0x0}, data = 0x0}})
-> (DIERef) {cu_offset = 0xffffffff, die_offset = 0xffffffff}
-> lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf = 0x61d00000b480) const
-> Type::Type(lldb::user_id_t encoding_uid = 0xffffffff)
But 0xffffffff !=
#define LLDB_INVALID_UID UINT64_MAX
Differential revision: https://reviews.llvm.org/D37492
llvm-svn: 319580
|
|
|
|
|
|
|
|
|
|
|
| |
struct iovec is used as an interface to system (posix) api's. As such,
we shouldn't be using it in os-independent code, and we shouldn't be
defining our own iovec replacements.
Fortunately, its usage was not very widespread, so the removal was very
easy -- I simply moved a couple declarations into os-specific code.
llvm-svn: 319536
|
|
|
|
|
|
|
|
|
| |
When it does, it returns a NULL ClassTemplateDecl. Don't use
it if it is NULL...
<rdar://problem/35672107>
llvm-svn: 319516
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is basically a proof-of-concept and starting point for having a
testing-centric tool in LLDB. I'm sure this leaves a lot of room to be
desired, but this at least allows us to have something to build on.
Right now there is only one command, the `module-sections` command, and I
created this command not because it was particularly special, but
because it addressed an immediate use case and was extremely simple.
Run the tool as `lldb-test module-sections <path-to-object>`.
Feel free to add testing related stuff to your heart's content after
this goes in. Implementing the commands themselves takes some work, but
once they're there they can be reused without writing any code and
result in very easy to use and maintain tests.
Differential Revision: https://reviews.llvm.org/D40636
llvm-svn: 319504
|
|
|
|
|
|
|
|
|
|
|
|
| |
but still listed in the kernel's kext table with the kernel
binary UUID. This resulted in the kernel text section being
loaded at the kext address and problems ensuing. Instead,
if there is a kext with the same UUID as the kernel, lldb
should skip over it.
<rdar://problem/35757689>
llvm-svn: 319500
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Move TaskPool into the namespace lldb_private.
2. Add missing std::move in TaskPoolImpl::Worker.
3. std::thread::hardware_concurrency may return 0,
handle this case correctly.
Differential revision: https://reviews.llvm.org/D40587
Test plan: make check-all
llvm-svn: 319492
|
|
|
|
|
|
|
|
| |
unambiguously on one bit of code. On macOS these
lines mapped to two distinct locations, and that
was artificially throwing off the test.
llvm-svn: 319472
|
|
|
|
| |
llvm-svn: 319454
|
|
|
|
|
|
|
| |
The test is about failing to hit breakpoints in global constructors in
shared libraries.
llvm-svn: 319443
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
llvm::APSInt(0) asserts because it creates an int with bit-width 0 and
not (as I thought) a value 0.
Theoretically it should be sufficient to change this to APSInt(1), as
the intention there was that the value of the first argument should be
ignored if the type is invalid, but that would look dodgy.
Instead, I use llvm::Optional to denote an invalid value and use a
special struct instead of a std::pair, to reduce typing and increase
clarity.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40615
llvm-svn: 319414
|
|
|
|
|
|
|
|
| |
Forgotten small simplification in D40212.
Differential revision: https://reviews.llvm.org/D40635
llvm-svn: 319402
|
|
|
|
|
|
| |
<rdar://problem/35562389>
llvm-svn: 319389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
initializers + Extract()
It has no functionality effect.
I was concerned about the worse performance of DWARFDebugInfo::Parse this way
of allocating+destroying a CU for each iteration but I see it is now used only
by DWARFDebugInfo::Dump so that is no longer a problem.
Differential revision: https://reviews.llvm.org/D40212
llvm-svn: 319359
|
|
|
|
| |
llvm-svn: 319226
|
|
|
|
| |
llvm-svn: 319213
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This remove a small amount of duplicated code.
Reviewers: clayborg, zturner, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40536
llvm-svn: 319191
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In https://reviews.llvm.org/D39681, we started using a map instead
passing a long list of register sets to the ppc64le register context.
However, existing register contexts were still using the old method.
This converts the remaining register contexts to use this approach.
While doing that, I've had to modify the approach a bit:
- the general purpose register set is still kept as a separate field,
because this one is always present, and it's parsing is somewhat
different than that of other register sets.
- since the same register sets have different IDs on different operating
systems, but we use the same register context class to represent
different register sets, I've needed to add a layer of indirection to
translate os-specific constants (e.g. NETBSD::NT_AMD64_FPREGS) into more
generic terms (e.g. floating point register set).
While slightly more complicated, this setup allows for better separation
of concerns. The parsing code in ProcessElfCore can focus on parsing
OS-specific core file notes, and can completely ignore
architecture-specific register sets (by just storing any unrecognised
notes in a map). These notes will then be passed on to the
architecture-specific register context, which can just deal with
architecture specifics, because the OS-specific note types are hidden in
a register set description map.
This way, adding an register set, which is already supported on other
OSes, to a new OS, should in most cases be as simple as adding a new
entry into the register set description map.
Differential Revision: https://reviews.llvm.org/D40133
llvm-svn: 319162
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
New linux kernels (on systems that support the XSAVES instruction) will
not update the inferior registers unless the corresponding flag in the
XSAVE header is set. Normally this flag will be set in our image of the
XSAVE area (since we obtained it from the kernel), but if the inferior
has never used the corresponding register set, the respective flag can
be clear.
This fixes the issue by making sure we explicitly set the flags
corresponding to the registers we modify. I don't try to precisely match
the flags to set on each write, as the rules could get quite complicated
-- I use a simpler over-approximation instead.
This was already caught by test_fp_register_write, but that was only
because the code that ran before main() did not use some of the register
sets. Since nothing in this test relies on being stopped in main(), I
modify the test to stop at the entry point instead, so we can be sure
the inferior did not have a chance to access these registers.
Reviewers: clayborg, valentinagiusti
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40434
llvm-svn: 319161
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|