| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
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
|
|
|
|
|
|
| |
Pointed out by Davide Italiano in post-commit review.
llvm-svn: 319935
|
|
|
|
|
|
|
| |
This fixes a few alignment problems pointed out by UBSan, and is
otherwise NFC.
llvm-svn: 319934
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: There are "FIXME"s in include/llvm/IR/DataLayout.h to remove the default arguments.
Reviewers: zturner, clayborg
Reviewed By: zturner
Subscribers: bjope
Differential Revision: https://reviews.llvm.org/D40064
llvm-svn: 319869
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
|
|
|
|
| |
llvm-svn: 319832
|
|
|
|
|
|
|
|
|
|
| |
Also add a test. There should also be control for this
in ProcessLaunchInfo and a "target launch" flag, but at least
this will allow you to control it somehow.
<rdar://problem/35842137>
llvm-svn: 319731
|
|
|
|
|
|
|
|
|
| |
I was warning about the fact that this will abort
further stop hooks, but didn't check that there WAS
a further stop hook. Also the warning was missing a
newline.
llvm-svn: 319730
|
|
|
|
| |
llvm-svn: 319694
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This flag is on by default for darwin and freebsd, but off for linux.
Without it, clang will sometimes not emit debug info for types like
std::string. Whether it does this, and which tests will fail because of
that depends on the linux distro and c++ library version.
A bunch of tests were already setting these flags manually, but here
instead I take a whole sale approach and enable this flag for all tests.
Any test which does not want to have this flag (right now we have one
such test) can turn it off explicitly via
CFLAGS_EXTRAS+=$(LIMIT_DEBUG_INFO_FLAGS)
This fixes a bunch of data formatter tests on red-hat.
Reviewers: davide, jankratochvil
Subscribers: emaste, aprantl, krytarowski, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D40717
llvm-svn: 319653
|
|
|
|
|
|
| |
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
|