| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When reading DBGSourcePathRemapping from a dSYM, we remove the last two
path components to make the source lookup more general. However, when
dealing with a relative path that has less than 2 components, we ended
up with an invalid (empty) FileSpec.
This patch changes the behavior of removeLastPathComponent to remove the
last path component, if possible. It does this by checking whether a
parent path exists, and if so using that as the new path. We rely
entirely on LLVM's path implementation to do the heavy lifting.
We now also return a boolean which indicates whether the operator was
successful or not.
Differential revision: https://reviews.llvm.org/D47495
rdar://37791687
llvm-svn: 333540
|
|
|
|
| |
llvm-svn: 333526
|
|
|
|
|
|
| |
This is a leftover regression from: https://reviews.llvm.org/D46810
llvm-svn: 333517
|
|
|
|
|
|
| |
See https://reviews.llvm.org/rL303907 for details about the bug.
llvm-svn: 333478
|
|
|
|
|
|
|
|
|
| |
Not strictly necessary, but makes the test more robust in case
we end up changing the defaults.
<rdar://problem/40622096>
llvm-svn: 333466
|
|
|
|
|
|
|
|
| |
While I'm here, delete some dead code.
<rdar://problem/40622096>
llvm-svn: 333465
|
|
|
|
|
|
|
| |
It was not implemented correctly after https://reviews.llvm.org/D46810 but then
it has not been used anywhere anyway.
llvm-svn: 333452
|
|
|
|
|
|
| |
Alex Langford has reported it from: https://reviews.llvm.org/D46810
llvm-svn: 333449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Generating LLDB.framework when building with CMake+Ninja will copy the
lldb-private headers because public_headers contains them, even though we try
to make sure they don't get copied by removing root_private_headers from
root_public_headers.
This patch also removes SystemInitializerFull.h from the LLDB.framework headers when building with CMake.
Reviewers: compnerd, sas, labath, beanz, zturner
Reviewed By: labath
Subscribers: clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47278
llvm-svn: 333444
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GetUnitDIEPtrOnly() needs to return pointer to the first DIE.
But the first element of m_die_array after ExtractDIEsIfNeeded(true)
may move in memory after later ExtractDIEsIfNeeded(false).
DWARFDebugInfoEntry::collection m_die_array is std::vector,
its data may move during its expansion.
Differential revision: https://reviews.llvm.org/D46810
llvm-svn: 333437
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The lldb test suite is highly configurable. While part of this
configuration takes place at configure/build-time, a common scenario
involves running the test suite several times with different
configuration. For example, we might want to test the current lldb
against inferiors built with different compilers.
This configuration was already possible for lldb-dotest, but was lacking
for the lit counterpart. It is now possible to pass arguments to pass
arguments like this:
./bin/llvm-lit ../llvm/tools/lldb/lit/Suite/ -Ddotest-args="-foo;-bar"
llvm-svn: 333432
|
|
|
|
|
|
|
|
|
|
| |
The framework argument was broken when I removed the generator
expressions upstream. I replaced $<TARGET_FILE_DIR:liblldb> with
${LLVM_LIBRARY_OUTPUT_INTDIR}) which is not correct.
rdar://40534649
llvm-svn: 333412
|
|
|
|
|
|
|
|
| |
It's been failing since I enabled the test for non-darwin targets. I
made it reference the same bug as the linux core, as it's likely that
the root cause is the same.
llvm-svn: 333401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This improves the process of cross-compiling from macOS to Linux
since these files aren't used / needed at all.
Reviewers: clayborg, labath
Subscribers: lldb-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D47420
llvm-svn: 333400
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: javed.absar
Subscribers: ki.stfu, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D47421
llvm-svn: 333399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
same way
Summary:
We were treating subprograms and inlined subroutines differently when
building the index. The difference was in which indexes were individual
tags inserted (subprograms went to all indexes, where as inlined
subroutines only into the basename and full name indexes).
This seems like an error, because an inlined subroutine can still
represent an C++ or an ObjC method. I don't see anything in the
subprogram branch which should not apply to an inlined subroutine, so I
propose to just treat them identically. This makes searching for an
inlined method behave the same way as for the apple index.
I write an assembly-based test because I did not want to depend on
particular clang inlining behavior (and because I wanted to see how hard
would it be).
Reviewers: clayborg, JDevlieghere
Subscribers: eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D47368
llvm-svn: 333398
|
|
|
|
| |
llvm-svn: 333364
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
FastDemangle gives us a C-string that we own (which is allocated in SymbolDemangler::GetDemangledCopy).
As we are not deleting the string, we leak memory whenever we call SubsPrimitiveParmItanium.
Reviewers: javed.absar
Subscribers: kristof.beyls, chrib, lldb-commits
Differential Revision: https://reviews.llvm.org/D47418
llvm-svn: 333353
|
|
|
|
|
|
|
|
|
|
| |
Summary: When compiling with modules, these missing includes cause the build to fail (as the header can't be compiled into a module).
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D47412
llvm-svn: 333345
|
|
|
|
|
|
|
|
| |
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D47410
llvm-svn: 333343
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This resolves unnecessary the header dependency from
Core to DataFormatters. Patch is necessary for the introduction of
C++ modules to the LLDB build system.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47409
llvm-svn: 333342
|
|
|
|
| |
llvm-svn: 333322
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It seems to me that files in include/lldb/API/ are headers that should
be exposed to liblldb users. Because SystemInitializerFull.h exposes details of
lldb_private, I think having it there is not the right thing to do. Since it's
only included from files in source/API, we should move it there and treat it as
private.
Reviewers: labath, clayborg
Reviewed By: labath, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47342
llvm-svn: 333304
|
|
|
|
| |
llvm-svn: 333299
|
|
|
|
|
|
|
| |
It has been now always passed as true and during planned D46810 it would no
longer make sense.
llvm-svn: 333287
|
|
|
|
|
|
|
| |
PRIx64 already has the x inside, so this was creating a nonsensical format
string.
llvm-svn: 333273
|
|
|
|
|
|
|
| |
Apple index was already treating them as methods. Not doing the same
seems like an omission.
llvm-svn: 333266
|
|
|
|
|
|
|
|
|
| |
Several functions were passing a list of 8 NameToDIE arguments around.
This puts those variables in a struct and passes that instead, reducing
code duplication and the possibility of error (swapping two arguments
accidentally).
llvm-svn: 333264
|
|
|
|
|
|
| |
rdar://problem/40537961
llvm-svn: 333248
|
|
|
|
|
|
| |
This should unbreak the green dragon bot builds.
llvm-svn: 333238
|
|
|
|
|
|
|
|
|
| |
As suggested by Pavel Labath in D46810 DWARFUnit::GetUnitDIEOnly() returning
a pointer to m_first_die should not permit using methods like GetFirstChild().
Differential revision: https://reviews.llvm.org/D47276
llvm-svn: 333224
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new DWARFBaseDIE is going to be used for DWARFUnit::GetUnitDIEOnly() as
other DIEs are unavailable that time so the caller should not have methods
available to access them.
This patch is only a mechanical split without any use of it.
Differential revision: https://reviews.llvm.org/D47275
llvm-svn: 333222
|
|
|
|
| |
llvm-svn: 333208
|
|
|
|
|
|
| |
This should unbreak the xcode build.
llvm-svn: 333207
|
|
|
|
|
|
|
|
|
|
|
| |
Now it's possible to set breakpoints before selecting a target, they
will be set to the dummy target and then copied to an each added one.
Patch by Alexander Polyakov!
Differential Revision: https://reviews.llvm.org/D46588
llvm-svn: 333205
|
|
|
|
|
|
|
| |
I should've known that something was wrong when only one of my plugins
was prefixed by the lldb_private namespace.
llvm-svn: 333183
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For lldb-server, it is sufficient to parse only the native object file
format for its target OS (no other file can be loaded into a running
process). This moves the object file initialization code into specific
initializer classes: lldb-test and liblldb get all object files;
lldb-server gets only one of them. For this to work, I've needed to
create a special SystemInitializer for use in lldb-server, instead of it
calling directly into the common one.
This reduces the size of lldb-server by about 2%, which is not
earth-shattering, but it's an easy win, and it helps.
Reviewers: zturner, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47250
llvm-svn: 333182
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I think this makes sense for several reasons:
- better separation of concerns: DWARFUnit's job should be to provide a
nice interface to its users to access the unit contents.
ManualDWARFIndex can then use this interface to build an index and
provide it to its users.
- closer alignment with llvm parsers: there is no indexing equivalent in
llvm, and there probably never will be, as the index is very centered
around how lldb wants to access debug info. If we ever switch to
llvm's parser, this will allow us swap out DWARFUnit implementations
and keep indexing as-is.
- closer proximity of the indexing code to AppleDWARFIndex will make it
easier to keep the two in sync (e.g. right now the two use very
different algorithms to determine whether a DW_TAG_subroutine
represents a "method"). This is my primary motivation for making this
change now, but I am leaving this work to a separate patch.
The only interface change to DWARFUnit I needed to make was to add an
efficient way to iterate over the list of all DIEs. Adding this also
aligns us closer to the llvm parser.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47253
llvm-svn: 333178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add PPC64le support information on LLDB site
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: labath, lldb-commits, lbianc, clayborg
Differential Revision: https://reviews.llvm.org/D47285
Patch by Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br>.
llvm-svn: 333173
|
|
|
|
| |
llvm-svn: 333151
|
|
|
|
| |
llvm-svn: 333145
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only reason this was here was so that Module could have a
function called CreateJITModule which created things in a special
order. Instead of making this specific to creating JIT modules,
I converted this into a template function that can create a module
for any type of object file plugin and just forwards arguments
through. Since the template is not instantiated in Core, the linker
(and header file) dependency moves to the point where it is
instantiated, which only happens in Expression. Conceptually, this
location also makes more sense for a dependency on ObjectFileJIT.
After all, we JIT expressions so it's no surprise that Expression
needs to make use of ObjectFileJIT.
Differential Revision: https://reviews.llvm.org/D47228
llvm-svn: 333143
|
|
|
|
|
|
|
|
| |
Patch by Alexander Polyakov!
Differential Revision: https://reviews.llvm.org/D47110
llvm-svn: 333140
|
|
|
|
|
|
|
| |
These checks do absolutely nothing other than cause a library layering
violation in the code.
llvm-svn: 333134
|
|
|
|
|
|
|
|
|
|
| |
The tests added in r332842 don't work on windows, because they do path
comparisons on strings, and on windows, the paths coming out of the
mappings had backslashes in them.
This switches comparisons to FileSpecs, so the results come out right.
llvm-svn: 333074
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This call was originally being only made when launching for debug (as an
attempt to make sure we don't impart extra privileges on the launched
process), but after the debug and non-debug paths were merged, it made
it's way into generic code. This was causing problems in locked down
android environments which disallowed calling setgid even if it would be
a no-op. This prevented launching llgs from lldb-server platform.
Overall I'm not sure we should be calling setgid in the first place
(it seems random -- e.g. why don't we call setuid then as well).
However, all our other copies of launch code have it, so I choose to
keep it for now.
llvm-svn: 333073
|
|
|
|
| |
llvm-svn: 333055
|
|
|
|
|
|
|
|
| |
The wchar_t is unsigned.
https://msdn.microsoft.com/en-us/library/s3f49ktz.aspx
llvm-svn: 333051
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Implement FindGlobalVariables and ParseVariableContext methods.
Compile unit information is necessary for resolving variable context, however some PDB symbols do not have this information. For now an empty DWARFExpression is used to construct a lldb::Variable instance with the limitation that using lldb to lookup the value of a global or local variable is not available.
This commit may slow down lit/SymbolFile/PDB/compilands.test since the test includes MS specific modules that spend more time parsing variables.
Reviewers: rnk, zturner, lldb-commits
Subscribers: aprantl, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D45224
llvm-svn: 333049
|
|
|
|
|
|
|
|
| |
Use proper cmake techniques to detect where the libedit package resides.
This allows for the use of libedit from an alternative location which is
needed for supporting cross-compilation.
llvm-svn: 333041
|