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:
The plugin already builds fine on other platforms (linux, at least). All
that was necessary was to revitalize the hack in PlatformDarwinKernel
(not a very pretty hack, but it gets us going at least).
I haven't done a thorough investigation of the state of the plugin on
other platforms, but at least the two core file tests we have seem to
pass, so I enable them.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D47133
llvm-svn: 332997
In r265181 the test for the NSCFBoolean data formatter was removed.
Later, in r279353 and r279446 a new implementation was provided for the
formatter, which I believe never worked (and this wasn't caught because
the test was never re-enabled).
This commit fixes the bug and re-enables the old test case.
Differential revision: https://reviews.llvm.org/D47014
llvm-svn: 332700
Summary: These three tests are failing on Windows and looking into the failures, they could be mapped to pr21765 and pr24489
Reviewers: asmith, labath, zturner
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47018
llvm-svn: 332629
Summary:
1) In logtest.cpp, the name of the file that is reported is not always capitalized, so split the comparison to validate the file (case insensitive) and function (case sensitive) separately
2) Update the gdb remote client tests to work with Python 3. In Python 3, socket sends/receives data as bytes rather than byte strings. This also updates the usage of .hex() - this is no longer available in Python 3, so use hexlify instead
Reviewers: asmith, labath, zturner
Reviewed By: labath
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46773
llvm-svn: 332293
This reverts commit r332162 as it breaks the bots (Ubuntu 14.04)
with the following message:
Build Command Output:
objcopy: option '--compress-debug-sections' doesn't allow an argument
llvm-svn: 332165
Summary:
1) In TestLinuxCore rather than skipping the tests on Windows, mark them as expected failures and add a bug reference
2) In dotest.py replace the undefined property in the exceptions with the actual property causing the exception
Reviewers: asmith, labath, zturner
Reviewed By: labath, zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46590
llvm-svn: 331886
Re-enable TestUnicodeSymbols now that we use the in-tree dsymutil. This
was disabled because the hashing of unicode symbols was out of sync
between llvm (dsymutil) and lldb.
llvm-svn: 331764
Summary:
... and fix one bug found this way. Currently, the test works not because
types are looked up correctly, but because by injecting local variables
we also materialize the types for Clang. If we disable the local variable
injection, then one check fails.
The reason of the failure is that FindTypes is run with max_matches==1
and this value is passed down to the symbol lookup functions. When the
search is performed only on the basename (like it's the case for an
entity defined in the root namespace), then the search will stop after
having found one match on the basename. But that match might be in a
namespace, we were really just looking up the basename in the accelerator
tables.
The solution is to not pass max_matches down, but to search without a
limit and let RemoveMismatchedTypes do its job afterwards. Note the
patch includes 2 hunks with the same change, but only the latter is
tested. I couldn't find a way to create a testcase for the other
branch of the if ('image lookup -t' allows me to get there, but it
only ever returns one type anyway).
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46548
llvm-svn: 331719
Summary:
In decorators.py, when opening streams, open them in text mode. In Py3, if they are not opened in text mode, the data is also expected to be binary, but we always use text data.
In TestLinuxCore, skip the tests that are not applicable on Windows
In the python api main.c, update the code to be compilable on Windows
Reviewers: asmith, zturner
Reviewed By: zturner
Subscribers: zturner
Differential Revision: https://reviews.llvm.org/D46440
llvm-svn: 331686
This change adds support for two types of Minidump CodeView records:
PDB70 (reference: https://crashpad.chromium.org/doxygen/structcrashpad_1_1CodeViewRecordPDB70.html)
This is by far the most common record type.
ELF BuildID (found in Breakpad/Crashpad generated minidumps)
This would set a proper UUID for placeholder modules, in turn enabling
an accurate match with local module images.
Differential Revision: https://reviews.llvm.org/D46292
llvm-svn: 331394
if an experimental setting has been removed/is missing.
Add tests for the .experimental. settings behaviors -- that they correctly
forward through to the real setting if it has become a real setting,
that they don't generate errors when a settig has been removed.
As Pavel notes in https://reviews.llvm.org/D45348, the way I'm suppressing
errors in the setting is not completely correct - if any of the setting
path components include "experimental", a missing setting would be declared
a non-error. So
settings set target.experimental.setting-that-does-not-exist true
would not generate an error, which is correct. But as Pavel notes,
settings set setting-does-not-exist.experimental.run-stopped true
should generate an error because the unknown name occurs before the
"experimental". The amount of change to do this correctly hasn't
thrilled me, so I'm leaving this as-is for now.
<rdar://problem/39223054>
Differential Revision: https://reviews.llvm.org/D45348
llvm-svn: 331315
Displaying of global pointer variables is not working on arm64 linux
(pr37301).
I've moved this part into a separate test, so it can be xfailed
separately. I then move the "show-variables-with-process-available"
check before the "show-all-variables" command to presrve the intent of
checking that global variable caching works correctly. (I've verified
that the new arrangement still fails when I revert the fix from
r331230.)
llvm-svn: 331250
This fixes a bug where
(lldb) target var g_ptr
would populate the global variables list with exactly one entry
because SymbolFileDWARF::ParseVariables() was invoked with a list of
DIEs pre-filtered by name, such that a subsequent call to
(lldb) fr var --show-globals
would only list that one variable, because CompileUnit::m_variables
was already initialized, fooling CompileUnit::GetVariableList().
CompileUnit::GetVariableList() grabs the *complete* list of variables
via (SymbolFileDWARF, ...)::ParseVariablesForContext and that still
calls CompileUnit::SetVariableList(variables) which acts as the
caching mechanism.
Differential Revision: https://reviews.llvm.org/D46220
llvm-svn: 331230
This patch fixes an issue where we weren't looking for exact matches in the expression parser and also fixed the type lookup logic in the Module.cpp. Tests added to make sure we don't regress.
Differential Revision: https://reviews.llvm.org/D46128
llvm-svn: 331227
ObjectFileELF assumes that code section has ".text" name. There is an
exception for kalimba toolchain that can use arbitrary names, but other
toolchains also could use arbitrary names for code sections. For
example, corert uses separate section for compiled managed code. As lldb
doesn't recognize such section it leads to problem with breakpoints on
arm, because debugger cannot determine instruction set (arm/thumb) and
uses incorrect breakpoint opcode that breaks program execution.
This change allows debugger to correctly handle such code sections. We
assume that section is a code section if it has SHF_EXECINSTR flag set
and has SHT_PROGBITS type.
Patch by Konstantin Baladurin <k.baladurin@partner.samsung.com>.
Differential Revision: https://reviews.llvm.org/D44998
llvm-svn: 331173
A typo in the patch (using syntax instead of m_syntax) resulted in the
normalization not working properly for windows filespecs when the syntax
was passed as host-native. This did not affect the unit tests, as all of
those pass an explicity syntax, but failed gloriously when running the
full test suite.
I also fix an expectation in an lldb-mi test, which was now failing
because it was expecting a path to be echoed verbatim, but we were now
normalizing it.
As a drive-by, this also fixes the default-in-fully-covered-switch
warning and removes an unused argument from the NeedsNormalization
function.
llvm-svn: 331172
LLDB doesn't use this packet so we never hit this, but it looks like
some other projects talk to debugserver and are hitting an assert
(https://github.com/derekparker/delve/issues/1015).
We had an off by 1 in the accounting of the FPU structure sizes.
I added a test that basically just check that 'g' doesn't return
an error (currently it assert in debug builds). I didn't make
it an lldb-server test because it looks like lldb-server doesn't
implement the g packet.
llvm-svn: 331004
When I merged the 2 codepaths that return an OS type, I hade
checked that the places accepting 'iphoneos' would also accept
'ios', but then I got it backwards and return 'iphoneos'.
We use this value to build triples, and there 'iphoneos' is
invalid.
This also makes the test slightly simpler.
llvm-svn: 330877
Summary:
The new script to run the lldbtests as part of lit invokes each test by calling dotest.py, however, we cannot rely on the system to always correctly interpret the script as python causing the tests to be unresolved on windows (at least). To fix this, we need to make sure that the first parameter in the command line is the python executable itself.
In Makefile.rules, there are a number of windows specific definitions that rely on the HOST_OS being set as Windows_NT but the logic detecting the OS currently does not detect server versions of windows correctly. This change updates the logic to detect windows server as well.
Reviewers: asmith, labath, JDevlieghere, zturner
Reviewed By: JDevlieghere, zturner
Subscribers: zturner, llvm-commits
Differential Revision: https://reviews.llvm.org/D46020
llvm-svn: 330740
Summary:
In the magic test duplicator, we were making the decision whether to
create a test variant based on the compiler and the target platform.
This meant that the set of known tests was different for each test
configuration.
This patch makes the set of generated test variants static and handles
the skipping via runtime checks instead. This is more consistent with
how we do other test-skipping decision (e.g. for libc++ tests), and
makes it easier to expose the full set of tests to lit, which now does
not need to know anything about what things can potentially cause tests
to appear or disappear.
Reviewers: JDevlieghere, aprantl
Subscribers: eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D45949
llvm-svn: 330708
The isOverload() method needs to account for situations where the two
methods being compared don't have the same number of arguments.
rdar://problem/39542960
llvm-svn: 330450
It was failing because the modules names were coming out as
C:\Windows\System32/MSVCP120D.dll (last separator is a forward slash) on
windows.
There are two issues at play here:
- the first problem is that the paths in minidump were being parsed as a
host path. This meant that on posix systems the whole path was
interpreted as a file name.
- on windows the path was split into a directory-filename pair
correctly, but then when it was reconsituted, the last separator ended
up being a forward slash because SBFileSpec.fullpath was joining them
with '/' unconditionally.
I fix the first issue by parsing the minidump paths according to the
path syntax of the host which produced the dump, which should make the
test behavior on posix&windows identical. The last path will still be a
forward slash because of the second issue. We should probably fix the
"fullpath" property to do something smarter in the future.
llvm-svn: 330314
Normally, LLDB is creating a high-fidelity representation of a live
process, including a list of modules and sections, with the
associated memory address ranges. In order to build the module and
section map LLDB tries to locate the local module image (object file)
and will parse it.
This does not work for postmortem debugging scenarios where the crash
dump (minidump in this case) was captured on a different machine.
Fortunately the minidump format encodes enough information about
each module's memory range to allow us to create placeholder modules.
This enables most LLDB functionality involving address-to-module
translations.
Also, we may want to completly disable the search for matching
local object files if we load minidumps unless we can prove that the
local image matches the one from the crash origin.
(not part of this change, see: llvm.org/pr35193)
Example: Identify the module from a stack frame PC:
Before:
thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14
frame #0: 0x00164d14
frame #1: 0x00167c79
frame #2: 0x00167e6d
frame #3: 0x7510336a
frame #4: 0x77759882
frame #5: 0x77759855
After:
thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14
frame #0: 0x00164d14 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #1: 0x00167c79 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #2: 0x00167e6d C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #3: 0x7510336a C:\Windows\SysWOW64\kernel32.dll
frame #4: 0x77759882 C:\Windows\SysWOW64\ntdll.dll
frame #5: 0x77759855 C:\Windows\SysWOW64\ntdll.dll
Example: target modules list
Before:
error: the target has no associated executable images
After:
[ 0] C:\Windows\System32\MSVCP120D.dll
[ 1] C:\Windows\SysWOW64\kernel32.dll
[ 2] C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
[ 3] C:\Windows\System32\MSVCR120D.dll
[ 4] C:\Windows\SysWOW64\KERNELBASE.dll
[ 5] C:\Windows\SysWOW64\ntdll.dll
NOTE: the minidump format also includes the debug info GUID, so we can
fill-in the module UUID from it, but this part was excluded from this change
to keep the changes simple (the LLDB UUID is hardcoded to be either 16 or
20 bytes, while the CodeView GUIDs are normally 24 bytes)
Differential Revision: https://reviews.llvm.org/D45700
llvm-svn: 330302
Summary:
If the remote stub sends a specific error message instead of just a E??
code, we can use this to display a more informative error message
instead of just the generic "unable to attach" message.
I write a test for this using the SB API.
On the console this will show up like:
(lldb) process attach ...
error: attach failed: <STUB-MESSAGE>
if the stub supports error messages, or:
error: attach failed: Error ??
if it doesn't.
Reviewers: jingham, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D45573
llvm-svn: 330247
We don't really care about the order as this is a dictionary.
It should be more resilient to changes (adding/shuffling stats
around).
Pointed out by Jason Molenda in a post-commit review (thanks Jason).
llvm-svn: 330170
This allows us to collect useful metrics about lldb debugging sessions.
I thought that an example would be better than a thousand words:
Process 19705 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x0000000100000fb4 blah`main at blah.c:3
1 int main(void) {
2 int a = 6;
-> 3 return 0;
4 }
(lldb) statistics enable
(lldb) frame var a
(int) a = 6
(lldb) expr a
(int) $1 = 6
(lldb) statistics disable
(lldb) statistics dump
Number of expr evaluation successes : 1
Number of expr evaluation failures : 0
Number of frame var successes : 1
Number of frame var failures : 0
Future improvements might include:
1. Passing a file, or implementing categories. The way this patch has
been implemented is generic enough to allow this to be extended
easily without breaking the grammar.
2. Adding an SBAPI and Python API for use in scripts.
Thanks to Jim Ingham for discussing the design with me.
<rdar://problem/36555975>
Differential Revision: https://reviews.llvm.org/D45547
llvm-svn: 330043
Many IDEs set breakpoints using absolute paths and this causes problems when the full path of the source file path doesn't match what is in the debug info. This can be due to different build systems and do or do not resolve symlinks. This patch allows relative breakpoint to be set correctly without needing to do any target.source-map tricks. If IDEs want to, they can send down relative paths like:
./main.c
./src/main.c
src/main.c
foo/bar/src/main.c
I used the breakpoint resolver to match on the file basename and then we weed out anything whose relative paths don't match. This will be a huge improvement for IDEs as they can specify as much of a relative path as desired to uniquely identify a source file in the current project.
Differential Revision: https://reviews.llvm.org/D45592
llvm-svn: 330028
When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread share a protocol ID. Instead, we should iterate over the memory
threads to find the virtual thread that is backed by the current real
thread.
Differential revision: https://reviews.llvm.org/D45497
rdar://36485830
The original revision (r329891) was reverted because the associated
tests ran into a deadlock on the Linux bots. That problem was resolved
by r330002.
llvm-svn: 330005
When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread share a protocol ID. Instead, we should iterate over the memory
threads to find the virtual thread that is backed by the current real
thread.
Differential revision: https://reviews.llvm.org/D45497
rdar://36485830
llvm-svn: 329891
Summary:
With the upstream implementation of dsymutil containing almost all
functionality from the one shipped with Xcode, we want to use the
in-tree version for running the test suite.
This will also allow us to re-enable TestUnicodeSymbols which was
failing because of the discrepancy in how Unicode symbols were hashed in
lldb and older versions of dsymutil.
Reviewers: aprantl, davide, jingham, labath
Subscribers: mgorny, llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45518
llvm-svn: 329889
Summary:
In one of the 2 places the LC_BUILD_VERSION load command is handled, there
is a bug preventing us from actually handling them (the address where to
read the load command was not updated). This patch factors reading the
deployment target load commands into a helper and adds testing for the 2
code paths calling the helper.
The testing is a little bit complicated because the only times those load
commands matter is when debugging a simulator process. I added a new
decorator to check that a specific SDK is available. The actual testing was
fairly easy once I knew how to run a simulated process.
Reviewers: jasonmolenda, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D45298
llvm-svn: 329374
Davide Italiano