summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process
Commit message (Collapse)AuthorAgeFilesLines
...
* typedef enum -> enumFangrui Song2019-05-144-14/+11
| | | | | | | | Reviewed By: labath Differential Revision: https://reviews.llvm.org/D61883 llvm-svn: 360654
* ARMDefines.h: fix -Wimplicit-fallthrough in -DLLVM_ENABLE_ASSERTIONS=OFF buildsFangrui Song2019-05-141-2/+3
| | | | | | | | Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D61844 llvm-svn: 360646
* Fix file names in file headers. NFCFangrui Song2019-05-131-1/+1
| | | | llvm-svn: 360554
* minidump: Don't eagerly resolve module paths read from the minidumpPavel Labath2019-05-101-1/+0
| | | | | | | | 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
* Minidump: use ThreadList parsing code from llvm/ObjectPavel Labath2019-05-108-91/+36
| | | | llvm-svn: 360412
* RegisterContextLLDB: Push CFA value on DWARF stack when evaluating register ↵Pavel Labath2019-05-071-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | expressions Summary: This behavior is specified in the Section 6.4.2.3 (Register Rule instructions) of the DWARF4 spec. We were not doing that, which meant that any register rule which was relying on the cfa value being there was not evaluated correctly (it was aborted due to "out of bounds" access). I'm not sure how come this wasn't noticed before, but I guess this has something to do with the fact that dwarf unwind expressions are not used very often, and when they are, the situation is so complicated that the CFA is of no use. I noticed this when I started emitting dwarf expressions for the unwind information present in breakpad symbol files. Reviewers: jasonmolenda, clayborg Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D61018 llvm-svn: 360158
* C.128 override, virtual keyword handlingRaphael Isemann2019-05-032-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: According to [C128] "Virtual functions should specify exactly one of `virtual`, `override`, or `final`", I've added override where a virtual function is overriden but the explicit `override` keyword was missing. Whenever both `virtual` and `override` were specified, I removed `virtual`. As C.128 puts it: > [...] writing more than one of these three is both redundant and > a potential source of errors. I anticipate a discussion about whether or not to add `override` to destructors but I went for it because of an example in [ISOCPP1000]. Let me repeat the comment for you here: Consider this code: ``` struct Base { virtual ~Base(){} }; struct SubClass : Base { ~SubClass() { std::cout << "It works!\n"; } }; int main() { std::unique_ptr<Base> ptr = std::make_unique<SubClass>(); } ``` If for some odd reason somebody removes the `virtual` keyword from the `Base` struct, the code will no longer print `It works!`. So adding `override` to destructors actively protects us from accidentally breaking our code at runtime. [C128]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c128-virtual-functions-should-specify-exactly-one-of-virtual-override-or-final [ISOCPP1000]: https://github.com/isocpp/CppCoreGuidelines/issues/1000#issuecomment-476951555 Reviewers: teemperor, JDevlieghere, davide, shafik Reviewed By: teemperor Subscribers: kwk, arphaman, kadircet, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61440 llvm-svn: 359868
* RegisterContextLLDB::GetFullUnwindPlanForFrame has four verboseJason Molenda2019-05-021-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | logging messages that are written the same, making it difficult to know for certain which code path was taken based on a logfile. Add some words to make each unique. Right now the ordering for finding a FullUnwindPlan (ignoring fallback unwind plan logic) is 1. If this is a _sigtramp like function, try eh_frame which is hand written on darwin systems to account for finding the saved register context correctly. 2. Ask the DynamicLoader if eh_frame should be preferred for this frame. Some binaries on the system may have hand-written eh_frame and the DynamicLoader is the source for this. (primarily this is for hand-written assembly in the objc runtime, and we tell lldb to trust that for functions in libobjc.dylib.) 3. if 0th frame, use GetUnwindPlanAtNonCallSite plan. 4. GetUnwindPlanAtCallSite {for 0th or any other} 5. GetUnwindPlanAtNonCallSite {now for non-0th frames, only if not from a compiler? hm.} 6. GetUnwindPlanArchitectureDefaultAtFunctionEntry if we're on the first instruction 7. Architectural default unwind plan ABI::CreateDefaultUnwindPlan I'm moving #6 -- DefaultAtFunctionEntry -- up to between #3 and #4, where we're already doing things specific to the zeroth frame. If we're on the zeroth frame and the GetUnwindPlanAtNonCallSite plan has failed for some reason, and we're on the first instruction, we should definitely use DefaultAtFunctionEntry instead of any other unwind plan. If we're trying to step out of some rando function on the system that we couldn't assembly instruction inspect, this is sufficient for us to step out of it. llvm-svn: 359847
* gdb-remote: fix the build on WindowsSaleem Abdulrasool2019-05-021-0/+3
| | | | | | | Windows does not have a definition for `mode_t`. Include the appropriate header. llvm-svn: 359816
* gdb-remote: reduce some inclusion of Target/Process.hSaleem Abdulrasool2019-05-027-7/+7
| | | | | | | Reduce the inclusion of Target/Process.h to help isolate why Process is being preserved during the build of `lldb-server`. llvm-svn: 359811
* Fix MSVC buildPavel Labath2019-05-022-2/+2
| | | | | | | | Address an ambiguity between lldb_private::Thread and llvm::minidump::Thread. Follow-up to llvm r359762 (which introduced the second type). llvm-svn: 359765
* [CMake] Correct lldbPluginProcessPOSIX dependenciesAlex Langford2019-05-011-1/+1
| | | | | | | This plugin does not depend on lldbInterpreter. It only depends on lldbUtility. llvm-svn: 359645
* [lldb] [Process/NetBSD] Fix handling piod_len from PT_IO callsMichal Gorny2019-04-301-4/+4
| | | | | | | | | | | | | | | | | | | | | | Fix bugs in piod_len return value processing in ReadMemory() and WriteMemory() methods. In particular, add support for piod_len == 0 indicating EOF, and fix summing bytes_read/bytes_written when PT_IO does partial reads/writes. The EOF condition could happen if LLDB attempts to read past vm.maxaddress, e.g. as a result of RBP containing large (invalid) value. Previously, the 0 return caused the function to retry reading via PT_IO indefinitely, effectively deadlooping lldb-server. Partial reads probably did not occur in practice, yet they would cause ReadMemory() to return incorrect bytes_read and/or overwrite previously read data. WriteMemory() suffered from analoguous problems. Differential Revision: https://reviews.llvm.org/D61310 llvm-svn: 359572
* [Windows] Dump more information about access violation exceptionAleksandr Urakov2019-04-292-0/+72
| | | | | | | | | | | | | | | | | | | | Summary: Dump more information about "access violation" and "in page error" exceptions to description. Description now contains data about read/write violation type and actual address as described at https://docs.microsoft.com/en-us/windows/desktop/api/winnt/ns-winnt-_exception_record Reviewers: asmith, stella.stamenova Reviewed By: stella.stamenova Subscribers: teemperor, amccarth, abidh, lldb-commits, aleksandr.urakov Tags: #lldb Differential Revision: https://reviews.llvm.org/D60519 llvm-svn: 359420
* [ScriptInterpreter] Move ownership into debugger (NFC)Jonas Devlieghere2019-04-261-1/+1
| | | | | | | | | | | | | | This is part two of the change started in r359330. This patch moves the ownership of the script interpreter from the command interpreter into the debugger. I would've preferred to remove the lazy initialization, however the fact that the scripting language is set after the debugger is created makes that tricky. So for now this does exactly the same thing as when it was under the command interpreter. The result is that this patch is fully NFC. Differential revision: https://reviews.llvm.org/D61211 llvm-svn: 359354
* [lldb] Use local definition of get_cpuid_countJoseph Tremoulet2019-04-241-1/+18
| | | | | | | | | | | | | | | | | | Summary: This is needed for gcc/cstdlib++ 5.4.0, where __get_cpuid_count is not defined in cpuid.h. Reviewers: labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61036 llvm-svn: 359120
* FuncUnwinders: remove "current_offset" from function argumentsPavel Labath2019-04-231-14/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This argument was added back in 2010 (r118882) to support the ability to unwind from functions whose eh_frame entry does not cover the entire range of the function. However, due to the caching happening in FuncUnwinders, this solution is very fragile. FuncUnwinders will cache the plan it got from eh_frame regardless of the value of the current_offset, so our ability to unwind from a given function depended what was the value of "current_offset" the first time that this function was called. Furthermore, since the "image show-unwind" command did not know what's the right offset to pass, this created an unfortunate situation where "image show-unwind" would show no valid plans for a function, even though they were available and being used. In this patch I implement the feature slightly differently. Instead of giving just a base address to the eh_frame unwinder, I give it the entire range we are interested in. Then, I change the unwinder to return the first plan that covers (even partially) that range. This way even a partial plan will be returned, regardless of the address in the function where we are stopped at. This solution is still not 100% correct, as it will not handle a function which is covered by two independent fde entries. However, I don't expect anybody will write this kind of functions, and this wasn't handled by the previous implementation either. If this is ever needed in the future. The eh_frame unwinder can be extended to return "composite" unwind plans created by merging sevelar fde entries. I also create a test which triggers this scenario. As doing this is virtually impossible without hand-written assembly, the test only works on x86 linux. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60829 llvm-svn: 358964
* [Process] Fix linux arm64 single step compilation failureAlex Langford2019-04-161-0/+1
| | | | | | | | This was updated in r356703 to use llvm::sys::RetryAfterSignal, which comes from llvm/Support/Errno.h. The header wasn't added, so it fails if you compile for arm64/aarch64. llvm-svn: 358530
* [lldb] [Process/NetBSD] Fix wrongly mapping mm* registersMichal Gorny2019-04-111-2/+2
| | | | | | | | | | | | | Fix mistake that mapped mm* registers into the space for xmm* registers, rather than the one shared with st* registers. In other words, 'register read mmN' now correctly shows the mmN register rather than part of xmmN. Includes a minimal lit regression test. Differential Revision: https://reviews.llvm.org/D60325 llvm-svn: 358178
* Minidump: extend UUID byte-swapping to windows platformPavel Labath2019-04-112-34/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-10113-595/+0
| | | | | | | | | | | | | | | | | | | | | | | A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
* Minidump: Use llvm parser for reading the ModuleList streamPavel Labath2019-04-105-109/+34
| | | | | | | | In this patch, I just remove the structure definitions for the ModuleList stream and the associated parsing code. The rest of the code is converted to work with the definitions in llvm. NFC. llvm-svn: 358070
* Minidump: use string parsing functionality from llvmPavel Labath2019-04-095-94/+30
| | | | llvm-svn: 357977
* Rename Target::GetSharedModule to Target::GetOrCreateModule.Jason Molenda2019-04-083-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a flag to control whether the ModulesDidLoad notification is called when a module is added. If the notifications are disabled, the caller must call ModulesDidLoad after adding all the new modules, but postponing this notification until they're all batched up can allow for better efficiency than notifying one-by-one. Change the name of the ModuleList notifier functions that a subclass can implement to start with 'Notify' to make it clear what they are. Add a NotifyModulesRemoved. Add header documentation for the changed/updated methods. Added defaulted-value 'notify' argument to ModuleList Append, AppendIfNeeded, and Remove because callers working with a local ModuleList don't have an obvious idea of what notify means in this context. When the ModuleList is a part of the Target class, the notify behavior matters. DynamicLoaderDarwin has been updated so that libraries being added/removed are correctly batched up before notifications are sent. Added the TestModuleLoadedNotifys.py test to run on Darwin to test this. <rdar://problem/48293064> Differential Revision: https://reviews.llvm.org/D60172 llvm-svn: 357955
* Experiment with a larger packet timeout.Adrian Prantl2019-04-081-2/+2
| | | | | | | | This is a follow-up to r357829 (https://reviews.llvm.org/D60340) to see whether increasing the packet timeout for non-asan builds could also positively affect the stability of non-asan bots. llvm-svn: 357954
* MinidumpParser: parse SystemInfo stream via llvmPavel Labath2019-04-082-18/+7
| | | | | | | I also update the tests for SystemInfo parsing to use the yaml2minidump capabilities in llvm instead of relying on checked-in binaries. llvm-svn: 357896
* Unify random timeouts throughout LLDB and make them configurable.Adrian Prantl2019-04-052-4/+10
| | | | | | | | | | | | | | | | | Since these timeouts guard against catastrophic error in debugserver, I also increased all of them to the maximum value among them. The motivation for this test was the observation that an asanified LLDB would often exhibit seemingly random test failures that could be traced back to debugserver packets getting out of sync. With this path applied I can no longer reproduce the one particular failure mode that I was investigating. rdar://problem/49441261 Differential Revision: https://reviews.llvm.org/D60340 llvm-svn: 357829
* MinidumpParser: use minidump parser in llvm/ObjectPavel Labath2019-04-054-118/+23
| | | | | | | | | | | | | | | | | | This patch removes the lower layers of the minidump parsing code from the MinidumpParser class, and replaces it with the minidump parser in llvm. Not all functionality is already avaiable in the llvm class, but it is enough for us to be able to stop enumerating streams manually, and rely on the minidump directory parsing code from the llvm class. This also removes some checked-in binaries which were used to test error handling in the parser, as the error handling is now done (and tested) in llvm. Instead I just add one test that ensures we correctly propagate the errors reported by the llvm parser. The input for this test can be written in yaml instead of a checked-in binary. llvm-svn: 357748
* Attempt #2 to get this patch working. I will watch the build bots carefully ↵Greg Clayton2019-04-031-7/+35
| | | | | | | | | | | | | | | | 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
* Avoid macro redefinition error if HAVE_LIBCOMPRESSIONJason Molenda2019-04-031-0/+2
| | | | | | is already defined. llvm-svn: 357553
* Revert r357504, r357491, r357482 because of bot breakage.Adrian Prantl2019-04-021-35/+7
| | | | | | | | | | | | | 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
* Allow partial UUID matching in Minidump core file plug-inGreg Clayton2019-04-021-7/+35
| | | | | | | | | | | | 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
* [lldb] [Process/elf-core] Support aarch64 NetBSD core dumpsMichal Gorny2019-04-013-0/+34
| | | | | | | | | | | 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
* [Linux/x86] Fix writing of non-gpr registers on newer processorsPavel Labath2019-04-012-51/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We're using ptrace(PTRACE_SETREGSET, NT_X86_XSTATE) to write all non-gpt registers on x86 linux. Unfortunately, this method has a quirk, where the kernel rejects all attempts to write to this area if one supplies a buffer which is smaller than the area size (even though the kernel will happily accept partial reads from it). This means that if the CPU supports some new registers/extensions that we don't know about (in my case it was the PKRU extension), we will fail to write *any* non-gpr registers, even those that we know about. Since this is a situation that's likely to appear again and again, I add code to NativeRegisterContextLinux_x86_64 to detect the runtime size of the area, and allocate an appropriate buffer. This does not mean that we will start automatically supporting all new extensions, but it does mean that the new extensions will not prevent the old ones from working. This fixes tests attempting to write to non-gpr registers on new intel processors (cca Kaby Lake Refresh). Reviewers: jankratochvil, davezarzycki Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D59991 llvm-svn: 357376
* minidump: Add ability to attach (breakpad) symbol files to placeholder modulesPavel Labath2019-03-271-43/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-commits r354263, which was because it uncovered with handling of modules with empty (zero) UUIDs. This would cause us to treat two modules as intentical even though they were not. This caused an assert in PlaceholderObjectFile::SetLoadAddress to fire, because we were trying to load the module twice even though it was designed to be only loaded at a specific address. (The same problem also existed with the previous implementation, but it had no asserts to warn us about this.) These issues have now been fixed in r356896. windows bot. The issue there was that ObjectFilePECOFF vended its base address through the incorrect interface. SymbolFilePDB depended on that, which lead to assertion failures when SymbolFilePDB was attempting to use the placeholder object files as a base. This has been fixed in r354258 The original commit message was: The reason this wasn't working was that ProcessMinidump was creating odd object-file-less modules, and SymbolFileBreakpad required the module to have an associated object file because it needed to get its base address. This fixes that by introducing a PlaceholderObjectFile to serve as a dummy object file. The general idea for this is taken from D55142, but I've reworked it a bit to avoid the need for the PlaceholderModule class. Now that we have an object file, our modules are sufficiently similar to regular modules that we can use the regular Module class almost out of the box -- the only thing I needed to tweak was the Module::CreateModuleFromObjectFile functon to set the module's FileSpec in addition to it's architecture. This wasn't needed for ObjectFileJIT (the other user of CreateModuleFromObjectFile), but it shouldn't hurt it either, and the change seems like a straightforward extension of this function. Reviewers: clayborg, lemo, amccarth Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D57751 llvm-svn: 357060
* Fix an out-of-bounds error in RegisterContextDarwin_arm64Pavel Labath2019-03-271-2/+3
| | | | | | | | | | | | | | | | | Summary: gcc diagnoses this as "array subscript 63 is above array bounds of 'RegisterContextDarwin_arm64::VReg [32]'". The correct fix seems to be subtracting the fpu register base index, but I have no way of verifying that this actually works. Reviewers: jasonmolenda Subscribers: javed.absar, kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D59495 llvm-svn: 357055
* Minidump: Use minidump types defined in llvmPavel Labath2019-03-265-180/+82
| | | | | | | | This is the next step in moving the minidump parsing into llvm. I remove the minidump structures already defined in the llvm Object library and convert our parser to use those. NFC. llvm-svn: 356992
* [lldb] [Process/NetBSD] Use nullptr to fix template arg deductionMichal Gorny2019-03-251-1/+1
| | | | llvm-svn: 356960
* Minidump: Use minidump constants defined in llvmPavel Labath2019-03-256-193/+62
| | | | | | | | | | | | | | | This patch begins the process of migrating the "minidump" plugin to the minidump parser in llvm. The llvm parser is not fully finished yet, but even now, a lot of things can be switched over. The gradual migration process will allow us to easier detect if things break than doing a big one-step migration. Doing it early will allow us to make sure that the llvm parser fits the use case that we need in lldb. In this patch I start with the various minidump constants, which have their llvm equivalent. It doesn't contain any functional changes. The diff just reflects the different naming of things in llvm. llvm-svn: 356898
* Reapply minidump changes reverted in r356806Pavel Labath2019-03-252-24/+51
| | | | | | | | | 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
* [Reproducers] Fix GDB remote flakiness during replayJonas Devlieghere2019-03-221-24/+23
| | | | | | | | | | | | | | | | | | | | | | This fixes the flakiness of the GDB remote reproducer during replay. It was caused by a combination sending one ACK to many from the replay server and the code that "flushes" any queued GDB remote packets in GDBRemoteCommunicationClient::HandshakeWithServer. The spurious ACK was the result of combining both implicit and explicit handling of ACKs in the replay server. The handshake consists of an ACK followed by an QStartNoAckMode. As long as we haven't seen any QStartNoAckMode, we were sending implicit acknowledgments. So the first ACK got acknowledged twice, once implicitly, and once as part of the replay. The reason we didn't notice this was the code in HandshakeWithServer that "waits for any responses that might have been queued up in the remote GDB server and flush them all". A 10ms timeout is used to move on when no packets are left. If the second ACK didn't make it within those 10ms, all packets were offset by one. llvm-svn: 356825
* Revert minidump changesJonas Devlieghere2019-03-221-36/+13
| | | | | | | | | | | | | | 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
* Extend r356573 (minidump UUID handling) to cover elf build-ids tooPavel Labath2019-03-221-1/+1
| | | | | | | | 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
* [Reproducers] Fix log statementsJonas Devlieghere2019-03-211-3/+3
| | | | | | This isn't python where you can omit the index inside `{}`. llvm-svn: 356725
* [lldb] Add missing EINTR handlingMichal Gorny2019-03-213-6/+12
| | | | | | Differential Revision: https://reviews.llvm.org/D59606 llvm-svn: 356703
* [Reproducers] Properly handle QEnvironment packetsJonas Devlieghere2019-03-211-0/+15
| | | | | | | | On Linux, a QEnvironment packet is sent for every environment variable. This breaks replay when the number of environment variables is different then during capture. The solution is to always reply with OK. llvm-svn: 356643
* [Reproducers] Log inconsistencies during replay (NFC)Jonas Devlieghere2019-03-212-5/+41
| | | | | | | | Make debugging of the GDB remote packet aspect of reproducers easier by logging both requests and replies. This enables some sanity checking during replay. llvm-svn: 356638
* Fix UUID decoding from minidump filesGreg Clayton2019-03-201-12/+35
| | | | | | | | | | | | | 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 "type qualifiers ignored on cast result type" warningsPavel Labath2019-03-182-13/+10
| | | | | | These warnings start to get emitted with gcc-8. llvm-svn: 356362
* [Reproducers] Fix data race found by tsanJonas Devlieghere2019-03-141-0/+2
| | | | | | | | This fixes a data race uncovered by tsan during destruction of the GDBRemoteReplay server. The solution is to lock the thread state mutex when receiving packets. llvm-svn: 356168
OpenPOWER on IntegriCloud