| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 331375
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case we are building with xml enabled, the GetMemoryRegionInfo
function will send extra packets to query te extended memory map, which
the tests were not expecting.
Add an expectation for this to the test. Right now, it's just a basic
one which pretends we don't support the extension, however, it would be
also interesting the add a test which verifies the extension-enabled
case.
I also noticed that the test does a pretty lousy job of validating the
returned memory region info, so I add a couple of extra assertions to
improve that.
llvm-svn: 331374
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This brings the LLDB configuration closer to LLVM's and removes visual
clutter in the source code by removing the @brief commands from
comments.
This patch also reflows the paragraphs in all doxygen comments.
See also https://reviews.llvm.org/D46290.
Differential Revision: https://reviews.llvm.org/D46321
llvm-svn: 331373
|
|
|
|
|
|
|
|
|
| |
The functions are unused, their comments are out of date with the
implementation, and the implementation is out of date with the rest of the code
base (it uses seconds(0) to mean infinite wait, whereas elsewhere we use the
Timeout class).
llvm-svn: 331350
|
|
|
|
|
|
|
| |
Also fix misclassification of char16_t and char32_t: these are unsigned types,
not signed types.
llvm-svn: 331323
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Using GENERATE breaks generators that support multiple configurations,
e.g. MSVC. Reverting for now until we find a better solution.
llvm-svn: 331285
|
|
|
|
|
|
|
|
| |
The lit site configuration for the test suite can contain generator
expressions such as $<TARGET_FILE:debugserver> that need to be
substituted.
llvm-svn: 331277
|
|
|
|
| |
llvm-svn: 331270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 331242
|
|
|
|
| |
llvm-svn: 331239
|
|
|
|
|
|
|
|
| |
cpusubtype that don't map to any known core definition.
<rdar://problem/39779398>
llvm-svn: 331236
|
|
|
|
|
|
|
|
|
|
|
|
| |
that takes a prefix string. This simplifies the implementation and
allows plugins such as the Swift plugin to supply different prefixes
for return and error variables.
rdar://problem/39299889
Differential Revision: https://reviews.llvm.org/D46088
llvm-svn: 331235
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so it can be shared across multiple language plugins.
In a multi-language project it is counterintuitive to have a result
variables reuse numbers just because they are using a different
language plugin in LLDB (but not for example, when they are
Objective-C versus C++, since they are both handled by Clang).
This is NFC on llvm.org except for the Go plugin.
rdar://problem/39299889
Differential Revision: https://reviews.llvm.org/D46083
llvm-svn: 331234
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Multiple DW_TAG_compile_unit being indexed in a multithreaded way can request
reading of the same DW_TAG_partial_unit.
Unfortunately one cannot detect DWZ file ahead of time to disable such locking
overhead as DWARFCompileUnit::Extract does not read the first DIE which is the
only place one could find early enough if the DWARF file is using any
DW_TAG_partial_unit.
Differential revision: https://reviews.llvm.org/D40470
llvm-svn: 331229
|
|
|
|
|
|
|
|
|
|
| |
type that must exist at root level
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
|
|
|
|
|
|
|
|
|
|
| |
Code commonly checks if the parent DIE is DW_TAG_compile_unit.
But DW_TAG_partial_unit also acts as DW_TAG_compile_unit for DWZ
as DWZ is using DW_TAG_imported_unit only at the top unit level.
Differential revision: https://reviews.llvm.org/D40469
llvm-svn: 331194
|
|
|
|
| |
llvm-svn: 331180
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D40468
llvm-svn: 331148
|
|
|
|
| |
llvm-svn: 331082
|
|
|
|
|
|
| |
Of course r331004 needed a counterpart on the write side.
llvm-svn: 331073
|
|
|
|
|
|
|
|
| |
Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed.
Differential Revision: https://reviews.llvm.org/D45977
llvm-svn: 331049
|
|
|
|
|
|
| |
This test will currently fail for people using the system debugserver.
llvm-svn: 331043
|
|
|
|
|
|
|
|
|
| |
The code was grabbing the first plugin, and then never getting
another one.
<rdar://problem/39779438>
llvm-svn: 331012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
source/Symbol/ClangASTContext.cpp:391:13: error: enumeration value 'HIP' not handled in switch [-Werror,-Wswitch]
switch (IK.getLanguage()) {
llvm-svn: 330823
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
windows server
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
|
|
|
|
| |
llvm-svn: 330617
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default packet timeout of 1 second is a bit too small for these
tests, particularly as they are working in ack-mode, which means they
need to fit twice as many packets into the timeslot.
This does not seem to be a problem on the bots, but for some people
these tests are timing out regularly. I can't be sure increasing this
will solve their problem, but this does seem like a likely culprit.
llvm-svn: 330578
|
|
|
|
|
|
|
| |
Only add `dsymutil` as a test dependency when this is not a stand-alone
build (LLDB_BUILT_STANDALONE).
llvm-svn: 330568
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current way that the lit configuration is generated for the LLDB
tests that run using dotest causes cmake to fail when using a generator
which supports multiple configurations (such as Visual Studio). The
failure is because file GENERATE will create a file *per possible
configuration* resulting in the same lit configuration file being
overwritten multiple times.
To fix the issue, we need to create a single lit file that is agnostic
of the configurations and can be used for any configuration.
Patch by: Stella Stamenova
Differential revision: https://reviews.llvm.org/D45918
llvm-svn: 330518
|
|
|
|
|
|
| |
llvm.org/pr37194
llvm-svn: 330504
|
|
|
|
|
|
|
|
|
|
| |
Previously, an attempt to read an unreadable address reported zeros.
Now, if DoReadMemory or DoWriteMemory encounters error then return 0
(bytes read or written) so that the error is reported to the user.
llvm.org/pr37190
llvm-svn: 330500
|
|
|
|
| |
llvm-svn: 330460
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
FileSpec class was moved to the Utility module a while ago, but the test
file was left behind. This corrects that.
llvm-svn: 330405
|
|
|
|
| |
llvm-svn: 330385
|
|
|
|
| |
llvm-svn: 330354
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first in what will hopefully become a series of patches to
replace the driver logic in dotest.py with LIT. The motivation for this
change is that there's no point in maintaining two driver
implementations. Since all of the LLVM projects are using lit, this is
the obvious choice.
Obviously the goal is maintain full compatibility with the functionality
offered by dotest. As such we won't be removing anything until that
point has been reached.
This patch is the initial attempt (referred to as v1) to run the lldb
test suite with lit. To do so we introduced a custom LLDB test format
that invokes dotest.py with a single test file.
Differential revision: https://reviews.llvm.org/D45333
llvm-svn: 330275
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|