Summary:
This patch adds FileSP and SBFile versions of the API methods
ReportEventState and HandleProcessEvent. It points the SWIG
wrappers at these instead of the ones that use FILE* streams.
Reviewers: JDevlieghere, jasonmolenda, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68546
llvm-svn: 374816
Summary:
The build directory name is based on the test method name, so having
two test methods with the same name in the same test file is a
problem, even if they're in different test classes.
On linux and darwin this conflict can go unnoticed, but windows
has different filesystem semantics and it will fail when one
process tries to delete files still held open by another.
The problem is fixed just by changing the name of one of the test
methods.
Reviewers: JDevlieghere, jasonmolenda, labath, stella.stamenova
Reviewed By: stella.stamenova
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68951
llvm-svn: 374803
The DWARFExpression is parsing the location lists in about five places.
Of those, only one actually had proper support for base address
selection entries.
Since r374600, llvm has started to produce location expressions with
base address selection entries more aggresively, which caused some tests
to fail.
This patch adds support for these entries to the places which had it
missing, fixing the failing tests. It also adds a targeted test for the
two of the three fixes, which should continue testing this functionality
even if the llvm output changes. I am not aware of a way to write a
targeted test for the third fix (DWARFExpression::Evaluate).
llvm-svn: 374769
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
> llvm-svn: 374584
llvm-svn: 374631
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
> llvm-svn: 374584
llvm-svn: 374626
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
> llvm-svn: 374584
llvm-svn: 374622
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
> llvm-svn: 374584
llvm-svn: 374620
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
> llvm-svn: 374584
llvm-svn: 374609
Summary:
For context: https://reviews.llvm.org/D68293
We need a way to show all the processes on android regardless of the user id.
When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb.
Before:
```
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
3234 1 aarch64-unknown-linux-android adbd
8034 3234 aarch64-unknown-linux-android sh
9096 3234 aarch64-unknown-linux-android sh
9098 9096 aarch64-unknown-linux-android lldb-server
(lldb) ^D
```
Now:
```
(lldb) platform process list -x
205 matching processes were found on "remote-android"
PID PARENT USER TRIPLE NAME
====== ====== ========== ======================== ============================
1 0 init
524 1 init
525 1 init
531 1 ueventd
568 1 logd
569 1 aarch64-unknown-linux-android servicemanager
570 1 aarch64-unknown-linux-android hwservicemanager
571 1 aarch64-unknown-linux-android vndservicemanager
577 1 aarch64-unknown-linux-android qseecomd
580 577 aarch64-unknown-linux-android qseecomd
...
23816 979 com.android.providers.calendar
24600 979 com.verizon.mips.services
27888 979 com.hualai
28043 2378 com.android.chrome:sandboxed_process0
31449 979 com.att.shm
31779 979 com.samsung.android.authfw
31846 979 com.samsung.android.server.iris
32014 979 com.samsung.android.MtpApplication
32045 979 com.samsung.InputEventApp
```
Reviewers: labath,xiaobai,aadsm,clayborg
Subscribers:
llvm-svn: 374584
BumpPtrAllocator allocates in 4KiB chunks, which with any larger
project is going to result in a large number of allocations.
Increasing allocation size this way can save 10%-20% of symbol
load time for a huge C++ project with correctly built debuginfo.
Differential Revision: https://reviews.llvm.org/D68549
llvm-svn: 374583
Summary:
IOHandler needs to read lines of input from a lldb::File.
The way it currently does this using, FILE*, which is something
we want to avoid now. I'd prefer to just replace the FILE* code
with calls to File::Read, but it contains an awkward and
delicate workaround specific to ctrl-C handling on windows, and
it's not clear if or how that workaround would translate to
lldb::File.
So in this patch, we use use the FILE* if it's available, and only
fall back on File::Read if that's the only option.
I think this is a reasonable approach here for two reasons. First
is that interactive terminal support is the one area where FILE*
can't be avoided. We need them for libedit and curses anyway,
and using them here as well is consistent with that pattern.
The second reason is that the comments express a hope that the
underlying windows bug that's being worked around will be fixed one
day, so hopefully when that happens, that whole path can be deleted.
Reviewers: JDevlieghere, jasonmolenda, labath, lanza
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68622
llvm-svn: 374576
We essentially test libc++ in a sysroot here so let's make sure
that we actually only run this test on platforms where libc++
testing is enabled.
llvm-svn: 374572
Summary:
Currently when invoking lldb-test symbols -dump-ast it parses all the debug symbols and calls print(...) on the TranslationUnitDecl.
While useful the TranslationUnitDecl::print(...) method gives us a higher level view then the dump from ASTDumper which is what we get when we invoke dump() on a specific AST node.
The main motivation for this change is allow us to verify that the AST nodes we create when we parse DWARF. For example in order to verify we are correctly using DIFlagExportSymbols added by D66667
Differential Revision: https://reviews.llvm.org/D67994
llvm-svn: 374570
This should allow lldb-server to operate on files with non-ascii
pathnames.
I tried looking around in lldb/tools, and this seemed like the only
other tool (other than the main lldb driver itself) that would be
used (implicitly) by an end user (which could be working in
non-ascii paths).
Differential Revision: https://reviews.llvm.org/D68864
llvm-svn: 374537
Summary:
The previous attempt at making nameless process not match when searching for a
given name failed because the macos implementation was depending on this detail
in its partial matching strategy. Doing partial matching to avoid expensive
lookups is a perfectly valid thing to do, the way it was implemented seems
somewhat unexpected.
This patch implements it differently by providing special
methods in the ProcessInstanceInfoMatch which match only a subset of fields,
and changes mac host code to use those instead.
Then, it re-applies r373925 to get make the ProcessInstanceInfoMatch with a
name *not* match a nameless process.
Reviewers: JDevlieghere, teemperor, jingham
Subscribers: wallace, lldb-commits
Differential Revision: https://reviews.llvm.org/D68631
llvm-svn: 374529
This patch adds an implementation of unwinding using PE EH info. It allows to
get almost ideal call stacks on 64-bit Windows systems (except some epilogue
cases, but I believe that they can be fixed with unwind plan disassembly
augmentation in the future).
To achieve the goal the CallFrameInfo abstraction was made. It is based on the
DWARFCallFrameInfo class interface with a few changes to make it less
DWARF-specific.
To implement the new interface for PECOFF object files the class PECallFrameInfo
was written. It uses the next helper classes:
- UnwindCodesIterator helps to iterate through UnwindCode structures (and
processes chained infos transparently);
- EHProgramBuilder with the use of UnwindCodesIterator constructs EHProgram;
- EHProgram is, by fact, a vector of EHInstructions. It creates an abstraction
over the low-level unwind codes and simplifies work with them. It contains
only the information that is relevant to unwinding in the unified form. Also
the required unwind codes are read from the object file only once with it;
- EHProgramRange allows to take a range of EHProgram and to build an unwind row
for it.
So, PECallFrameInfo builds the EHProgram with EHProgramBuilder, takes the ranges
corresponding to every offset in prologue and builds the rows of the resulted
unwind plan. The resulted plan covers the whole range of the function except the
epilogue.
Reviewers: jasonmolenda, asmith, amccarth, clayborg, JDevlieghere, stella.stamenova, labath, espindola
Reviewed By: jasonmolenda
Subscribers: leonid.mashinskiy, emaste, mgorny, aprantl, arichardson, MaskRay, lldb-commits, llvm-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67347
llvm-svn: 374528
This avoids the currently MSVC specific codepath of using the
wchar entry point and converting that to utf8.
Differential Revision: https://reviews.llvm.org/D68770
llvm-svn: 374526
We currently don't handle the error in the Expected we get
when searching for an equal local DeclContext. Usually this can't
happen as this would require that we have a STL container and
we can find libc++'s std module, but when we load the module in
the expression parser the module doesn't even contain the 'std'
namespace. The only way I see to test this is by having a fake
'std' module that requires a special define to actually provide
its contents, while it will just be empty (that is, it doesn't
even contain the 'std' namespace) without that define. LLDB currently
doesn't know about that define in the expression parser, so it
will load the wrong 'empty' module which should trigger this error.
Also removed the 'auto' for that variable as the function name
doesn't make it obvious that this is an expected and not just
a optional/ptr (which is how this slipped in from the start).
llvm-svn: 374525
Summary: Makes the indent consistent to other part of the file.
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68842
llvm-svn: 374483
Summary:
After rLLDB365761, and with `LLVM_ENABLE_ABI_BREAKING_CHECKS` enabled,
launching any process on FreeBSD crashes lldb with:
```
Expected<T> must be checked before access or destruction.
Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed).
```
This is because `m_operation_thread` and `m_monitor_thread` were wrapped
in `llvm::Expected<>`, but this requires the objects to be correctly
initialized before accessing them.
To fix the crashes, use `llvm::Optional<>` for the members (as indicated
by labath), and use local variables to store the return values of
`LaunchThread` and `StartMonitoringChildProcess`. Then, only assign to
the member variables after checking if the return values indicated
success.
Reviewers: devnexen, emaste, MaskRay, mgorny
Reviewed By: devnexen
Subscribers: jfb, labath, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D68723
llvm-svn: 374444
Before the reorganiziation, the API tests were inheriting the timeout
from the top-level lit file. Now that this is no longer the case, the
lldb-api test suite needs to set its own timeout.
llvm-svn: 374435
Summary:
If you look at what this test is doing, it's actually quite
mysterious why it works at all. It sets the input file
inside a "with open". As soon as the with block ends,
that file will be closed. And yet somehow LLDB reads
commands from it anyway. What's actually happening is that
the file descriptor gets dup'd when something inside LLDB
calls File::GetStream(). I think it's fair to say that
what this test is doing is illegal and it has no right
to expect it to work.
This patch updates the test with two cases. One uses
the SBFile api, and actually transfers ownership of
the original file descriptor to the debugger. The other
just uses the old FILE* API, but in a sane way.
I also set NO_DEBUG_INFO_TESTCASE, because this test doesn't
use any debug info and doesn't need to run three times.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68738
llvm-svn: 374424
Summary:
Python 3.6 stringifies exceptions as `ExceptionClass("foo",)` instead
of `ExceptionClass("foo")`. This patch makes the test assertions a
little more flexible so the test passes anyway.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68745
llvm-svn: 374417
Auto-detecting CC in Makefile.rules is no longer useful. Ever since
out-of-tree builds we are better off just running lldb-dotest which
sets it directly. This also makes it harder to accidentally unset CC
in a Makefile.
Differential Revision: https://reviews.llvm.org/D68731
llvm-svn: 374402
When debugging a large program like clang and doing "frame variable
*this", the ValueObject pretty printer is doing hundreds of scoped
FindTypes lookups. The ones that take longest are the ones where the
DWARFDeclContext ends in something like ::Iterator which produces many
false positives that need to be filtered out *after* extracting the
DIEs. This patch demonstrates a way to filter out false positives at
the accerator table lookup step.
With this patch
lldb clang-10 -o "b EmitFunctionStart" -o r -o "f 2" -o "fr v *this" -b -- ...
goes (in user time) from 5.6s -> 4.8s
or (in wall clock) from 6.9s -> 6.0s.
Differential Revision: https://reviews.llvm.org/D68678
llvm-svn: 374401
Before the test reorganization, everything was part of a single test
suite with a single module cache. Now that things are properly separated
this is no longer the case. Only the shell tests inherited the logic to
properly configure and wipe the module caches. This patch adds that
logic back for the API tests. While doing so, I noticed that we were
configuring a Clang module cache in CMake, but weren't actually using it
from dotest.py. I included a fix for that in this patch as well.
Differential revision: https://reviews.llvm.org/D68755
llvm-svn: 374386
Pass the DSYMUTIL and SDKROOT variables on the command line instead of
the environment. This makes it easier to reproduce the make invocation
during development.
Differential revision: https://reviews.llvm.org/D68812
llvm-svn: 374385
Lawrence D'Anna