summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote
Commit message (Collapse)AuthorAgeFilesLines
...
* [NFC] Move dumping into GDBRemotePacketJonas Devlieghere2019-09-161-5/+2
| | | | | | | | This moves the dumping logic from the GDBRemoteCommunicationHistory class into the GDBRemotePacket so that it can be reused from the reproducer command object. llvm-svn: 372028
* [Reproducer] Move GDB Remote Packet into Utility. (NFC)Jonas Devlieghere2019-09-1310-153/+34
| | | | | | | | | | | | | | To support dumping the reproducer's GDB remote packets, we need the (de)serialization logic to live in Utility rather than the GDB remote plugin. This patch renames StreamGDBRemote to GDBRemote and moves the relevant packet code there. Its uses in the GDBRemoteCommunicationHistory and the GDBRemoteCommunicationReplayServer are updated as well. Differential revision: https://reviews.llvm.org/D67523 llvm-svn: 371907
* [Reproducer] Move GDB Remote Provider into Reproducer (NFC)Jonas Devlieghere2019-09-111-42/+4
| | | | | | | | | | | | | | Originally the idea was for providers to be defined close to where they are used. While this helped designing the providers in such a way that they don't depend on each other, it also means that it's not possible to access them from a central place. This proved to be a problem for some providers and resulted in them living in the reproducer class. The ProcessGDBRemote provider is the last remaining exception. This patch makes things consistent and moves it into the reproducer like the other providers. llvm-svn: 371685
* [Utility] Replace `lldb_private::CleanUp` by `llvm::scope_exit`Jonas Devlieghere2019-09-101-4/+4
| | | | | | | | | This removes the CleanUp class and replaces its usages with llvm's ScopeExit, which has similar semantics. Differential revision: https://reviews.llvm.org/D67378 llvm-svn: 371474
* [Reproducer] Disconnect when the replay server is out of packets.Jonas Devlieghere2019-09-091-3/+3
| | | | | | | | | | | | | | This is a fix for the issue described in r371144. > 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. When the replay server is out of packets we should just disconnect so the debugger doesn't have to do any cleanup that it wouldn't do during capture. llvm-svn: 371459
* Upstream macCatalyst support in debugserver and the macOS dynamic loaderAdrian Prantl2019-09-045-2/+43
| | | | | | | | | | | plugin. Unfortunately the test is currently XFAILed because of missing changes to the clang driver. Differential Revision: https://reviews.llvm.org/D67124 llvm-svn: 370931
* Really fix the type mismatch error in GDBRemoteCommunicationServerCommonPavel Labath2019-08-261-2/+2
| | | | | | | | My previous attempt in attempt in r369904 actually broke the 32bit build because File::Read expects to take a reference to size_t. Fix the warning by using SIZE_MAX to denote failure instead. llvm-svn: 369910
* Fix a type mismatch error in GDBRemoteCommunicationServerCommonPavel Labath2019-08-261-1/+1
| | | | | | | GetU64 returns a uint64_t. Don't store it in size_t as that is only 32-bit on 32-bit platforms. llvm-svn: 369904
* [NFC] Return llvm::StringRef from StringExtractor::GetStringRef.Jonas Devlieghere2019-08-216-37/+32
| | | | | | | | | | This patch removes the two variant of StringExtractor::GetStringRef that return (non-)const references to std::string. The non-const one was being abused to reinitialize the StringExtractor and its uses are replaced by calls to the copy asignment operator. The const variant was refactored to return an actual llvm::StringRef. llvm-svn: 369493
* [lldb] D66174 `RegularExpression` cleanupJan Kratochvil2019-08-201-2/+3
| | | | | | | | | | I find as a good cleanup to drop the Compile method. As I do not find TIMTOWTDI as an advantage and there is already constructor parameter to compile the regex. Differential Revision: https://reviews.llvm.org/D66392 llvm-svn: 369352
* [LLDB] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-1/+1
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368933
* Enable lldb-server on WindowsAaron Smith2019-08-132-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit contains three small changes to enable lldb-server on Windows. - Add lldb-server for Windows to the build - Disable pty redirection on Windows for the initial lldb-server bring up - Add a support to get the parent pid for a process on Windows - Ifdef some signals which aren't supported on Windows Thanks to Hui Huang for the help with this patch! Reviewers: labath Reviewed By: labath Subscribers: JDevlieghere, compnerd, Hui, amccarth, xiaobai, srhines, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61686 llvm-svn: 368774
* [lldb] Fix HAVE_LIBCOMPRESSIONHaibo Huang2019-08-082-4/+2
| | | | | | | | | | | | | | | | Summary: This test doesn't make sense. Change to be consistent with what we did in GDBRemoteCommunication.cpp. Reviewers: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65965 llvm-svn: 368352
* Remove usage of usleep in generic codePavel Labath2019-08-052-6/+7
| | | | | | | | This function is not portable, and there are only a handful of usages of it anyway. Replacing it with std::this_thread::sleep_for enables us to get rid of the compatibility code in PosixApi.h. llvm-svn: 367814
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-051-2/+2
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* [GDBRemote] Reflow comments and improve docs.Jonas Devlieghere2019-07-311-31/+35
| | | | | | | | Improved the GDB client base documentation while I was reading through it. Looks like it got messed up during the automatic comment reflow a while ago. llvm-svn: 367481
* [lldb] Qualify includes of Properties[Enum].inc files. NFCJordan Rupprecht2019-07-293-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a bit more explicit, and makes it possible to build LLDB without varying the -I lines per-directory. (The latter is useful because many build systems only allow this to be configured per-library, and LLDB is insufficiently layered to be split into multiple libraries on stricter build systems). (My comment on D65185 has some more context) Reviewers: JDevlieghere, labath, chandlerc, jdoerfert Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65397 Patch by Sam McCall! llvm-svn: 367241
* [lldb] Also include the array definition in Properties.incJonas Devlieghere2019-07-291-14/+12
| | | | | | | | | | | | | | | | Right now our Properties.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the Properties.inc generate it alongside the initializers. Unfortunately we cannot do the same for enums, as there's this magic ePropertyExperimental, which needs to come at the end to be interpreted correctly. Hopefully we can get rid of this in the future and do the same for the property enums. Differential revision: https://reviews.llvm.org/D65353 llvm-svn: 367238
* Let tablegen generate property definitionsJonas Devlieghere2019-07-253-32/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
* Correctly use GetLoadedModuleList to take advantage of libraries-svr4Antonio Afonso2019-07-252-38/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Here's a replacement for D62504. I thought I could use LoadModules to implement this but in reality I can't because there are at few issues with it: * The LoadModules assumes that the list returned by GetLoadedModuleList is comprehensive in the sense that reflects all the mapped segments, however, this is not true, for instance VDSO entry is not there since it's loaded manually by LoadVDSO using GetMemoryRegionInfo and it doesn't represent a specific shared object in disk. Because of this LoadModules will unload the VDSO module. * The loader (interpreter) module might have also been loaded using GetMemoryRegionInfo, this is true when we launch the process and the rendezvous structure is not yet available (done through LoadInterpreterModule()). The problem here is that this entry will point to the same file name as the one found in /proc/pid/maps, however, when we read the same module from the r_debug.link_map structure it might be under a different name. This is true at least on CentOS where the loader is a symlink. Because of this LoadModules will unload and load the module in a way where the rendezvous breakpoint is unresolved but not resolved again (because we add the new module first and remove the old one after). The symlink issue might be fixable by first unloading the old and loading the news (but sounds super brittle), however, I'm not sure how to fix the VDSO issue. Since I can't trust it I'm just going to use GetLoadedModuleList directly with the same logic that we use today for when we read the linked list in lldb. The only safe thing to do here is to only calculate differences between different snapshots of the svr4 packet itself. This will also cut the dependency this plugin has from LoadModules. I separated the 2 logics into 2 different functions (remote and not remote) because I don't like mixing 2 different logics in the same function with if/else's. Two different functions makes it easier to reason with I believe. However, I did abstract away the logic that decides if we should take a snapshot or add/remove modules so both functions could reuse it. The other difference between the two is that on the UpdateSOEntriesFromRemote I take the snapshot only once when state = Consistent because I didn't find a good reason to always update that, as we already got the list from state = Add | Remove. I probably should use the same logic on UpdateSOEntries though I don't see a reason not to since it's really using the same data, just read in different places. Any thoughts here? It might also be worthwhile to add a test to make sure we don't unload modules that were not actually "unloaded" like the vdso. I haven't done this yet though. This diff is also missing the option for svr4 like proposed in https://reviews.llvm.org/D62503#1564296, I'll start working on this but wanted to have this up first. Reviewers: labath, jankratochvil, clayborg, xiaobai Reviewed By: labath Subscribers: srhines, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64013 llvm-svn: 367020
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-2411-774/+719
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
* Revert "Revert "Implement xfer:libraries-svr4:read packet""Antonio Afonso2019-07-233-0/+46
| | | | | | This reverts commit 08c38f77c5fb4d3735ec215032fed8ee6730b3db. llvm-svn: 366847
* Change LaunchThread interface to return an expected.Jonas Devlieghere2019-07-053-21/+35
| | | | | | | | | Change the interface to return an expected, instead of taking a Status pointer. Differential revision: https://reviews.llvm.org/D64163 llvm-svn: 365226
* Add plugin.process.gdb-remote.use-libraries-svr4 optionAntonio Afonso2019-07-031-7/+36
| | | | | | | | | | | | | | | | | | | | | Summary: This option allow the toggling of the libraries-svr4 usage in ProcessGDBRemote. It's a follow up of https://reviews.llvm.org/D62503#1564296 and it's meant to test / tweak this new packet with, hopefully, minimum impact and in a faster way. Enable it with `settings set plugin.process.gdb-remote.use-libraries-svr4 true`. For now, by default it's false. I didn't put tests up for this but I did test it manually. Reviewers: labath, jankratochvil Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64112 llvm-svn: 365059
* [Reproducer] Assert on unexpected packetJonas Devlieghere2019-07-011-0/+1
| | | | | | | | I'm not able to reproduce the reproducer flakiness we're seeing on GreenDragon. I want to add this assert to find out if the GDB remote packets are somehow getting out of sync when this happens. llvm-svn: 364852
* Revert "Implement xfer:libraries-svr4:read packet"Pavel Labath2019-07-013-46/+0
| | | | | | | | | | | | | | | | | | | D62502, together with D62503 have broken the builds which have XML support enabled. Reverting D62503 (r364355) fixed that, but has broken has left some of the tests introduced by D62502 broken more or less nondeternimistically (it depended on whether the system happens to place the library list near unreadable pages of memory). I attempted to make a partial fix for this in r364748, but Jan Kratochvil pointed out that this reintroduces the problem which reverting D62503 was trying to solve. So instead, I back out the whole thing so we can get back to a clean slate that works for everyone. We can figure out a way forward from there. This reverts r364748, r363772 and r363707. llvm-svn: 364751
* Revert "[GDBRemote] Remove code that flushes GDB remote packets"Jonas Devlieghere2019-06-301-0/+7
| | | | | | | Reverting this again as it doesn't appear to solve the flakiness on the LLDB standalone bot. llvm-svn: 364722
* [GDBRemote] Remove code that flushes GDB remote packetsJonas Devlieghere2019-06-281-7/+0
| | | | | | | | | | | | | | The arbitrary timeout when flushing GDB remote packets caused non-determinism and flakiness between test runs. I suspect it is what's causing the flakiness of the reproducer tests on GreenDragon, and want to see if removing it causes that to go away. This change was originally introduced in r197579 to discard a `$T02thread:01;#4` that QEMU was sending. If anybody knows how to test that this continues working after removing this code, I'd love to hear it. llvm-svn: 364669
* Make sure the thread list is updated before you set the stop reasonJim Ingham2019-06-281-7/+10
| | | | | | | | | | | | | | | on a thread. When talking to some older gdb-remote stubs, We were getting a stop reason from the stop reply packet and setting it on the relevant thread before we updated the full stop list. That would get discarded when the full list was updated. Also, if you already have a thread list when you go to see if there is an Operating System plugin, and you do indeed load a new OS plugin, you have to re-fetch the thread list or it will only show the raw threads. Differential Revision: https://reviews.llvm.org/D62887 llvm-svn: 364666
* [Reproducers] Fix flakiness and off-by-one during replay.Jonas Devlieghere2019-06-271-6/+25
| | | | | | | | | | | | | | | | | | | | | | | This fixes two replay issues that caused the tests to behave erratically: 1. It fixes an off-by-one error, where all replies where shifted by 1 because of a `+` packet that should've been ignored. 2. It fixes another off-by-one-error, where an asynchronous ^C was offsetting all subsequent packets. The reason is that we 'synchronize' requests and replies. In reality, a stop reply is only sent when the process halt. During replay however, we instantly report the stop, as the reply to packets like continue (vCont). Both packets should be ignored, and indeed, checking the gdb-remote log, no unexpected packets are received anymore. Additionally, be more pedantic when it comes to unexpected packets and return an failure form the replay server. This way we should be able to catch these things faster in the future. llvm-svn: 364494
* Support nested target.xml register definition files, lack of reg group markers.Jason Molenda2019-06-262-60/+88
| | | | | | | | | | | | | | | | | | | | | The qemu x86_64 target returns a target.xml register definition file which includes other xml files and they include others, etc. Also, the registers are not put in register groups like lldb wants to see. This patch (1) puts registers that aren't in a register group in a "general" register group, (2) change ProcessGDBRemote::GetGDBServerRegisterInfo to be a method that starts the parsing, asking a recurisve function to fetch and parse target.xml, (3) adds ProcessGDBRemote::GetGDBServerRegisterInfoXMLAndProcess which can recusively call itself to read and parse included xml files, (4) in addition to expecting the top-level <target> element (which only happens in the top level xml file), also an xml file that consists of a <feature> node - read the register defintions and includes from that <feature> element. <rdar://problem/49537922> Differential revision: https://reviews.llvm.org/D63802 llvm-svn: 364484
* Implement xfer:libraries-svr4:read packetAntonio Afonso2019-06-183-0/+46
| | | | | | | | | | | | | | | | | | | Summary: This is the fourth patch to improve module loading in a series that started here (where I explain the motivation and solution): D62499 Implement the `xfer:libraries-svr4` packet by adding a new function that generates the list and then in Handle_xfer I generate the XML for it. The XML is really simple so I'm just using string concatenation because I believe it's more readable than having to deal with a DOM api. Reviewers: clayborg, xiaobai, labath Reviewed By: labath Subscribers: emaste, mgorny, srhines, krytarowski, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62502 llvm-svn: 363707
* [Reproducers] Simplify providers with nested Info struct (NFC)Jonas Devlieghere2019-06-121-11/+8
| | | | | | | | | This replaces the `info` typedef with a nested struct named Info. This means we now have FooProvider and FooProvider::Info, instead of two related but separate classes FooProvider and FooInfo. This change is mostly cosmetic. llvm-svn: 363211
* Add support to read aux vector valuesAntonio Afonso2019-06-112-3/+3
| | | | | | | | | | | | | | | | | | | | Summary: This is the second patch to improve module loading in a series that started here (where I explain the motivation and solution): https://reviews.llvm.org/D62499 I need to read the aux vector to know where the r_debug map with the loaded libraries are. The AuxVector class was made generic so it could be reused between the POSIX-DYLD plugin and NativeProcess*. The class itself ended up in the ProcessUtility plugin. Reviewers: clayborg, xiaobai, labath, JDevlieghere Reviewed By: clayborg, labath, JDevlieghere Subscribers: emaste, JDevlieghere, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62500 llvm-svn: 363098
* Create a generic handler for Xfer packetsAntonio Afonso2019-06-104-63/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first of a few patches I have to improve the performance of dynamic module loading on Android. In this first diff I'll describe the context of my main motivation and will then link to it in the other diffs to avoid repeating myself. ## Motivation I have a few scenarios where opening a specific feature on an Android app takes around 40s when lldb is attached to it. The reason for that is because 40 modules are dynamicly loaded at that point in time and each one of them is taking ~1s. ## The problem To learn about new modules we have a breakpoint on a linker function that is called twice whenever a module is loaded. One time just before it's loaded (so lldb can check which modules are loaded) and another right after it's loaded (so lldb can check again which ones are loaded and calculate the diference). It's figuring out which modules are loaded that is taking quite some time. This is currently done by traversing the linked list of loaded shared libraries that the linker maintains in memory. Each item in the linked list requires its own `x` packet sent to the gdb server (this is android so the network also plays a part). In my scenario there are 400+ loaded libraries and even though we read 0x800 worth of bytes at a time we still make ~180 requests that end up taking 150-200ms. We also do this twice, once before the module is loaded (state = eAdd) and another right after (state = eConsistent) which easly adds up to ~400ms per module. ## A solution **Implement `xfer:libraries-svr4` in lldb-server:** I noticed in the code that loads the new modules that it had support for the `xfer:libraries-svr4` packet (added ~4 years ago to support the ds2 debug server) but we didn't support it in lldb-server. This single packet returns an xml list of all the loaded modules by the process. The advantage is that there's no more need to make 180 requests to read the linked list. Additionally this new requests takes around 10ms. **More efficient usage of the `xfer:libraries-svr4` packet in lldb:** When `xfer:libraries-svr4` is available the Process class has a `LoadModules` function that requests this packet and then loads or unloads modules based on the current list of loaded modules by the process. This is the function that is used by the DYLDRendezvous class to get the list of loaded modules before and after the module is loaded. However, this is really not needed since the LoadModules function already loaded or unloaded the modules accordingly. I changed this strategy to call LoadModules only once (after the process has loaded the module). **Bugs** I found a few issues in lldb while implementing this and have submitted independent patches for them. I tried to devide this into multiple logical patches to make it easier to review and discuss. ## Tests I wanted to put these set of diffs up before having all the tests up and running to start having them reviewed from a techical point of view. I'm also having some trouble making the tests running on linux so I need more time to make that happen. # This diff The `xfer` packages follow the same protocol, they are requested with `xfer:<object>:<read|write>:<annex>:<offset,length>` and a return that starts with `l` or `m` depending if the offset and length covers the entire data or not. Before implementing the `xfer:libraries-svr4` I refactored the `xfer:auxv` to generically handle xfer packets so we can easly add new ones. The overall structure of the function ends up being: * Parse the packet into its components: object, offset etc. * Depending on the object do its own logic to generate the data. * Return the data based on its size, the requested offset and length. Reviewers: clayborg, xiaobai, labath Reviewed By: labath Subscribers: mgorny, krytarowski, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62499 llvm-svn: 362982
* Make ConnectionFileDescription work with all socketsAntonio Afonso2019-05-301-12/+11
| | | | | | | | | | | | | | | | | | | | | Summary: My main goal here is to make lldb-server work with Android Studio. This is currently not the case because lldb-server is started in platform mode listening on a domain socket. When Android Studio connects to it lldb-server crashes because even though it's listening on a domain socket as soon as it gets a connection it asserts that it's a TCP connection, which will obviously fails for any non-tcp connection. To do this I came up with a new method called GetConnectURI() in Socket that returns the URI needed to connect to the connected portion of the socket. Reviewers: labath, clayborg, xiaobai Reviewed By: labath Subscribers: mgorny, jfb, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62089 llvm-svn: 362173
* [lldb-server] Support 'g' packetsPavel Labath2019-05-302-0/+60
| | | | | | | Differential Revision: https://reviews.llvm.org/D62221 Patch by Guilherme Andrade <guiandrade@google.com>. llvm-svn: 362063
* [gdb-remote] Fix more issues with thread_result_tJonas Devlieghere2019-05-232-4/+4
| | | | | | More fixes needed to un-break the Windows bot. llvm-svn: 361539
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-235-80/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
* Simplify Triple::ppc64{,le} checks with Triple::isPPC64()Fangrui Song2019-05-161-5/+5
| | | | | | | | | | While here, update some ppc64le specific check to isPPC64(), if it applies to big-endian as well, in the hope that it will ease the support of big-endian if people are interested in this area. The big-endian variant is used by at least FreeBSD, Gentoo Linux, Adélie Linux, and Void Linux. llvm-svn: 360868
* Simplify ArchSpec::IsMIPS()Fangrui Song2019-05-162-14/+4
| | | | llvm-svn: 360865
* typedef enum -> enumFangrui Song2019-05-141-2/+2
| | | | | | | | Reviewed By: labath Differential Revision: https://reviews.llvm.org/D61883 llvm-svn: 360654
* C.128 override, virtual keyword handlingRaphael Isemann2019-05-031-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* [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
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-1014-114/+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
* 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
* Unify random timeouts throughout LLDB and make them configurable.Adrian Prantl2019-04-051-1/+7
| | | | | | | | | | | | | | | | | 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
* Avoid macro redefinition error if HAVE_LIBCOMPRESSIONJason Molenda2019-04-031-0/+2
| | | | | | is already defined. llvm-svn: 357553
OpenPOWER on IntegriCloud