Linux configure+make builds have ~175 tests failing that aren't
failing in cmake builds. The tests have error messages like
"'a.out' doesn't contain the architecture x86-64" ObjectFileELF
plugin wasn't loaded when this message was output.
I found ScriptInterpreterPython::InitializePrivate() is calling
Debugger::Terminate(), which terminates ObjectFileELF (and lots
of other stuff) setup earlier in the InitializeForLLGS.
So I moved python Init/Term from Init/TermForLLGS to Init/Term
llvm-svn: 231550
This means you can set an expression prefix file with:
(lldb) settings set target.expr-prefix /tmp/to/prefix.txt
And you can run an expression and modify your expression prefix file in another editor without having to type:
(lldb) settings set target.expr-prefix /tmp/to/prefix.txt
again...
<rdar://problem/12155942>
llvm-svn: 231535
Summary: This patch adds a few comments for GetValueDidChange and contains improvements for TestValueVarUpdate.py test which checks ValueObject::GetValueDidChange for complex types.
Reviewers: zturner, granata.enrico, clayborg
Reviewed By: clayborg
Subscribers: jingham, lldb-commits, granata.enrico, zturner, clayborg
Differential Revision: http://reviews.llvm.org/D8103
llvm-svn: 231526
Summary:
This patch includes:
* Fix -var-create command for global/static variables
* Fix -var-update command: remove m_strValueName/m_eVarInfoFormat/m_bValueChanged{Array,Composite,Normal}Type; clean CMICmdCmdVarUpdate::Execute and CMICmdCmdVarUpdate::Acknowledge; improve CMICmdCmdVarUpdate::MIFormResponse; Complete the value after -var-create using the CMICmdCmdVarCreate::CompleteSBValue to get SBValue::GetValueDidChange work.
* Add non-constant version of CMICmnLLDBDebugSessionInfoVarObj::GetValue
* Add MiVarTestCase.test_lldbmi_var_update test
All tests pass on OS X.
Reviewers: abidh, emaste, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, emaste, clayborg, abidh
Differential Revision: http://reviews.llvm.org/D8110
llvm-svn: 231525
This removes Host::Backtrace from the codebase, and changes all
call sites to use llvm::sys::PrintStackTrace(). This makes the
functionality available for all platforms, and even for platforms
which currently had a supported implementation of Host::Backtrace,
this patch should enable richer information in stack traces, such
as file and line number information, as well as giving it the
ability to unwind through inlined functions.
llvm-svn: 231511
- use a hardcoded formatter to match all vector types, and make it so that their element type is taken into account when doing default formatting
- special case a vector of char to display byte values instead of characters by default
Fixes the test failures Ilia was seeing
llvm-svn: 231504
Summary:
I'm not sure that this failure should be fixed by modifying this test.
It seems strange for me that the only one type vUInt8 is printed with '0x' prefix.
This patch fixes the following error:
```
======================================================================
FAIL: test_with_dsym_and_run_command (Test-rdar-10642615.Radar10642615DataFormatterTestCase)
Test data formatter commands.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 456, in wrapper
return func(self, *args, **kwargs)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/rdar-10642615/Test-rdar-10642615.py", line 21, in test_with_dsym_and_run_command
self.data_formatter_commands()
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/rdar-10642615/Test-rdar-10642615.py", line 68, in data_formatter_commands
'(vBool32) valueBool32 = (0, 1, 0, 1)'])
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 2100, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : '(vUInt8) valueU8 = ('\x01', '\0', '\x04', '\0', '\0', '\x01', '\0', '\x04', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0')' returns expected result
Config=x86_64-clang
======================================================================
FAIL: test_with_dwarf_and_run_command (Test-rdar-10642615.Radar10642615DataFormatterTestCase)
Test data formatter commands.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 473, in wrapper
return func(self, *args, **kwargs)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/rdar-10642615/Test-rdar-10642615.py", line 28, in test_with_dwarf_and_run_command
self.data_formatter_commands()
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/rdar-10642615/Test-rdar-10642615.py", line 68, in data_formatter_commands
'(vBool32) valueBool32 = (0, 1, 0, 1)'])
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 2100, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : '(vUInt8) valueU8 = ('\x01', '\0', '\x04', '\0', '\0', '\x01', '\0', '\x04', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0')' returns expected result
Config=x86_64-clang
----------------------------------------------------------------------
```
Reviewers: granata.enrico, zturner, clayborg
Subscribers: clayborg, lldb-commits, zturner, granata.enrico
Differential Revision: http://reviews.llvm.org/D8102
llvm-svn: 231490
Previously it was initialized by ProcessLinux but lldb-server don't
contain ProcessLinux anymore so it have to be initialized by
NativeProcessLinux also.
Differential revision: http://reviews.llvm.org/D8080
llvm-svn: 231482
Summary:
starting a debug session on linux with -o "process launch" lldb parameter was failing since
Target::Launch (in sychronous mode) is expecting to be able to receive public process events.
However, PlatformLinux did not set up event hijacking on process launch, which caused these
events to be processed elsewhere and left Target::Launch hanging. This patch enables event
interception in PlatformLinux (which was commented out).
Upon enabling event interception, I noticed an issue, which I traced back to the inconsistent
state of public run lock, which remained false even though public and private process states were
"stopped". I addressed this by making sure the run lock is "stopped" upon exit from
WaitForProcessToStop (which already had similar provisions for other return paths).
Test Plan: This should fix the intermittent TestFormats failure we have been experiencing on Linux.
Reviewers: jingham, clayborg, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8079
llvm-svn: 231460
Unlike GDB, we tackle the problem of representing vector types in different styles by having a synthetic child provider that recognizes the format you're trying to apply to the variable, and coming up with the right type and number of child values to match that format
This makes for a more compact representation and less visual noise
Fixes rdar://5429347
llvm-svn: 231449
This is a temporary fix until a more comprehensive fix can be made for finding functions that we call in expressions.
We find "NSLog" in ClangExpressionDeclMap::FindExternalVisibleDecls() in after a call to target->GetImages().FindFunctions(...). Note that there are two symbols: NSLog from CFNetwork which is not external, and NSLog from Foundation which _is_ external. We do something with the external symbol with:
if (extern_symbol)
{
AddOneFunction (context, NULL, extern_symbol, current_id);
context.m_found.function = true;
}
Then later we try to lookup the _Z5NSLogP8NSStringz name and we don't find it so we call ClangExpressionDeclMap::GetFunctionAddress() with "_Z5NSLogP8NSStringz" as the name and the sc_list_size is zero at the "if" statement at line 568 because we don't find the mangled name and we extract the basename "NSLog" and call:
FindCodeSymbolInContext(ConstString(basename), m_parser_vars->m_sym_ctx, sc_list);
sc_list_size = sc_list.GetSize();
and we get a list size of two again, and we proceed to search for the symbol again, this time ignoring the external vs non-external-ness of the symbols that we find. This fix ensures we prioritize the external symbol until we get a real fix from Sean Callanan when he gets back to make sure we don't do multiple lookups for the same symbol we already resolved.
<rdar://problem/19879282>
llvm-svn: 231420
Summary:
LLDB driver was simply tacking quotes around the strings in lldb commands, hoping that will work.
This changes it to properly escape quotes and backslashes.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8083
llvm-svn: 231394
operator in addition to the vendor-extension DW_OP_GNU_push_tls_address.
clang on PS4 and Darwin will be emitting the standard opcode
as of r231286 via http://reviews.llvm.org/D8018
Behavior of this standard opcode is the same as
DW_OP_GNU_push_tls_address.
<rdar://problem/20043195>
llvm-svn: 231342
We would like it if LLDB never crashed, especially if we never caused LLDB to crash
On the other hand, having assertions can sometimes be useful
lldbassert(x) is the best of both worlds:
- in debug builds, it turns into a regular assert, which is fine because we don't mind debug LLDB to crash on development machines
- in non-debug builds, it emits a message formatted just like assert(x) would, but then instead of crashing, it dumps a backtrace, suggests filing a bug, and keeps running
llvm-svn: 231310
Setting it from the Target architecture cause problems when the target
archiutecture is filled just by examining the executable because in that
case the OS isn't set.
Differential revision: http://reviews.llvm.org/D8035
llvm-svn: 231234
The deadlock occurred when the Attach or the Launch operation failed for
any reason.
Differential revision: http://reviews.llvm.org/D8030
llvm-svn: 231231
Summary:
Symbol table generation code was failing to take into account the debug symbols because
the object file was looking only into its own section list when doing the generation, even though
the debug symbols from another object file were correctly detected and loaded by the
SymbolVendor. This changes the code to use the unified section list, which fixes this problem.
Test Plan:
I do not intend do submit this yet since it causes (or more like, exposes) the issue
in D7884, but I wanted to put this out here, so that anyone who wants to take a look at it can do
so. (And I also wanted to know if this is the right approach to the problem :).
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7913
llvm-svn: 231229
Summary:
Symbols in ELF files can be versioned, but LLDB currently does not understand these. This problem
becomes apparent once one loads glibc with debug info. Here (in the .symtab section) the versions
are embedded in the name (name@VERSION), which causes issues when evaluating expressions
referencing memcpy for example (current glibc contains memcpy@@GLIBC_2.14 and
memcpy@GLIBC_2.2.5).
This problem was not evident without debug symbols as the .dynsym section
stores the bare names and the actual versions are present in a separate section (.gnu.version_d),
which LLDB ignores. This resulted in two definitions of memcpy in the symbol table.
This patch adds support for storing annotated names to the Symbol class. If
Symbol.m_contains_linker_annotations is true then this symbol is annotated. Unannotated name can
be obtained by calling StripLinkerAnnotations on the corresponding ObjectFile. ObjectFileELF
implements this to strip @VERSION suffixes when requested. Symtab uses this function to add the
bare name as well as the annotated name to the name lookup table.
To preserve the size of the Symbol class, I had to steal one bit from the m_type field.
Test Plan:
This fixes TestExprHelpExamples.py when run with a glibc with debug symbols. Writing
an environment agnostic test case would require building a custom shared library with symbol
versions and testing symbol resolution against that, which is somewhat challenging.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8036
llvm-svn: 231228
Debugger.h is a huge file that gets included everywhere, and
FormatManager.h brings in a ton of unnecessary stuff and doesn't
even use anything from it in the header.
llvm-svn: 231161
Summary:
The inferior can load the library now, but the remote test is still failing
because of a module loading problem in LLDB.
Reviewers: ovyalov, sivachandra, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8038
llvm-svn: 231120
This continues the effort to reduce header footprint and improve
build speed by removing clang and other unnecessary headers
from Target.h. In one case, some headers were included solely
for the purpose of declaring a nested class in Target, which was
not needed by anybody outside the class. In this case the
definition and implementation of the nested class were isolated
in the .cpp file so the header could be removed.
llvm-svn: 231107
Summary: Needed to transfer stdout.txt to host before reading.
Reviewers: ovyalov, clayborg
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D8023
llvm-svn: 231101
This is part of a larger effort to reduce header file footprints.
Combined, these patches reduce the build time of LLDB locally by
over 30%. However, they touch many files and make many changes,
so will be submitted in small incremental pieces.
Reviewed By: Greg Clayton
Differential Revision: http://reviews.llvm.org/D8022
llvm-svn: 231097
Summary:
Fix and enable some lldb-mi tests on Linux:
Fixed:
# MiExecInterpreterTestCase.test_lldbmi_thread_step_in
# MiExecTestCase.test_lldbmi_exec_step
# MiStackTestCase.test_lldbmi_stack_info_frame tests.
Also I enabled the following tests on Linux:
# MiExecTestCase.test_lldbmi_exec_step_instruction
# MiSignalTestCase.test_lldbmi_stopped_when_interrupted
All test pass on OS X and Linux.
Reviewers: abidh, vharron, clayborg
Reviewed By: clayborg
Subscribers: vharron, lldb-commits, clayborg, abidh
Differential Revision: http://reviews.llvm.org/D7987
llvm-svn: 231072
Vince Harron