Summary:
In my next step at cleaning up modify-python-lldb.py, I started focusing
on equality comparison. To my surprise, I found out that both python and
c++ versions of the SBType class implement equality comparison, but each
one does it differently. While the python version was implemented in
terms of type name equality, the C++ one used a deep comparison on the
underlying objects.
Removing the python version caused one test to fail (TestTypeList). This
happened because the c++ version of operator== boiled down to
TypePair::operator==, which contains two items: the compiler_type and
type_sp. In this case, the compiler_type was identical, but one of the
objects had the type_sp field unset.
I tried fixing the code so that both objects keep their type_sp member,
but it wasn't easy, because there are so many operations which just work
with the CompilerType types, and so any operation on the SBType (the
test in question was doing GetPointeeType on the type of one variable
and expecting it to match the type of another variable), cause that
second member to be lost.
So instead, here I relax the equality comparison on the TypePair
class. Now, this class ignores the type_sp for the purposes of
comparison, and uses the CompilerType only. This seems reasonable, as
each TypeSP is able to convert itself to a CompilerType.
Reviewers: clayborg, aprantl, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D59217
llvm-svn: 356048
Given this was under trace, it can just be removed. If somebody
ever needs to debug this testcase again and print the data, they
can add a new statement.
llvm-svn: 355999
This patch adds an XCOFF triple object format type into LLVM.
This XCOFF triple object file type will be used later by object file and assembly generation for the AIX platform.
Differential Revision: https://reviews.llvm.org/D58930
llvm-svn: 355989
LLVM doesn't produce DWARF64, and neither does GCC. LLDB's support
for DWARF64 is only partial, and if enabled appears to also not work.
Finally, it's untested. Removing this makes merging LLVM and
LLDB's DWARF parsing implementations simpler.
Differential Revision: https://reviews.llvm.org/D59235
llvm-svn: 355975
This is a very thin wrapper over a std::vector<DWARFDIE> and does
not seem to provide any real value over just using a container
directly.
Differential Revision: https://reviews.llvm.org/D59165
llvm-svn: 355974
This is not used outside of the private implementation of the class,
so hiding in the implementation file is a nice way of simplifying
the external interface.
Differential Revision: https://reviews.llvm.org/D59164
llvm-svn: 355973
darwin kernel debug session.
Originally, the kext name & uuid were emitted in the middle of the
kext-loading period's. Last week I decided to try not printing
any details about kexts that failed to load, only printing a summary
of how many failed to load.
This time I'm print different progress characters depending on whether
the kext loaded or not ("-" for not), then at the end I will print a
summary of how many kexts failed to load and a sorted list of the
kexts with the bundle ID and the uuid. It's a lot more readable.
<rdar://problem/48654569>
llvm-svn: 355958
There's a single report of a crash coming from this current_sp being NULL. I don't
have a repro case, and I couldn't get it to happen by hand-corrupting a list. We
always get an error instead. So I don't have a test case. But checking for null
is clearly right here.
<rdar://problem/48503320>
llvm-svn: 355957
ICF can cause multiple symbols to start at the same virtual address.
I plan to handle this shortly, but I wanted to correct the comment for
now.
Deleted an obsolete comment about adjusting the offset for the magic
number at the beginning of the debug info stream. This adjustment is
handled at a lower level now.
llvm-svn: 355943
Yesterday I noticed a reproducer test failing after making a local
change. Removing the reproducer directory solved the issue. Add a test
case that detects this.
llvm-svn: 355941
The command interpreter holds a pointer to a DataRecorder. After
generating the reproducer, we deallocated all the DataRecorders, causing
the command interpreter to hold a non-null reference to an invalid
object.
This patch changes the behavior of the command provider to stop the
DataRecorders when a reproducer is generated, rather than deallocating
them.
llvm-svn: 355940
Summary:
This patch is the MVP version of importing the std module into the expression parser to improve C++ debugging.
What happens in this patch is that we inject a `@import std` into our expression source code. We also
modify our internal Clang instance for parsing this expression to work with modules and debug info
at the same time (which is the main change in terms of LOC). We implicitly build the `std` module on the first use. The
C++ include paths for building are extracted from the debug info, which means that this currently only
works if the program is compiled with `-glldb -fmodules` and uses the std module. The C include paths
are currently specified by LLDB.
I enabled the tests currently only for libc++ and Linux because I could test this locally. I'll enable the tests
for other platforms once this has landed and doesn't break any bots (and I implemented the platform-specific
C include paths for them).
With this patch we can now:
* Build a libc++ as a module and import it into the expression parser.
* Read from the module while also referencing declarations from the debug info. E.g. `std::abs(local_variable)`.
What doesn't work (yet):
* Merging debug info and C++ module declarations. E.g. `std::vector<CustomClass>` doesn't work.
* Pretty much anything that involves the ASTImporter and templated code. As the ASTImporter is used for saving the result declaration, this means that we can't
call yet any function that returns a non-trivial type.
* Use libstdc++ for this, as it requires multiple include paths and Clang only emits one include path per module. Also libstdc++ doesn't support Clang modules without patches.
Reviewers: aprantl, jingham, shafik, friss, davide, serge-sans-paille
Reviewed By: aprantl
Subscribers: labath, mgorny, abidh, jdoerfert, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D58125
llvm-svn: 355939
Tablegen doesn't support options that are both flags and take values as
an argument. I noticed this when doing the tablegen rewrite, but forgot
that that affected the reproducer --capture flag.
This patch makes --capture a flag and adds --capture-path to specify a
path for the reproducer. In reality I expect this to be mostly used for
testing, but it could be useful nonetheless.
Differential revision: https://reviews.llvm.org/D59238
llvm-svn: 355936
Summary:
This patch marks the inline namespaces from DWARF as inline and also ensures that looking
up declarations now follows the lookup rules for inline namespaces.
Reviewers: aprantl, shafik, serge-sans-paille
Reviewed By: aprantl
Subscribers: eraman, jdoerfert, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D59198
llvm-svn: 355897
The RECORD macro is context sensitive because it depends on the
LLDB_GET_INSTRUMENTATION_DATA. This updates the modulemap to mark that
header as textual.
llvm-svn: 355879
Apparently the log_append variant added in r355863 is considered
ambiguous. At this point I'm out of ideas so a good old reinterpret cast
will have to do. If anybody has a better idea I'd be happy to hear it.
llvm-svn: 355866
Changing the type in the DUMMY macro to void* doesn't actually fix the
build error, because the argument type is deducted from the template (as
opposed to when serializing through the instrumentation framework, where
this would matter). Instead I've added a proper instance of log_append
that takes function pointers and logs their address.
llvm-svn: 355863
There was a crash that would happen if an IDE would ask for a child of a shared pointer via any SB API call that ends up calling StackFrame::GetValueForVariableExpressionPath(). The previous code expects an error to be set describing why the synthetic child of a type was not able to be found, but we have some synthetic child providers that weren't setting the error and returning an empty value object shared pointer. This fixes that to ensure we don't lose our debug session by crashing, fully tests GetValueForVariableExpressionPath functionality, and ensures we don't crash on GetValueForVariableExpressionPath() in the future.
Differential Revision: https://reviews.llvm.org/D59200
llvm-svn: 355850
Callbacks in the LLDB_RECORD_DUMMY macros were causing build failures
with the Xcode project. This patch replaces the function pointers with
void pointers so they can be logged.
llvm-svn: 355842
Summary:
Our python version of the SB API has (the python equivalent of)
operator bool, but the C++ version doesn't.
This is because our python operators are added by modify-python-lldb.py,
which performs postprocessing on the swig-generated interface files.
In this patch, I add the "operator bool" to all SB classes which have an
IsValid method (which is the same logic used by modify-python-lldb.py).
This way, we make the two interfaces more constent, and it allows us to
rely on swig's automatic syntesis of python __nonzero__ methods instead
of doing manual fixups.
Reviewers: zturner, jingham, clayborg, jfb, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58792
llvm-svn: 355824
the input StringRef is not guaranteed to be null-terminated, so using
data to get the c string is wrong. Luckily, in two of the usages the
target function already accepts a StringRef so we can just drop the
data() call, and the third one is easily replaced by a stringref-aware
function.
Issue found by msan.
llvm-svn: 355817
Summary:
Within .lldbinit, regex commands can be structured as a list of substitutions over
multiple lines. It's possible that this is uninentional, but it works and has
benefits.
For example:
command regex <command-name>
s/pat1/repl1/
s/pat2/repl2/
...
I use this form of `command regex` in my `~/.lldbinit`, because it makes it
clearer to write and read compared to a single line definition, because
multiline substitutions don't need to be quoted, and are broken up one per line.
However, multiline definitions result in usage instructions being printed for
each use. The result is that every time I run `lldb`, I get a dozen or more
lines of noise. With this change, the instructions are only printed when
`command regex` is invoked interactively, or from a terminal, neither of which
are true when lldb is sourcing `~/.lldbinit`.
Reviewers: clayborg, jingham
Reviewed By: clayborg
Subscribers: jdoerfert, kastiglione, xiaobai, keith, lldb-commits
Differential Revision: https://reviews.llvm.org/D48752
llvm-svn: 355793
Fix 2lwp_process_SIGSEGV NetBSD core test to terminate inside regular
function rather than libc call, in order to get reproducible backtrace
on different platforms.
Differential Revision: https://reviews.llvm.org/D59177
llvm-svn: 355786
Adjust the XFAIL-ing tests to match consistent results from buildbot.
I'm going to work on differences between them and my local results
following this.
llvm-svn: 355774
The code commited in r355764 didn't do what I want as I typed GetThreadID
instead of GetQueueID. This commit contains a (hopefully) better version
of the workaround.
llvm-svn: 355766
This is not a fix, but if I understand enough of the issue, it should
bail out early of the test when in a situation that would result in
a failure down the road.
llvm-svn: 355764
Inspired by Zachary's mail on lldb-dev, this seemed like low hanging
fruit. This patch breaks the circular dependency between commands and
expression.
Differential revision: https://reviews.llvm.org/D59158
llvm-svn: 355762
to do "databuffer + offset" so that we don't overflow the uint64_t's
we're using for addresses when working with high addresses.
Found with clang's ubsan while doing darwin kernel debugging.
<rdar://problem/48728940>
llvm-svn: 355761
Fix the NetBSD core test not to verify libc function names in backtrace.
This obviously requires the same libc.so as originally used to produce
the core file, and so it is going to fail everywhere except on my
system.
llvm-svn: 355747
Improve the support for processing NetBSD cores. Fix reading process
identifier, thread information and associating the terminating signal
with the correct thread.
Includes test cases for single-threaded program receiving SIGSEGV,
and two dual-threaded programs: one where thread receives the signal,
and the other one when the whole process is signalled.
Differential Revision: https://reviews.llvm.org/D32149
llvm-svn: 355736
Add a macro that doesn't actually record anything but still toggles the
API boundary. Removing just the register macros for lldb::thread_t
wasn't sufficient on NetBSD because the serialization logic needed the
underlying type to be complete.
This macro should be used by functions that are currently unsupported,
as they might trip the API boundary logic. This should be easy using the
lldb-instr tool.
llvm-svn: 355709
I changed the variable to an unsigned to get rid of a signed and
unsigned compare without realizing the value could be negative. This
fixes the assert instead.
llvm-svn: 355708
The last round of logging taught us that when the test fails, lldb
is indeed aware of the thread it's failing to associate to a given
queue. Add more logging to try to figure out why the thread and the
queue do not appear related to the Queue APIs.
llvm-svn: 355706
The overload and/or template specialization are regular functions and
should be marked inline when implemented in the header. Writing the
previous commit message should've made that obvious but I was already
overthinking it. This will fix the windows bot.
llvm-svn: 355657
Previously if an invalid program was specified, there was a bug
which, when we attempted to launch the program, would report that
the operation succeeded, causing LLDB to then hang while waiting
indefinitely to receive some events from the process.
After this patch, when an invalid program is specified, we immediately
return to vs code with an error message that indicates that the
program can not be found.
Differential Revision: https://reviews.llvm.org/D59114
llvm-svn: 355656
The current record macros already log the function being called. This
patch extends the macros to also log their input arguments and removes
explicit logging from the SB API.
This might degrade the amount of information in some cases (because of
smarter casts or efforts to log return values). However I think this is
outweighed by the increased coverage and consistency. Furthermore, using
the reproducer infrastructure, diagnosing bugs in the API layer should
become much easier compared to relying on log messages.
Differential revision: https://reviews.llvm.org/D59101
llvm-svn: 355649
I committed an implementation of GetClangResourceDir on windows but
forgot to update this test. I merged the tests like I intended to, but I
realized that the test was actually failing. After looking into it, it
appears that FileSystem::Resolve was taking the path and setting
the FileSpec's Directory to "/path/to/lldb/lib/clang/" and the File to
"9.0.0" which isn't what we want. So I removed the resolve line from
DefaultComputeClangResourceDir.
llvm-svn: 355648
Windows can't use standard i/o system calls such as read and write
to work with sockets, it instead needs to use the specific send
and recv calls. This complicates matters for the debug adapter,
since it needs to be able to work in both server mode where it
communicates over a socket, as well as non-server mode where it
communicates via stdin and stdout. To abstract this out, I've
introduced a class IOStream which hides all these details and
exposes a read/write interface that does the right on each
platform.
Differential Revision: https://reviews.llvm.org/D59104
llvm-svn: 355637
Summary: This function is useful for expression evaluation, especially when doing swift debugging on windows.
Reviewers: aprantl, labath
Reviewed By: labath
Subscribers: teemperor, jdoerfert, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D59072
llvm-svn: 355631
Summary: DW_OP_GNU_addr_index has been renamed as DW_OP_addrx in the standard. clang produces DW_OP_addrx tags and with this change lldb starts to process them.
Reviewers: aprantl, jingham, davide, clayborg, serge-sans-paille
Reviewed By: aprantl
Subscribers: jdoerfert, dblaikie, labath, shafik, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D59004
llvm-svn: 355629
After D55626 I see a failure in my Fedora buildbot.
There is uninitialized variable as the Foo constructor has not been run and foo
is an autovariable.
(lldb) breakpoint set -f foo.cpp -l 11
Breakpoint 1: where = TestDataFormatter.test.tmp.out`main + 30 at foo.cpp:11:7, address = 0x000000000040112e
(lldb) run
Process 801065 stopped
* thread #1, name = 'TestDataFormatt', stop reason = breakpoint 1.1
frame #0: 0x000000000040112e TestDataFormatter.test.tmp.out`main(argc=1, argv=0x00007fffffffcc48) at foo.cpp:11:7
8 };
9
10 int main(int argc, char **argv) {
-> 11 Foo foo(1, 2.22);
12 return 0;
13 }
Process 801065 launched: '.../tools/lldb/lit/Reproducer/Functionalities/Output/TestDataFormatter.test.tmp.out' (x86_64)
(lldb) frame var
(int) argc = 1
(char **) argv = 0x00007fffffffcc48
(Foo) foo = (m_i = 4198432, m_d = 0)
While the testcase expects m_i will be 0.
Differential Revision: https://reviews.llvm.org/D59088
llvm-svn: 355611
As discussed on the mailing list, default serialization for thread ids
is not correct, even if they're represented as basic types. I'm
purposely leaving the corresponding record macros in place so that we
don't break the API boundary detection.
llvm-svn: 355610
lldb/cmake/modules/LLDBConfig.cmake does not build lldb-server on Windows:
if (CMAKE_SYSTEM_NAME MATCHES "Android|Darwin|FreeBSD|Linux|NetBSD")
set(LLDB_CAN_USE_LLDB_SERVER 1)
Also do not append 'platform' parameter twice - although that was quietly
ignored.
llvm-svn: 355579
"apple-latest" which llvm uses to indicate the newest supported ISA.
Add a unit test; I'm only testing an armv8.1 instruction in this
unit test which would already be disassembled correctly because we
set the disassembler to ARM v8.2 mode, but it ensures that nothing
has been broken by adding this cpu spec.
<rdar://problem/38714781>
llvm-svn: 355578
Summary:
If LLDB_DISABLE_PYTHON is set, some functions are unavailable but
SBReproducer assumes they are. Let's conditionally register those functions
since they are conditionally declared.
Differential Revision: https://reviews.llvm.org/D59056
llvm-svn: 355575
This patch adds test that check that functionality in lldb continues to
work when replaying a reproducer.
- Entries in image list are identical.
- That stepping behaves the same.
- That the data formatters behave the same.
Differential revision: https://reviews.llvm.org/D55626
llvm-svn: 355570
DynamicLoaderDarwinKernel::KextImageInfo::LoadImageUsingMemoryModule
which would list every kext that failed to load when doing kernel
debugging. Instead, in DynamicLoaderDarwinKernel::ParseKextSummaries,
print a summary of how many kexts lldb was unable to load at the end.
I want to reduce the amount of output at the start of kernel debug
sessions a bit; we'll see if anyone really wanted to see the list of
which kexts specifically were unable to be loaded.
No functional change, only changing lldb's output at the start of
a kernel debug session.
<rdar://problem/48654569>
llvm-svn: 355565
Alex Langford