| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that don't actually call 'print()'
Summary:
A lot of tests do this trick but the vast majority of them don't even call `print()`.
Most of this patch was generated by a script that just looks at all the files and deletes the line if there is no `print (` or `print(` anywhere else in the file.
I checked the remaining tests manually and deleted the import if we never call print (but instead do stuff like `expr print(...)` and similar false-positives).
I also corrected the additional empty lines after the import in the files that I manually edited.
Reviewers: JDevlieghere, labath, jfb
Reviewed By: labath
Subscribers: dexonsmith, wuzish, nemanjai, kbarton, christof, arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71452
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The architecture enum contains two kinds of contstants: the "official" ones
defined by Microsoft, and unofficial constants added by breakpad to cover the
architectures not described by the first ones.
Up until now, there was no big need to differentiate between the two. However,
now that Microsoft has defined
https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/ns-sysinfoapi-system_info
a constant for ARM64, we have a name clash.
This patch renames all breakpad-defined constants with to include the prefix
"BP_". This frees up the name "ARM64", which I'll re-introduce with the new
"official" value in a follow-up patch.
Reviewers: amccarth, clayborg
Subscribers: lldb-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D69285
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The minidump exception stream can report an exception record with
signal 0. If we try to create a stop reason with signal zero, processing
of the stop event won't find anything, and the debugger will hang.
So, simply early-out of RefreshStateAfterStop in this case.
Also set the UnixSignals object in DoLoadCore as is done for
ProcessElfCore.
Reviewers: labath, clayborg, jfb
Reviewed By: labath, clayborg
Subscribers: dexonsmith, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68096
llvm-svn: 375244
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: labath, jhenderson, clayborg, MaskRay, grimar
Reviewed By: grimar
Subscribers: lldb-commits, grimar, MaskRay, hiraditya, llvm-commits
Tags: #llvm, #lldb
Differential Revision: https://reviews.llvm.org/D68657
llvm-svn: 375242
|
|
|
|
| |
llvm-svn: 375234
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
different paths.
Summary: The PlaceholderObjectFile has an assert in SetLoadAddress that fires if "m_base == value" is not true. To avoid this, we create check that the base address matches, and if it doesn't we clear the module that was found using the UUID so that we create a new PlaceholderObjectFile. Added a test to cover this issue.
Reviewers: labath, aadsm, dvlahovski
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68106
llvm-svn: 374242
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this fix, ELF files might contain PT_LOAD program headers that had a valid p_vaddr, and a valid file p_offset, but the p_filesz would be zero. For example in llvm-project/lldb/test/testcases/functionalities/postmortem/elf-core/thread_crash/linux-i386.core we see:
Program Headers:
Index p_type p_flags p_offset p_vaddr p_paddr p_filesz p_memsz p_align
======= ---------------- ---------- ------------------ ------------------ ------------------ ------------------ ------------------ ------------------
[ 0] PT_NOTE 0x00000000 0x0000000000000474 0x0000000000000000 0x0000000000000000 0x0000000000001940 0x0000000000000000 0x0000000000000000
[ 1] PT_LOAD 0x00000005 0x0000000000002000 0x0000000008048000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000
[ 2] PT_LOAD 0x00000004 0x0000000000002000 0x000000000804b000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 3] PT_LOAD 0x00000006 0x0000000000002000 0x000000000804c000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 4] PT_LOAD 0x00000006 0x0000000000002000 0x0000000009036000 0x0000000000000000 0x0000000000000000 0x0000000000025000 0x0000000000001000
[ 5] PT_LOAD 0x00000000 0x0000000000002000 0x00000000f63a1000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 6] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f63a2000 0x0000000000000000 0x0000000000000000 0x0000000000800000 0x0000000000001000
[ 7] PT_LOAD 0x00000000 0x0000000000002000 0x00000000f6ba2000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 8] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f6ba3000 0x0000000000000000 0x0000000000000000 0x0000000000804000 0x0000000000001000
[ 9] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f73a7000 0x0000000000000000 0x0000000000000000 0x00000000001b1000 0x0000000000001000
[ 10] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7558000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000
[ 11] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f755a000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 12] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f755b000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000
[ 13] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f755e000 0x0000000000000000 0x0000000000000000 0x0000000000019000 0x0000000000001000
[ 14] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7577000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 15] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f7578000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 16] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f7579000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000
[ 17] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f757b000 0x0000000000000000 0x0000000000000000 0x000000000001c000 0x0000000000001000
[ 18] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7597000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 19] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f7598000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 20] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f7599000 0x0000000000000000 0x0000000000000000 0x0000000000053000 0x0000000000001000
[ 21] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f75ec000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 22] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f75ed000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 23] PT_LOAD 0x00000005 0x0000000000002000 0x00000000f75ee000 0x0000000000000000 0x0000000000000000 0x0000000000176000 0x0000000000001000
[ 24] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f7764000 0x0000000000000000 0x0000000000000000 0x0000000000006000 0x0000000000001000
[ 25] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f776a000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 26] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f776b000 0x0000000000000000 0x0000000000000000 0x0000000000003000 0x0000000000001000
[ 27] PT_LOAD 0x00000006 0x0000000000002000 0x00000000f778a000 0x0000000000000000 0x0000000000000000 0x0000000000002000 0x0000000000001000
[ 28] PT_LOAD 0x00000004 0x0000000000002000 0x00000000f778c000 0x0000000000000000 0x0000000000002000 0x0000000000002000 0x0000000000001000
[ 29] PT_LOAD 0x00000005 0x0000000000004000 0x00000000f778e000 0x0000000000000000 0x0000000000002000 0x0000000000002000 0x0000000000001000
[ 30] PT_LOAD 0x00000005 0x0000000000006000 0x00000000f7790000 0x0000000000000000 0x0000000000000000 0x0000000000022000 0x0000000000001000
[ 31] PT_LOAD 0x00000004 0x0000000000006000 0x00000000f77b3000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 32] PT_LOAD 0x00000006 0x0000000000006000 0x00000000f77b4000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0000000000001000
[ 33] PT_LOAD 0x00000006 0x0000000000006000 0x00000000ffa25000 0x0000000000000000 0x0000000000000000 0x0000000000022000 0x0000000000001000
Prior to this fix if users tried to read memory from one of these addresses like 0x8048000, they would end up incorrectly reading from the next memory region that actually had a p_filesz which would be 0x00000000f778c000 in this case. This fix correctly doesn't include program headers with zero p_filesz in the ProcessELFCore::m_core_aranges that is used to read memory. I found two cores files that have this same issue and added tests.
Differential Revision: https://reviews.llvm.org/D67370
llvm-svn: 371457
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Instead of each test case knowing its depth relative to the test root,
we can just have dotest add the folder containing Makefile.rules to the
include path.
This was motivated by r370616, though I have been wanting to do this
ever since we moved to building tests out-of-tree.
The only manually modified files in this patch are lldbinline.py and
plugins/builder_base.py. The rest of the patch has been produced by this
shell command:
find . \( -name Makefile -o -name '*.mk' \) -exec sed --in-place -e '/LEVEL *:\?=/d' -e '1,2{/^$/d}' -e 's,\$(LEVEL)/,,' {} +
Reviewers: teemperor, aprantl, espindola, jfb
Subscribers: emaste, javed.absar, arichardson, christof, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D67083
llvm-svn: 370845
|
|
|
|
|
|
|
|
|
|
|
| |
the platform in the setUp/tearDown methods. I want to migrate the
re-instatement of the correct plaform to the setUp base method but
haven't had time to look at that yet, so I want to land this handful
of fixes until I get to it.
Differential revision: https://reviews.llvm.org/D66331
llvm-svn: 369484
|
|
|
|
| |
llvm-svn: 367663
|
|
|
|
|
|
| |
This test was originally marked as expected failure on Windows, but it is timing out instead of outright failing now. The expectedFailure attribute does not correctly track timeouts (as in, they don't count as failures), so now this is causing the test suite to fail.
llvm-svn: 365527
|
|
|
|
|
|
|
|
|
| |
Replace checked-in minidumps with their yaml forms now that yaml2obj
supports the ThreadList stream. I delete the test_modules_in_mini_dump
test altogether as this functionality is covered more systematically in
TestMinidumpUUID.py.
llvm-svn: 360655
|
|
|
|
|
|
|
|
| |
This can cause us to return paths to files on the local filesystem even
if we don't end up using that file (for instance because the file is not
a real module).
llvm-svn: 360432
|
|
|
|
|
|
| |
After Aaron's commit for ObjectFilePECOFF:: GetUUID, the tests are now passing
llvm-svn: 359573
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Instead of checking in raw minidump binaries, check in their yaml form,
and call yaml2obj in the test.
Reviewers: clayborg
Subscribers: javed.absar, lldb-commits
Differential Revision: https://reviews.llvm.org/D60948
llvm-svn: 358957
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
D59433 and D60501 changed the way UUIDs are computed from minidump
files. This was done to synchronize the U(G)UID representation with the
native tools of given platforms, but it created a mismatch between
minidumps and breakpad files.
This updates the breakpad algorithm to match the one found in minidumps,
and also adds a couple of tests which should fail if these two ever get
out of sync. Incidentally, this means that the module id in the breakpad
files is almost identical to our notion of UUIDs, so the computation
algorithm can be somewhat simplified.
llvm-svn: 358500
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
D59433 added code to swap bytes UUIDs coming from minidump files, but
only enabled it for apple platforms. Based on my research, I believe
this is the correct thing to do for windows as well, as the natural way
of printing U(G)UIDs on this platforms is to print the first three
components as (4 or 2)-byte integers printed in natural (big-endian)
order. This makes the UUID string coming out of lldb match the strings
produced by other windows tools.
The decision to byte-swap the age field is somewhat arbitrary, because
the age field is usually printed separately from the file GUID (and
often in decimal). However, for our purposes (telling whether two files
are identical), including it in the UUID is correct, and printing it in
big-endian makes it easier to recognize the age value.
This also makes the UUIDs generated here (almost) match up with the
UUIDs computed for breakpad symbol files
(BreakpadRecords.cpp:parseModuleId), which already implemented the
byte-swapping. The "almost" is here because ObjectFileBreakpad does not
swap the age field, but I'll fix that in a follow-up.
There is no UUID support in ObjectFileCOFF at the moment, but ideally
the algorithms used here and in ObjectFileCOFF should be in sync so that
object file matching works correctly.
Reviewers: clayborg, amccarth, markmentovai, asmith
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60501
llvm-svn: 358169
|
|
|
|
|
|
| |
The test is passing on Windows and the windows bot is failing because of the unexpected pass
llvm-svn: 357641
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
today.
Allow partial UUID matching in Minidump core file plug-in
Breakpad had bugs in earlier versions where it would take a 20 byte ELF build ID and put it into the minidump file as a 16 byte PDB70 UUID with an age of zero. This would make it impossible to do postmortem debugging with one of these older minidump files.
This fix allows partial matching of UUIDs. To do this we first try and match with the full UUID value, and then fall back to removing the original directory path from the module specification and we remove the UUID requirement, and then manually do the matching ourselves. This allows scripts to find symbols files using a symbol server, place them all in a directory, use the "setting set target.exec-search-paths" setting to specify the directory, and then load the core file. The Target::GetSharedModule() can then find the correct file without doing any other matching and load it.
Tests were added to cover a partial UUID match where the breakpad file has a 16 byte UUID and the actual file on disk has a 20 byte UUID, both where the first 16 bytes match, and don't match.
Differential Revision: https://reviews.llvm.org/D60001
llvm-svn: 357603
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See discussion in https://reviews.llvm.org/D60001.
Revert Clean up windows build bot.
This reverts r357504 (git commit 380c2420ecb0c3e809b04f385d37b89800df1ecf)
Revert Fix buildbot where paths were not matching up.
This reverts r357491 (git commit 5050586860140b55a0cc68c77dd1438f44a23ca5)
Revert Allow partial UUID matching in Minidump core file plug-in
This reverts r357482 (git commit 838bba9c34bf1e5500c2e100327bc764afc8d367)
llvm-svn: 357534
|
|
|
|
| |
llvm-svn: 357504
|
|
|
|
| |
llvm-svn: 357491
|
|
|
|
|
|
|
|
|
|
|
|
| |
Breakpad had bugs in earlier versions where it would take a 20 byte ELF build ID and put it into the minidump file as a 16 byte PDB70 UUID with an age of zero. This would make it impossible to do postmortem debugging with one of these older minidump files.
This fix allows partial matching of UUIDs. To do this we first try and match with the full UUID value, and then fall back to removing the original directory path from the module specification and we remove the UUID requirement, and then manually do the matching ourselves. This allows scripts to find symbols files using a symbol server, place them all in a directory, use the "setting set target.exec-search-paths" setting to specify the directory, and then load the core file. The Target::GetSharedModule() can then find the correct file without doing any other matching and load it.
Tests were added to cover a partial UUID match where the breakpad file has a 16 byte UUID and the actual file on disk has a 20 byte UUID, both where the first 16 bytes match, and don't match.
Differential Revision: https://reviews.llvm.org/D60001
llvm-svn: 357482
|
|
|
|
|
|
|
|
|
|
|
| |
Include support for NetBSD core dumps from evbarm/aarch64 system,
and matching test cases for them.
Based on earlier work by Kamil Rytarowski.
Differential Revision: https://reviews.llvm.org/D60034
llvm-svn: 357399
|
|
|
|
|
|
|
|
|
| |
The changes were reverted due to ubsan errors (unaligned accesses). Here
I fix those errors by first copying the data into aligned storage.
Besides fixing alignment issues, this also fixes reading of minidump
strings on big-endian systems.
llvm-svn: 356896
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts the following two commits:
Revert "Extend r356573 (minidump UUID handling) to cover elf build-ids too"
Revert "Fix UUID decoding from minidump files"
Greg's original commit broke the sanitizer bot which has been red for
several days now.
http://green.lab.llvm.org/green/view/LLDB/job/lldb-sanitized/
llvm-svn: 356806
|
|
|
|
|
|
|
|
| |
Breakpad (but not crashpad) will insert an empty (all-zero) build-id
record for modules which do not have a build-id. This tells lldb to
treat such records as empty/invalid uuids.
llvm-svn: 356751
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes:
UUIDs now don't include the age field from a PDB70 when the age is zero. Prior to this they would incorrectly contain the zero age which stopped us from being able to match up the UUID with real files.
UUIDs for Apple targets get the first 32 bit value and next two 16 bit values swapped. Breakpad incorrectly swaps these values when it creates darwin minidump files, so this must be undone so we can match up symbol files with the minidump modules.
UUIDs that are all zeroes are treated as invalid UUIDs. Breakpad will always save out a UUID, even if one wasn't available. This caused all files that have UUID values of zero to be uniqued to the first module that had a zero UUID. We now don't fill in the UUID if it is all zeroes.
Added tests for PDB70 and ELF build ID based CvRecords.
Differential Revision: https://reviews.llvm.org/D59433
llvm-svn: 356573
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Apparently the problem is harder than anticipated. Skip the test for
now to fix buildbots.
llvm-svn: 355750
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Core files need to know the size of the PRSTATUS header so that we can grab the register values that follow it. The code that figure out this size was using a hard coded list of architecture cores instead of relying on 32 or 64 bit for most cores.
The fix here fixes core files for 32 bit ARM. Prior to this the PRSTATUS header size was being returned as zero and the register values were being taken from the first bytes of the PRSTATUS struct (signo, etc).
Differential Revision: https://reviews.llvm.org/D58985
llvm-svn: 355526
|
|
|
|
|
|
|
| |
It turns out all that was needed to get this test passing was to fix the
python3 incompatibility.
llvm-svn: 354278
|
|
|
|
|
|
|
| |
- dictionaries don't have iteritems()
- division returns floats
llvm-svn: 354273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
|
|
| |
Both of these are now passing. I've resolved the bugs as well for verification.
llvm-svn: 349783
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D55841
llvm-svn: 349767
|
|
|
|
|
|
|
|
|
|
| |
region" command
Prior to this change we would show the name of the section that a memory region belonged to but not its actual region name. Now we show this,. Added a test that reuses the regions-linux-map.dmp minidump file to test this and verify the correct region names for various memory regions.
Differential Revision: https://reviews.llvm.org/D55854
llvm-svn: 349658
|
|
|
|
| |
llvm-svn: 349122
|
|
|
|
|
|
|
| |
Patch by Eugene Birukov <eugenebi@microsoft.com>
Differential Revision: https://reviews.llvm.org/D49685
llvm-svn: 340841
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this patch I add support for ARM and ARM64 break pad files. There are two flavors of ARM: Apple where FP is R7, and non Apple where FP is R11. Added minimal tests that load up ARM64 and the two flavors or ARM core files with a single thread and known register values in each register. Each register is checked for the exact value.
This is a fixed version of: https://reviews.llvm.org/D49750
The changes from D49750 are:
Don't init the m_arch in the Initialize call as a system info isn't required. This keeps the thread list, module list and other tests from failing
Added -Wextended-offsetof to Xcode project so we catch use extended usages of offsetof before submission
Fixed any extended offset of warnings
Differential Revision: https://reviews.llvm.org/D50336
llvm-svn: 339032
|
|
|
|
|
|
|
|
| |
This reverts commit r338734 (and subsequent fixups in r338772 and
r338746), because it breaks some minidump unit tests and introduces a
lot of compiler warnings.
llvm-svn: 338828
|
|
|
|
|
|
|
|
| |
In this patch I add support for ARM and ARM64 break pad files. There are two flavors of ARM: Apple where FP is R7, and non Apple where FP is R11. Added minimal tests that load up ARM64 and the two flavors or ARM core files with a single thread and known register values in each register. Each register is checked for the exact value.
Differential Revision: https://reviews.llvm.org/D49750
llvm-svn: 338734
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
To successfully open a core file, we need to have LLVM built with
support for the relevant target. Right now, if one does not have the
appropriate targets configured, the tests will fail.
This patch uses the GetBuildConfiguration SB API to inform the test (and
anyone else who cares) about the list of supported LLVM targets. The
test then uses this information to approriately skip the tests.
Reviewers: clayborg, jingham
Subscribers: martong, lldb-commits
Differential Revision: https://reviews.llvm.org/D48641
llvm-svn: 335859
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was no way to find out what's wrong if SBProcess SBTarget::LoadCore(const char *core_file) failed.
Additionally, the implementation was unconditionally setting sb_process, so it wasn't even possible to check if the return SBProcess is valid.
This change adds a new overload which surfaces the errors and also returns a valid SBProcess only if the core load succeeds:
SBProcess SBTarget::LoadCore(const char *core_file, SBError &error);
Differential Revision: https://reviews.llvm.org/D48049
llvm-svn: 334439
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: They all correspond to bugs that are already logged and I've added the appropriate (or most appropriate) bug numbers. This leaves only a handful of failing tests.
Reviewers: asmith, zturner, labath
Reviewed By: zturner
Subscribers: eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D47892
llvm-svn: 334210
|
|
|
|
|
|
|
|
| |
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
|