summaryrefslogtreecommitdiffstats
path: root/lldb/lit
Commit message (Collapse)AuthorAgeFilesLines
* Re-land "[test] Split LLDB tests into API, Shell & Unit"Jonas Devlieghere2019-10-09440-20444/+0
| | | | | | | The original patch got reverted because it broke `check-lldb` on a clean build. This fixes that. llvm-svn: 374201
* Update breakpad lit test to be independent of the unnamed symbol numberAntonio Afonso2019-10-091-1/+1
| | | | llvm-svn: 374192
* Revert [test] Split LLDB tests into API, Shell & UnitAdrian Prantl2019-10-09440-0/+20444
| | | | | | | | as it appears to have broken check-lldb. This reverts r374184 (git commit 22314179f0660c172514b397060fd8f34b586e82) llvm-svn: 374187
* [test] Split LLDB tests into API, Shell & UnitJonas Devlieghere2019-10-09440-20444/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLDB has three major testing strategies: unit tests, tests that exercise the SB API though dotest.py and what we currently call lit tests. The later is rather confusing as we're now using lit as the driver for all three types of tests. As most of this grew organically, the directory structure in the LLDB repository doesn't really make this clear. The 'lit' tests are part of the root and among these tests there's a Unit and Suite folder for the unit and dotest-tests. This layout makes it impossible to run just the lit tests. This patch changes the directory layout to match the 3 testing strategies, each with their own directory and their own configuration file. This means there are now 3 directories under lit with 3 corresponding targets: - API (check-lldb-api): Test exercising the SB API. - Shell (check-lldb-shell): Test exercising command line utilities. - Unit (check-lldb-unit): Unit tests. Finally, there's still the `check-lldb` target that runs all three test suites. Finally, this also renames the lit folder to `test` to match the LLVM repository layout. Differential revision: https://reviews.llvm.org/D68606 llvm-svn: 374184
* Explicitly set entry point arch when it's thumb [Second Try]Antonio Afonso2019-10-083-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added. I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb). The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash. This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb. I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code. I also run the following on the command line with the `app_process32` where I found the issue: **Before:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32[0x1640]: .long 0xf0004668 ; unknown opcode ``` **After:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32`: app_process32[0x1640] <+0>: mov r0, sp app_process32[0x1642]: andeq r0, r0, r0 ``` Reviewers: clayborg, labath, wallace, espindola Reviewed By: labath Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines Tags: #lldb Differential Revision: https://reviews.llvm.org/D68533 llvm-svn: 374132
* Add pretty printing of Clang "bitfield" enumsFrederic Riss2019-10-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Using enumerators as flags is standard practice. This patch adds support to LLDB to display such enum values symbolically, eg: (E) e1 = A | B If enumerators don't cover the whole value, the remaining bits are displayed as hexadecimal: (E) e4 = A | 0x10 Detecting whether an enum is used as a bitfield or not is complicated. This patch implements a heuristic that assumes that such enumerators will either have only 1 bit set or will be a combination of previous values. This patch doesn't change the way we currently display enums which the above heuristic would not consider as bitfields. Reviewers: jingham, labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D67520 llvm-svn: 374067
* Tweak minidebuginfo-set-and-hit-breakpoint.testPavel Labath2019-10-081-5/+8
| | | | | | | | | | | On my system, llvm-objcopy was refusing to remove the .dynsym section because it was still referenced from .rela.plt. Remove that section too, and clarify that this is needed only because llvm-objcopy --only-keep-debug does not work (does not set the sections to SHT_NOBITS). Also, ensure that the test is not creating temporary files in the source tree. llvm-svn: 374046
* [CMake] Add two more uses of add_lldb_test_dependencyJonas Devlieghere2019-10-081-1/+1
| | | | llvm-svn: 374000
* [CMake] Track test dependencies with add_lldb_test_dependencyJonas Devlieghere2019-10-081-9/+5
| | | | | | | | | | | | | I often use `ninja lldb-test-deps` to build all the test dependencies before running a subset of the tests with `lit --filter`. This functionality seems to break relatively often because test dependencies are tracked in an ad-hoc way acrooss cmake files. This patch adds a helper function `add_lldb_test_dependency` to unify test dependency tracking by adding dependencies to lldb-test-deps. Differential revision: https://reviews.llvm.org/D68612 llvm-svn: 373996
* [MachO] Fix symbol merging during symtab parsing.Jonas Devlieghere2019-10-081-0/+699
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The symtab parser in ObjectFileMachO has logic to coalesce debug (STAB) and non-debug symbols, based on the address and the symbol name for static (STSYM) and global symbols (GSYM) respectively. It makes the assumption that the debug variant is always encountered first. Rather than creating a second entry in the symbol table for the non-debug symbol, the latter gets merged into the existing debug symbol. This breaks when the linker emits the non-debug symbol first. We'd end up with two entries in the symbol table, each containing part of the information LLDB relies on. Indeed, commenting out the merging logic breaks the test suite spectacularly. This patch solves that problem by always parsing the debug symbols first. This guarantees that the assumption for merging holds. I'm not particularly happy with adding a lambda, but after numerous attempts this is the best solution I could come up with. The symtab parsing logic is pretty complex in that it touches a lot of things. I've experienced first hand that it's very easy to break things. I believe this approach strikes a balance between fixing the issue while limiting the risk of regressions. Differential revision: https://reviews.llvm.org/D68536 llvm-svn: 373994
* [test] Rename `Modules` to `ObjectFile` (NFC)Jonas Devlieghere2019-10-0762-0/+0
| | | | llvm-svn: 373955
* [lldb][ELF] Read symbols from .gnu_debugdata sect.Konrad Kleine2019-10-078-0/+192
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If the .symtab section is stripped from the binary it might be that there's a .gnu_debugdata section which contains a smaller .symtab in order to provide enough information to create a backtrace with function names or to set and hit a breakpoint on a function name. This change looks for a .gnu_debugdata section in the ELF object file. The .gnu_debugdata section contains a xz-compressed ELF file with a .symtab section inside. Symbols from that compressed .symtab section are merged with the main object file's .dynsym symbols (if any). In addition we always load the .dynsym even if there's a .symtab section. For example, the Fedora and RHEL operating systems strip their binaries but keep a .gnu_debugdata section. While gdb already can read this section, LLDB until this patch couldn't. To test this patch on a Fedora or RHEL operating system, try to set a breakpoint on the "help" symbol in the "zip" binary. Before this patch, only GDB can set this breakpoint; now LLDB also can do so without installing extra debug symbols: lldb /usr/bin/zip -b -o "b help" -o "r" -o "bt" -- -h The above line runs LLDB in batch mode and on the "/usr/bin/zip -h" target: (lldb) target create "/usr/bin/zip" Current executable set to '/usr/bin/zip' (x86_64). (lldb) settings set -- target.run-args "-h" Before the program starts, we set a breakpoint on the "help" symbol: (lldb) b help Breakpoint 1: where = zip`help, address = 0x00000000004093b0 Once the program is run and has hit the breakpoint we ask for a backtrace: (lldb) r Process 10073 stopped * thread #1, name = 'zip', stop reason = breakpoint 1.1 frame #0: 0x00000000004093b0 zip`help zip`help: -> 0x4093b0 <+0>: pushq %r12 0x4093b2 <+2>: movq 0x2af5f(%rip), %rsi ; + 4056 0x4093b9 <+9>: movl $0x1, %edi 0x4093be <+14>: xorl %eax, %eax Process 10073 launched: '/usr/bin/zip' (x86_64) (lldb) bt * thread #1, name = 'zip', stop reason = breakpoint 1.1 * frame #0: 0x00000000004093b0 zip`help frame #1: 0x0000000000403970 zip`main + 3248 frame #2: 0x00007ffff7d8bf33 libc.so.6`__libc_start_main + 243 frame #3: 0x0000000000408cee zip`_start + 46 In order to support the .gnu_debugdata section, one has to have LZMA development headers installed. The CMake section, that controls this part looks for the LZMA headers and enables .gnu_debugdata support by default if they are found; otherwise or if explicitly requested, the minidebuginfo support is disabled. GDB supports the "mini debuginfo" section .gnu_debugdata since v7.6 (2013). Reviewers: espindola, labath, jankratochvil, alexshap Reviewed By: labath Subscribers: rnkovacs, wuzish, shafik, emaste, mgorny, arichardson, hiraditya, MaskRay, lldb-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D66791 llvm-svn: 373891
* Revert "Explicitly set entry point arch when it's thumb"Antonio Afonso2019-10-041-13/+0
| | | | | | | | Backing out because SymbolFile/Breakpad/symtab.test is failing and it seems to be a legit issue. Will investigate. This reverts commit 72153f95ee4c1b52d2f4f483f0ea4f650ec863be. llvm-svn: 373687
* Explicitly set entry point arch when it's thumbAntonio Afonso2019-10-041-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb). The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash. This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb. I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code. I also run the following on the command line with the `app_process32` where I found the issue: **Before:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32[0x1640]: .long 0xf0004668 ; unknown opcode ``` **After:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32`: app_process32[0x1640] <+0>: mov r0, sp app_process32[0x1642]: andeq r0, r0, r0 ``` Reviewers: clayborg, labath, wallace, espindola Subscribers: srhines, emaste, arichardson, kristof.beyls, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68069 llvm-svn: 373680
* [test] Disable TestCustomShell on LinuxJonas Devlieghere2019-10-031-0/+4
| | | | | | | ShellExpandArguments is unimplemented on Linux. I need to come up with another way to test this on Linux. llvm-svn: 373662
* [Host] Return the user's shell from GetDefaultShellJonas Devlieghere2019-10-032-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | LLDB handles shell expansion by running lldb-argdumper under a shell. Currently, this is always /bin/sh on POSIX. This potentially leads to different behavior between lldb and the user's current shell. Here's an example of different expansions between shells: $ /bin/bash -c 'echo -config={Options:[{key:foo_key,value:foo_value}]}' -config={Options:[key:foo_key]} -config={Options:[value:foo_value]} $ /bin/zsh -c 'echo -config={Options:[{key:foo_key,value:foo_value}]}' zsh:1: no matches found: -config={Options:[key:foo_key]} $ /bin/sh -c 'echo -config={Options:[{key:foo_key,value:foo_value}]}' -config={Options:[key:foo_key]} -config={Options:[value:foo_value]} $ /bin/fish -c 'echo -config={Options:[{key:foo_key,value:foo_value}]}' -config=Options:[key:foo_key] -config=Options:[value:foo_value] To reduce surprises, this patch returns the user's current shell. It first looks at the SHELL environment variable. If that isn't set, it'll ask for the user's default shell. Only if that fails, we'll fallback to /bin/sh, which should always be available. Differential revision: https://reviews.llvm.org/D68316 llvm-svn: 373644
* Use llvm for dumping DWARF expressionsPavel Labath2019-09-302-3/+3
| | | | | | | | | | | | | | | Summary: It uses the new ability of ABI plugins to vend llvm::MCRegisterInfo structs (which is what is needed to turn dwarf register numbers into strings). Reviewers: JDevlieghere, aprantl, jasonmolenda Subscribers: tatyana-krasnukha, lldb-commits Differential Revision: https://reviews.llvm.org/D67966 llvm-svn: 373208
* [Reproducer] Always use absolute paths for capture & replay.Jonas Devlieghere2019-09-271-0/+8
| | | | | | | | | | | The VFS requires files to be have absolute paths. The file collector makes paths relative to the reproducer root. If the root is a relative path, this would trigger an assert in the VFS. This patch ensures that we always make the given path absolute. Thank you Ted Woodward for pointing this out! llvm-svn: 373102
* Unwind: Add a stack scanning mechanism to support win32 unwindingPavel Labath2019-09-273-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Windows unwinding is weird. The unwind rules do not (always) describe the precise layout of the stack, but rather expect the debugger to scan the stack for something which looks like a plausible return address, and the unwind based on that. The reason this works somewhat reliably is because the the unwinder also has access to the frame sizes of the functions on the stack. This allows it (in most cases) to skip function pointers in local variables or function arguments, which could otherwise be mistaken for return addresses. Implementing this kind of unwind mechanism in lldb was a bit challenging because we expect to be able to statically describe (in the UnwindPlan) structure, the layout of the stack for any given instruction. Giving a precise desription of this is not possible, because it requires correlating information from two functions -- the pushed arguments to a function are considered a part of the callers stack frame, and their size needs to be considered when unwinding the caller, but they are only present in the unwind entry of the callee. The callee may end up being in a completely different module, or it may not even be possible to determine it statically (indirect calls). This patch implements this functionality by introducing a couple of new APIs: SymbolFile::GetParameterStackSize - return the amount of stack space taken up by parameters of this function. SymbolFile::GetOwnFrameSize - the size of this function's frame. This excludes the parameters, but includes stuff like local variables and spilled registers. These functions are then used by the unwinder to compute the estimated location of the return address. This address is not always exact, because the stack may contain some additional values -- for instance, if we're getting ready to call a function then the stack will also contain partially set up arguments, but we will not know their size because we haven't called the function yet. For this reason the unwinder will crawl up the stack from the return address position, and look for something that looks like a possible return address. Currently, we assume that something is a valid return address if it ends up pointing to an executable section. All of this logic kicks in when the UnwindPlan sets the value of CFA as "isHeuristicallyDetected", which is also the final new API here. Right now, only SymbolFileBreakpad implements these APIs, but in the future SymbolFilePDB will use them too. Differential Revision: https://reviews.llvm.org/D66638 llvm-svn: 373072
* [lit] Do a better job at parsing unsupported tests.Jonas Devlieghere2019-09-251-0/+5
| | | | | | | | | | | | | When all the tests run by dotest are unsupported, it still reports RESULT: PASSED which we translate to success for lit. We can better report the status as unsupported when we see that there are unsupported tests but no passing tests. This will not affect the situation where there are failures or unexpected passes, because those report a non-zero exit code. Differential revision: https://reviews.llvm.org/D68039 llvm-svn: 372914
* [LLDB] Add tests for PECOFF arm architecture identificationMartin Storsjo2019-09-242-0/+172
| | | | | | | | | | | | | | | Add a test case for the change from SVN r372657, and for the preexisting ARM identification. Add a missing ArchDefinitionEntry for PECOFF/arm64, and tweak the ArmNt case to set the architecture to armv7 (ArmNt never ran on anything lower than that). (This avoids a case where ArchSpec::MergeFrom would override the arch from arm to armv7 and ArchSpec::CoreUpdated would reset the OS to unknown at the same time.) Differential Revision: https://reviews.llvm.org/D67951 llvm-svn: 372741
* [LLDB] [test] Allow differing order of some matchesMartin Storsjo2019-09-241-2/+2
| | | | | | | | | These can appear in a different order depending on the relative layout of the source and build trees. Differential Revision: https://reviews.llvm.org/D67953 llvm-svn: 372740
* [LLDB] [test] Add a few missing cases of REQUIRES: pythonMartin Storsjo2019-09-242-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D67952 llvm-svn: 372739
* Fix command-script-import.test on linuxPavel Labath2019-09-182-3/+3
| | | | | | | | | | | | | | | | | | The test was expecting the value of "lldb.frame" to be None, because it is cleared after each python interpreter session. However, this is not true in the very first session, because lldb.py sets these values to invalid objects (lldb.SBFrame(), etc.). I have not investigated why is it that this test passes on darwin, but my guess is that this is because we do extra work on darwin (loading the objc runtime, etc), which causes us to enter the python interpreter sooner. This patch changes lldb.py to also initialize these values to None, as that seems to make more sense. I also fixed some typos in the test while I was in there. llvm-svn: 372222
* [lldb] Fix a test assertion after r372192Krasimir Georgiev2019-09-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The `CHECK: frame:py: None` seems to have been a typo, causing build bot failures: ``` # CHECK: frame:py: None ^ <stdin>:1:1: note: scanning from here (lldb) command source -s 0 'E:/build_slave/lldb-x64-windows-ninja/build/tools/lldb\lit\lit-lldb-init' ^ <stdin>:23:1: note: possible intended match here frame:py: No value ^ ``` This update fixes the build bots. -- Reviewers: bkramer Reviewed By: bkramer Differential Revision: https://reviews.llvm.org/D67702 llvm-svn: 372221
* [ScriptInterpreter] Limit LLDB's globals to interactive mode.Jonas Devlieghere2019-09-182-3/+7
| | | | | | | | | | | Jim pointed out that the LLDB global variables should only be available in interactive mode. When used from a command for example, their values might be stale or not at all what the user expects. Therefore we want to explicitly make these variables unavailable. Differential revision: https://reviews.llvm.org/D67685 llvm-svn: 372192
* lldb: move a test input to the test Inputs dirKrasimir Georgiev2019-09-172-1/+3
| | | | | | | | | | Summary: This makes the input file for a new test added in r372060 directly available in the Inputs subdirectory of the test dir. Differential Revision: https://reviews.llvm.org/D67655 llvm-svn: 372112
* [test] Disable reproducer dump test on WindowsJonas Devlieghere2019-09-171-0/+1
| | | | llvm-svn: 372064
* [ScriptInterpreter] Initialize globals when loading a scripting module.Jonas Devlieghere2019-09-172-0/+10
| | | | | | | | | | | | | The LoadScriptingModule used by command script import wasn't initializing the LLDB global variables (things like `lldb.frame` and `lldb.debugger`). They would get initialized however when running the interactive script interpreter or running a single script line (e.g. `script print(lldb.frame)`). This patch fixes that by properly initializing the globals when loading a Python module. Differential revision: https://reviews.llvm.org/D67644 llvm-svn: 372060
* [Reproducer] Implement dumping packets.Jonas Devlieghere2019-09-161-0/+4
| | | | | | | | | This patch completes the dump functionality by adding support for dumping a reproducer's GDB remote packets. Differential revision: https://reviews.llvm.org/D67636 llvm-svn: 372046
* [test] Add -z separate-code to fix tests that ae sensitive to exact ↵Fangrui Song2019-09-166-6/+6
| | | | | | addresses after r371958 llvm-svn: 371962
* [Reproducer] Add reproducer dump command.Jonas Devlieghere2019-09-132-0/+22
| | | | | | | | | | | This adds a reproducer dump commands which makes it possible to inspect a reproducer from inside LLDB. Currently it supports the Files, Commands and Version providers. I'm planning to add support for the GDB Remote provider in a follow-up patch. Differential revision: https://reviews.llvm.org/D67474 llvm-svn: 371909
* Revert "[LLDB][ELF] Load both, .symtab and .dynsym sections"Konrad Kleine2019-09-115-101/+1
| | | | | | This reverts commit 3a4781bbf4f39a25562b4c61c9a9ab2483a96b41. llvm-svn: 371625
* Revert "[LLDB][ELF] Fixup for comments in D67390"Konrad Kleine2019-09-112-2/+2
| | | | | | This reverts commit 813f05915d29904878d926f9849ca3dbe78096af. llvm-svn: 371624
* [LLDB][ELF] Fixup for comments in D67390Konrad Kleine2019-09-112-2/+2
| | | | llvm-svn: 371600
* [LLDB][ELF] Load both, .symtab and .dynsym sectionsKonrad Kleine2019-09-115-1/+101
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change ensures that the .dynsym section will be parsed even when there's already is a .symtab. It is motivated because of minidebuginfo (https://sourceware.org/gdb/current/onlinedocs/gdb/MiniDebugInfo.html#MiniDebugInfo). There it says: Keep all the function symbols not already in the dynamic symbol table. That means the .symtab embedded inside the .gnu_debugdata does NOT contain the symbols from .dynsym. But in order to put a breakpoint on all symbols we need to load both. I hope this makes sense. My other patch D66791 implements support for minidebuginfo, that's why I need this change. Reviewers: labath, espindola, alexshap Subscribers: JDevlieghere, emaste, arichardson, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67390 llvm-svn: 371599
* Revert "[Reproducer] Add a `cont` to ModuleCXX.test"Jonas Devlieghere2019-09-091-1/+0
| | | | | | This should no longer be necessary after r371459. llvm-svn: 371460
* [test] Add a FIXME test for stop-command-source-on-errorJonas Devlieghere2019-09-063-0/+30
| | | | | | | | | | | | | | Modifying the interpreter settings is tricky because they don't take effect until we create a new command interpreter, which should be merely an implementation detail. This leads to confusing and unexpected scenarios. This adds a test cases with FIXMEs for some of the odd scenarios I encountered. I didn't XFAIL the test because I don't think there's a way to get an unexpected PASS if any of the commands succeeds and splitting up the file in multiple tests seems excessive. llvm-svn: 371259
* [Reproducer] Add a `cont` to ModuleCXX.testJonas Devlieghere2019-09-051-0/+1
| | | | | | | | | | On more than one occasion I've found this test got stuck during replay while waiting for a packet from debugserver when the debugger was in the process of being destroyed. For some reason it's more prevalent on the downstream Swift fork. Adding a cont mitigates the problem while I investigate. llvm-svn: 371144
* Breakpad: Basic support for STACK WIN unwindingPavel Labath2019-09-053-0/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch makes it possible to unwind via breakpad STACK WIN records. It is "basic" because two important features are missing: - support for the .raSearch keyword - support for multiple STACK WIN records within a single function Right now, we just reject the .raSearch records, and always pick the first record for the whole function SymbolFileBreakpad, and so I think it can serve as a good example of what is needed of the symbol file and unwinding machinery to make this work. However, it is already useful for unwinding in some situations, and it sets up the general framework for the parsing of these kinds of records, which reduces the size of the followup patches implementing the two other components. Reviewers: amccarth, rnk, markmentovai Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D67067 llvm-svn: 371017
* disassemble command: fix error message when disassembly failsPavel Labath2019-09-042-0/+49
| | | | | | | | | | | | | We were printing the start_addr field, which is not correct, as in this branch we are processing the memory described by cur_range. Print that instead. Ideally, in particular this case, the error message would also say something about not being able to disassemble due to not having found the module from the core file, but that is not easy to do right now, so I'm leaving that for another time. llvm-svn: 370898
* [lit] Only set DYLD_LIBRARY_PATH for shared buildsJonas Devlieghere2019-08-303-9/+8
| | | | | | | | | | | | In r370135 I committed a temporary workaround for the sanitized bot to not set (DY)LD_LIBRARY_PATH when (DY)LD_INSERT_LIBRARIES was set. Setting (DY)LD_LIBRARY_PATH is only necessary for (standalone) shared-library builds, so a better solution is to only set the environment variable when necessary. Differential revision: https://reviews.llvm.org/D67012 llvm-svn: 370549
* [lit] Fix my earlier bogus fix to not set DYLD_LIBRARY_PATH with Asan.Jonas Devlieghere2019-08-301-1/+1
| | | | | | | | | | | | | My follow-up commit to mess with DYLD_LIBRARY_PATH was bogus for two reasons: - The condition was inverted. - We were checking the OS's environment, instead of the config's. Two wrongs don't make a right, but the second mistake meant that the sanitizer bot passed. llvm-svn: 370483
* [lit] Print exit code in for unresolved (lldb)tests.Jonas Devlieghere2019-08-291-2/+2
| | | | | | | | | | | | A test is marked unresolved when we're unable to find PASSED or FAILED in the dotest output. Usually this is because we crashed and when that happens the exit code can give a clue as to why. This patch adds the exit code to the lit output to make it easier to investigate those issues. Differential revision: https://reviews.llvm.org/D66975 llvm-svn: 370413
* [test] Fix various module cache bugs and inconsistenciesJonas Devlieghere2019-08-298-7/+27
| | | | | | | | | | | | | | | | | Currently, lit tests don't set neither the module cache for building inferiors nor the module cache used by lldb when running tests. Furthermore, we have several places where we rely on the path to the module cache being always the same, rather than passing the correct value around. This makes it hard to specify a different module cache path when debugging a a test. This patch reworks how we determine and pass around the module cache paths and fixes the omission on the lit side. It also adds a sanity check to the lit and dotest suites. Differential revision: https://reviews.llvm.org/D66966 llvm-svn: 370394
* Remove DWARFExpression::LocationListSizePavel Labath2019-08-291-8/+32
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The only reason for this function's existance is so that we could pass the correct size into the DWARFExpression constructor. However, there is no harm in passing the entire data extractor into the DWARFExpression, since the same code is performing the size determination as well as the subsequent parse. So, if we get malformed input or there's a bug in the parser, we'd compute the wrong size anyway. Additionally, reducing the number of entry points into the location list parsing machinery makes it easier to switch the llvm debug_loc(lists) parsers. While inside, I added a couple of tests for invalid location list handling. Reviewers: JDevlieghere, clayborg Subscribers: aprantl, javed.absar, kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D66789 llvm-svn: 370373
* [dotest] Remove -q (quiet) flag.Jonas Devlieghere2019-08-281-1/+1
| | | | | | | | | | | | | | This patch removes the -q (quiet) flag and changing the default behavior. Currently the flag serves two purposes that are somewhat contradictory, as illustrated by the difference between the argument name (quiet) and the configuration flag (parsable). On the one hand it reduces output, but on the other hand it prints more output, like the result of individual tests. My proposal is to guard the extra output behind the verbose flag and always print the individual test results. Differential revision: https://reviews.llvm.org/D66837 llvm-svn: 370226
* [lit] Fix the way we check if an environment var is setJonas Devlieghere2019-08-281-1/+1
| | | | | | The old method would throw a KeyError. llvm-svn: 370138
* [lit] Don't set DYLD_LIBRARY_PATH when DYLD_INSERT_LIBRARIES is set.Jonas Devlieghere2019-08-281-13/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | Setting DYLD_INSERT_LIBRARIES to the Asan runtime and DYLD_LIBRARY_PATH to the LLVM shared library dir causes the test suite to crash with a segfault. We see this on the LLDB sanitized bot [1] on GreenDragon. I've spent some time investigating, but I'm not sure what's going on (yet). Originally I thought this was because we were building compiler-rt and were loading an incompatible, just-built Asan library. However, the issue persists even without compiler-rt. It doesn't look like the Asan runtime is opening any other libraries that might be found in LLVM's shared library dir and talking to the team confirms that. Another possible explanation is that we're loading lldb form a place we don't expect, but that doesn't make sense either, because DYLD_LIBRARY_PATH is always set without the crash. I tried different Python versions and interpreters but the issue persist. As a (temporary?) workaround I propose not setting DYLD_LIBRARY_PATH when DYLD_INSERT_LIBRARIES is set so we can turn the Asan bot on again and get useful results. [1] http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-sanitized/ Differential revision: https://reviews.llvm.org/D66845 llvm-svn: 370135
* Upstream support for macCatalyst Mach-O binaries.Adrian Prantl2019-08-231-2/+12
| | | | | | | | | | | | On macOS one Mach-O slice can contain multiple load commands: One load command for being loaded into a macOS process and one load command for being loaded into a macCatalyst process. This patch adds support for the new load command and makes sure ObjectFileMachO returns the Architecture that matches the Module. Differential Revision: https://reviews.llvm.org/D66626 llvm-svn: 369814
OpenPOWER on IntegriCloud