| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
COFF files are modelled in lldb as having one big container section
spanning the entire module image, with the actual sections being
subsections of that. In this model, the base address is simply the
address of the first byte of that section.
This also removes the hack where ObjectFilePECOFF was using the
m_file_offset field to communicate this information. Using file offset
for this purpose is completely wrong, as that is supposed to indicate
where is this ObjectFile located in the file on disk. This field is only
meaningful for fat binaries, and should normally be 0.
Both PDB plugins have been updated to use GetBaseAddress instead of
GetFileOffset.
llvm-svn: 354258
|
|
|
|
| |
llvm-svn: 354256
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The policy is about cmake_include_files ignoring
CMAKE_REQUIRED_LIBRARIES in the OLD behavior. Llvm already sets this
policy to NEW, but that is overridden by our cmake_minimum_required
command.
This makes our cmake policy setup consistent with the llvm build files
and avoids a warning when using newer versions of cmake.
Reviewers: sgraenitz, xiaobai
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D58279
llvm-svn: 354251
|
|
|
|
| |
llvm-svn: 354225
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D57817
llvm-svn: 354206
|
|
|
|
| |
llvm-svn: 354204
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The compilation of the TestDataFormatterLibcxxListLoop.py currently fails with this error:
```
functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/main.cpp:19:24: error: no member named '__value_' in 'std::__1::__list_node_base<int, void *>'
assert(third_elem->__value_ == 3);
~~~~~~~~~~ ^
```
It seems the internal structure of list has changed with the 3.8 release. This patch makes the test compile with the current libc++ and with the previous libc++.
Reviewers: shafik, zturner, labath
Reviewed By: labath
Subscribers: christof, jdoerfert, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D58273
llvm-svn: 354202
|
|
|
|
|
|
|
|
|
| |
test/lang/cpp/class-template-parameter-pack/TestClassTemplateParameterPack.py
It fails on Mac OS; apparently a VarDecl 'void *&C' is implicitly
declared there, making the class template name C ambiguous.
llvm-svn: 354185
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to a process so we'll always get messages in the console logs.
Also make the "is frontboard process" / "is backboard process"
determination lazy, specifically take it out of the
MachProcess::AttachForDebug codepath when we are attaching to a
process, to simplify attaching.
<rdar://problem/47982516>
<rdar://problem/48060134>
llvm-svn: 354181
|
|
|
|
|
|
| |
It broke the modules green dragon buildbot.
llvm-svn: 354177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
class template back to the template.
Previously, when the ASTImporter imported the class, it didn't know that
it was the pattern of a class template, so made the class a name lookup
result for the name of the template, resulting in ambiguity errors when
naming the template.
Due to a clang bug (fixed in r354091, reverted and soon to be
re-committed), ambiguity errors between a template and a non-template
were previously not diagnosed. Once r354091 is re-committed, this will
be covered by existing lldb tests.
llvm-svn: 354173
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit modifies the OnLoadModule method to resolve the module
unless we already have one
Change by Hui Huang to fix the failing LLDB tests on Windows
Reviewers: labath, asmith
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D58303
llvm-svn: 354172
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Host had a function to get the UnixSignals instance corresponding
to the current host architecture. This means that Host had to
include a file from Target. To break this dependency, just make
this a static function directly in UnixSignals. We already have
the function UnixSignals::Create(ArchSpec) anyway, so we just
need to have UnixSignals::CreateForHost() which determines which
value to pass for the ArchSpec.
The goal here is to eventually break the Host->Target->Host
circular dependency.
Differential Revision: https://reviews.llvm.org/D57780
llvm-svn: 354168
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ExecControl/StopHook/stop-hook-threads.test is flaky on Linux (it's
consistently failing on my machine, but doesn't fail on a co-worker's).
I'm seeing the following assertion failure:
```
CommandObject.cpp:145: bool lldb_private::CommandObject::CheckRequirements(lldb_private::CommandReturnObject&): Assertion `m_exe_ctx.GetTargetPtr() == NULL' failed.
```
Interestingly, this doesn't happen when typing the same commands in
interactive mode. The cause seems to be that, in synchronous execution
mode continue waits until the process stops again, and that includes
running any stop-hooks for that later stop, so we end with a stack trace
like this (lots of frames omitted for clarity):
```
abort()
CommandObject::CheckRequirements() <-- this is again the same instance of CommandObjectProcessContinue, fails assertion because the previous continue command hasn't finished.
Target::RunStopHooks()
CommandObjectProcessContinue::DoExecute()
Target::RunStopHooks()
```
In general, it seems like using process control commands inside
stop-hooks does not have very well defined semantics. You don't even
need multiple threads to make that assertion fail, you can build
```
int main() {
printf("1\n"); // break1
printf("2\n"); // break2
}
```
and then on lldb
```
target stop-hook add -o continue
break set -f stop-hook-simple.cpp -p "break1"
break set -f stop-hook-simple.cpp -p "break2"
run
```
In this case it's even worse because the presence of multiple threads
makes it prone to race conditions. In some tests I ran with a simpler
version of this test case, I was hitting either the previous assertion
failure or the following issue:
1. Two threads reach a breakpoint
2. First stop-hook does a process continue
3. Threads end
4. Second stop-hook runs, complains about process not existing.
This change disables the test on Linux. It's already marked as XFAIL on
Windows, so maybe we should just delete it until it's clear what should
be the expected behavior in these cases. Or maybe try to come up with a
way to write a similar multithreaded test without calling continue from
a stop hook, I don't know.
Differential Revision: https://reviews.llvm.org/D58257
llvm-svn: 354149
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: As seen in a crash report, the C-string returned for the directory component of `target_file` can null. It should not be assigned to `std::string` directly as this is undefined behavior.
Reviewers: jingham
Reviewed By: jingham
Subscribers: jdoerfert, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D57964
llvm-svn: 354145
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I reduced the alignment of this struct in r342029 to avoid compiler
warnings about under-aligned allocations, but it turns out that this
still causes problems with some compilers (see r353778). As I hinted in
r342029, I don't believe any special aligment is necessary here (the
only reason for that would be if we used some aligned SSE instructions to
access this buffer, but I don't see any reason why we should do that),
so here I go all the way, and remove the alignment requirements (except
the ones naturally imposed by basic types) altogether.
llvm-svn: 354125
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add missing EINTR handling for kevent() calls. If the call is
interrupted, return from Poll() as if zero events were returned and let
the polling resume on next iteration. This fixes test flakiness
on NetBSD.
Includes a test case suggested by Pavel Labath on D42206.
Differential Revision: https://reviews.llvm.org/D58230
llvm-svn: 354122
|
|
|
|
|
|
|
|
|
|
| |
This applies the same fix that was done in r354106 to the lldb-server
test: bitcasting the string to a bytes object before sending it over a
socket. Since the gdb-remote protocol occasionally contains binary data,
and it does not assign any particular encoding to them, this is the
right thing to do here.
llvm-svn: 354114
|
|
|
|
| |
llvm-svn: 354112
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch finishes the python3-ification of the lldb-server test suite.
It reverts the partial attempt in r352709 to encode/decode the string
via utf8 before writing to the socket. This wasn't enough because the
gdb-remote protocol can sometimes (but not very often) carry binary
data, and the utf8 codec chokes on that. Instead I add utility functions
to the "seven" module for performing "identity" transformations on the
byte data. This basically drills back the hole in the python type system
that the string/bytes distinction was supposed to plug. That is not
ideal, but was the best solution of the alternatives I could come up
with. The options I considered were:
- make use of the type system to add type safety to the test suite: This
required making a lot of changes to the test suite, since most of the
strings would now become byte objects instead, and it was not even
fully clear to me where to draw the line. One extreme solution would
be to just use byte objects everywhere, as the protocol doesn't
support non-ascii characters anyway. However, this appeared to be:
a) weird, because most of the protocol actually deals with strings,
but we would have to prefix everything with 'b'
b) clunky, because the handling of the bytes objects is sufficiently
different in PY2 and PY3 (e.g. b'a'[0] is a string in PY2, but an
int in PY3).
- using the latin1 codec (which gives an identity transformation for the
first 256 code points of unicode) instead of the custom
bytes_to_string functions. This almost could work, but it was still
slightly different between python 2 and 3, because in PY2 in would
return a unicode object, which would then cause problems when
combined with regular strings if it contained 8-bit chars.
With this in mind, I think the best solution for the time being is to
just coerce everything into the string type as early as possible, and
have things proceed indentically on both python versions. Once we stop
supporting python3, we can revisit the idea of using bytes objects more
prevasively.
Reviewers: davide, zturner, serge-sans-paille
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D58177
llvm-svn: 354106
|
|
|
|
|
|
|
|
|
|
|
| |
Without that, dotest.py would be executed with the default python
interpreter, which may not be the same one that lldb is built with.
This still requires the user do know which python interpreter to use
when running lldb-dotest, but now he is at least able to choose it, if
he knows which one to use.
llvm-svn: 354105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Instead of doing string chopping on the resulting python file, get swig
to output the version for us. The two things which make slightly
non-trivial are:
- in order to get swig to expand SWIG_VERSION for us, we cannot use
%pythoncode directly, but we have to go through an intermediate macro.
- SWIG_VERSION is a hex number, but it's components are supposed to be
interpreted decimally, so there is a bit of integer magic needed to
get the right number to come out.
I've tested that this approach works both with the latest (3.0.12) and
oldest (1.3.40) supported swig.
Reviewers: zturner, jingham, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58172
llvm-svn: 354104
|
|
|
|
| |
llvm-svn: 354103
|
|
|
|
| |
llvm-svn: 354100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When a process is loaded, update its sections with the load address to resolve any created breakpoints. For the remote debugging case, the debugged process is launched remotely so GetLoadAddress is intended to pass the load address from remote to LLDB (client).
Reviewers: zturner, llvm-commits, clayborg, labath
Reviewed By: labath
Subscribers: mgorny, sas, Hui, clayborg, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D56237
llvm-svn: 354099
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the redundant termination clause from within the loop. Since
the check is done at the end of the loop, it's entirely redundant
to the 'while' condition. If termination was requested, the latter
will become false and the 'while' loop will terminate, resulting
in the 'return' statement below the loop being executed (which is
equivalent to the one used inside 'if').
Differential Revision: https://reviews.llvm.org/D58227
llvm-svn: 354050
|
|
|
|
| |
llvm-svn: 354048
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dotest's version comparision function is just a lexicographical compare
of the version strings. This is obviously wrong. This patch implements
the comparison using distutils.version.LooseVersion as suggested by
Zachary.
Reviewers: zturner, labath, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58219
llvm-svn: 354047
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was looking at the ClangExpressionParser and noticed that we have a
FileManager owned by the expression parser and later ask the compiler
instance to create a new FileManager, owned by the clang CI. Looking at
the code I don't see a good reason for having two instances. This patch
removes the one owned by LLDB.
Differential revision: https://reviews.llvm.org/D58222
llvm-svn: 354041
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As suggested by Pavel, we shouldn't let our tests parse the local .lldbinit to prevent random test failures
due to changed settings.
Fixes Minidump/Windows/Sigsegv/sigsegv.test (and probably others too).
Reviewers: labath, serge-sans-paille
Reviewed By: labath
Subscribers: abidh, lldb-commits, zturner
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D58235
llvm-svn: 354038
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Generator expressions are not supported in the `BUILD_RPATH` target property.
`BUILD_RPATH` is only supported in 3.8+ https://cliutils.gitlab.io/modern-cmake/chapters/intro/newcmake.html
`LLDB_FRAMEWORK_INSTALL_DIR` should not overwrite, but rather add an install RPATH (and it should be the first)
Reviewers: xiaobai, lanza
Reviewed By: xiaobai
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D57989
llvm-svn: 354037
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a preparatory step to enable adding extra unwind strategies by
symbol file plugins. This has been discussed on the lldb-dev mailing
list: <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.
Reviewers: jasonmolenda, clayborg, espindola
Subscribers: lemo, emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D58129
llvm-svn: 354033
|
|
|
|
|
|
|
|
|
|
| |
Catch the possible error from lldb-gdbserver's main loop, and report
it verbosely. Currently, if the loop fails the server exits normally,
rendering the problem indistinguishable from regular termination.
Differential Revision: https://reviews.llvm.org/D58228
llvm-svn: 354030
|
|
|
|
|
|
|
|
|
|
| |
Modify the kevent() error reporting to use errno rather than returning
the return value. At least on FreeBSD and NetBSD, kevent() always
returns -1 in case of error, and the actual error is returned via errno.
Differential Revision: https://reviews.llvm.org/D58229
llvm-svn: 354029
|
|
|
|
| |
llvm-svn: 354012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Implement a few routines for Windows to support some basic process interaction and file system operations.
Reviewers: zturner, llvm-commits, labath, jingham
Reviewed By: labath
Subscribers: emaste, jdoerfert, Hui, labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56232
llvm-svn: 354010
|
|
|
|
| |
llvm-svn: 353979
|
|
|
|
|
|
|
| |
We have a custom target for lldb's test dependencies but it must have
gotten lost in one of the recent CMake refactorings.
llvm-svn: 353978
|
|
|
|
| |
llvm-svn: 353971
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch properly extracts the full submodule path as well as its
search paths from DWARF import decls and passes it on to the
ClangModulesDeclVendor.
rdar://problem/47970144
Differential Revision: https://reviews.llvm.org/D58090
llvm-svn: 353961
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It looks like I was too hasty to submit the previous patch. It does fix
some tests on python3, but it also breaks one tests with python2.
This happens because the gdb-remote protocol can sometimes (but not very
often) contain binary data, and attempting to parse this as utf8
characters fails.
This reverts commit r353944.
llvm-svn: 353945
|
|
|
|
|
|
| |
This fixes about a dozen tests with python3.
llvm-svn: 353944
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Restore the previous behavior of using install directories for
LLVM_MAIN_INCLUDE_DIR, LLVM_LIBRARY_DIR and LLVM_BINARY_DIR. The update
from llvm-config to CMake has changed the values of those values to use
LLVM_BUILD_* which is plain wrong and breaks stand-alone builds.
Instead, use the CMake counterparts of the values returned
by llvm-config.
Differential Revision: https://reviews.llvm.org/D57995
llvm-svn: 353925
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is coming from the discussion in D55356 (the most interesting part
happened on the mailing list, so it isn't reflected on the review page).
In short the issue is that lldb assumes that all bytes of a module image
in memory will be backed by a "section". This isn't the case for PECOFF
files because the initial bytes of the module image will contain the
file header, which does not correspond to any normal section in the
file. In particular, this means it is not possible to implement
GetBaseAddress function for PECOFF files, because that's supposed point
to the first byte of that header.
If my (limited) understanding of how PECOFF files work is correct, then
the OS is expecded to load the entire module into one continuous chunk
of memory. The address of that chunk (+/- ASLR) is given by the "image
base" field in the COFF header, and it's size by "image size". All of
the COFF sections are then loaded into this range.
If that's true, then we can model this behavior in lldb by creating a
"container" section to represent the entire module image, and then place
other sections inside that. This would make be consistent with how MachO
and ELF files are modelled (except that those can have multiple
top-level containers as they can be loaded into multiple discontinuous
chunks of memory).
This change required a small number of fixups in the PDB plugins, which
assumed a certain order of sections within the object file (which
obivously changes now). I fix this by changing the lookup code to use
section IDs (which are unchanged) instead of indexes. This has the nice
benefit of removing spurious -1s in the plugins as the section IDs in
the pdbs match the 1-based section IDs in the COFF plugin.
Besides making the implementation of GetBaseAddress possible, this also
improves the lookup of addresses in the gaps between the object file
sections, which will now be correctly resolved as belonging to the
object file.
Reviewers: zturner, amccarth, stella.stamenova, clayborg, lemo
Reviewed By: clayborg, lemo
Subscribers: JDevlieghere, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56537
llvm-svn: 353916
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.
In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.
I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.
llvm-svn: 353912
|
|
|
|
|
|
|
|
|
|
| |
This patch hooks up clang and lldb's reproducers functionality. It
ensures that when capturing a reproducer, headers and modules imported
through the expression parser are collected.
Differential revision: https://reviews.llvm.org/D58076
llvm-svn: 353906
|
|
|
|
| |
llvm-svn: 353896
|
|
|
|
|
|
| |
Nothing crazy, this is pretty mechanical.
llvm-svn: 353894
|
|
|
|
|
|
|
|
|
|
|
|
| |
On a local modules build this would cause an error.
> fatal error: no handler registered for module format 'obj'
> LLVM ERROR: unknown module format
Interestingly enough, this didn't trigger on the GreenDragon CMake bot,
which is configured with modules.
llvm-svn: 353869
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the tests not to use '127.0.0.1' and 'localhost' interchangeably.
More specifically, since tests bind specifically to 127.0.0.1, connect
to that address as well; using 'localhost' can resolve to IPv6 address
which can cause issues -- for example, if the matching port happens to
be used by some other process, the tests hang forever waiting for
the client to connect.
While technically the case of randomly selected IPv4 port being taken
on IPv6 loopback is not very likely, NetBSD happens to be suffering from
some weird kernel issue where connection to that port succeeds
nevertheless. Until we can really figure out what goes wrong there,
this saves us from the tests hanging randomly.
Differential Revision: https://reviews.llvm.org/D58131
llvm-svn: 353868
|