summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [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
* [Reproducers] Fix log statementsJonas Devlieghere2019-03-211-3/+3
| | | | | | This isn't python where you can omit the index inside `{}`. llvm-svn: 356725
* [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
* [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
* Add XCOFF triple object format type for AIXJason Liu2019-03-121-0/+2
| | | | | | | | | This patch adds an XCOFF triple object format type into LLVM. This XCOFF triple object file type will be used later by object file and assembly generation for the AIX platform. Differential Revision: https://reviews.llvm.org/D58930 llvm-svn: 355989
* [Reproducers] Add a test to ensure we can reuse the reproducer dir.Jonas Devlieghere2019-03-121-1/+1
| | | | | | | | Yesterday I noticed a reproducer test failing after making a local change. Removing the reproducer directory solved the issue. Add a test case that detects this. llvm-svn: 355941
* Bring Doxygen comment syntax in sync with LLVM coding style.Adrian Prantl2019-03-114-27/+27
| | | | | | This changes '@' prefix to '\'. llvm-svn: 355841
* Promote more debug-only assertions to regular assertions.Adrian Prantl2019-03-071-4/+0
| | | | llvm-svn: 355568
* Pass ConstString by value (NFC)Adrian Prantl2019-03-064-4/+4
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* Resubmit "Don't include UnixSignals.h from Host."Zachary Turner2019-03-061-1/+1
| | | | | | | | This was reverted because it breaks the GreenDragon bot, but the reason for the breakage is lost, so I'm resubmitting this now so we can find out what the problem is. llvm-svn: 355528
* Refactor user/group name resolving codePavel Labath2019-03-041-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This creates an abstract base class called "UserIDResolver", which can be implemented to provide user/group ID resolution capabilities for various objects. Posix host implement a PosixUserIDResolver, which does that using posix apis (getpwuid and friends). PlatformGDBRemote forwards queries over the gdb-remote link, etc. ProcessInstanceInfo class is refactored to make use of this interface instead of taking a platform pointer as an argument. The base resolver class already implements caching and thread-safety, so implementations don't have to worry about that. The main motivating factor for this was to remove external dependencies from the ProcessInstanceInfo class (so it can be put next to ProcessLaunchInfo and friends), but it has other benefits too: - ability to test the user name caching code - ability to test ProcessInstanceInfo dumping code - consistent interface for user/group resolution between Platform and Host classes. Reviewers: zturner, clayborg, jingham Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D58167 llvm-svn: 355323
* [lldb] [Process/gdb-remote] Use '127.0.0.1' in ConnectLocally()Michal Gorny2019-03-031-1/+1
| | | | | | | | | | | | | | | | Use '127.0.0.1' instead of 'localhost' in ConnectLocally() function as this is the specific address the server is bound to. Using 'localhost' may involve trying IPv6 first which may accidentally be used by another service. While technically it might be interesting to support IPv6 here, it would need to be supported properly, with the connection copying family and address from the listening socket, and possibly without relying on existence of 'localhost' at all. Differential Revision: https://reviews.llvm.org/D58883 llvm-svn: 355285
* Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cppZachary Turner2019-02-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Given that we have a target named Symbols, one wonders why a file named Symbols.cpp is not in this target. To be clear, the functions exposed from this file are really focused on *locating* a symbol file on a given host, which is where the ambiguity comes in. However, it makes more sense conceptually to be in the Symbols target. While some of the specific places to search for symbol files might change depending on the Host, this is not inherently true in the same way that, for example, "accessing the file system" or "starting threads" is fundamentally dependent on the Host. PDBs, for example, recently became a reality on non-Windows platforms, and it's theoretically possible that DSYMs could become a thing on non MacOSX platforms (maybe in a remote debugging scenario). Other types of symbol files, such as DWO, DWP, etc have never been tied to any Host platform anyway. After this patch, there is only one remaining dependency from Host to Target. Differential Revision: https://reviews.llvm.org/D58730 llvm-svn: 355032
* Return better error message from GDBRemoteCommunication::ConnectLocallyPavel Labath2019-02-181-3/+4
| | | | llvm-svn: 354256
* Revert "Don't include UnixSignals.h from Host."Davide Italiano2019-02-151-1/+1
| | | | | | It broke the modules green dragon buildbot. llvm-svn: 354177
* Don't include UnixSignals.h from Host.Zachary Turner2019-02-151-1/+1
| | | | | | | | | | | | | | | | | Host had a function to get the UnixSignals instance corresponding to the current host architecture. This means that Host had to include a file from Target. To break this dependency, just make this a static function directly in UnixSignals. We already have the function UnixSignals::Create(ArchSpec) anyway, so we just need to have UnixSignals::CreateForHost() which determines which value to pass for the ArchSpec. The goal here is to eventually break the Host->Target->Host circular dependency. Differential Revision: https://reviews.llvm.org/D57780 llvm-svn: 354168
* [gdb-remote] Sanity check platform pointerAaron Smith2019-02-141-2/+5
| | | | llvm-svn: 354012
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-131-7/+7
| | | | | | | | | | | | | | | | | The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
* Have Stream::PutCStringAsRawHex8 take llvm::StringRefPavel Labath2019-02-126-42/+42
| | | | | | | | | This enables the function to be called with a StringRef without jumping through any hoops. I rename the function to "PutStringAsRawHex8" to honor the extended interface. I also remove ".c_str()" from any calls to this function I could find. llvm-svn: 353841
OpenPOWER on IntegriCloud