summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-241-21/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-18/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-101-4/+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
* Promote more debug-only assertions to regular assertions.Adrian Prantl2019-03-071-4/+0
| | | | llvm-svn: 355568
* Use std::make_shared in LLDB (NFC)Jonas Devlieghere2019-02-111-2/+4
| | | | | | | | | | | Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
* Add a warning to GDBRemoteRegisterContext (if packet logging enabled)Jason Molenda2019-02-061-0/+8
| | | | | | | if the size of the g packet response was smaller than expected and is going to be ignored. llvm-svn: 353269
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Simplify Boolean expressionsJonas Devlieghere2018-12-151-2/+2
| | | | | | | | | | | This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
* Remove header grouping comments.Jonas Devlieghere2018-11-111-4/+0
| | | | | | | | This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-071-2/+2
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-82/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* Move StringExtractorGDBRemote.h to the include folderPavel Labath2018-03-201-1/+1
| | | | | | | | While trying to use this header I noticed that it is not in the include folder. Move it to there and update all #includes to reference that file correctly. llvm-svn: 327996
* Remove unused variable.Tatyana Krasnukha2017-11-221-1/+1
| | | | llvm-svn: 318833
* Rename Error -> Status.Zachary Turner2017-05-121-2/+2
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-041-2/+2
| | | | llvm-svn: 296943
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Break some dependencies in lldbUtility.Zachary Turner2017-02-011-1/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D29359 llvm-svn: 293806
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-766/+731
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Revert "gdb-remote: Make the sequence mutex non-recursive"Pavel Labath2016-08-301-38/+28
| | | | | | This reverts commit r279725 as it breaks "dynamic register size" feature of mips. llvm-svn: 280088
* gdb-remote: Make the sequence mutex non-recursivePavel Labath2016-08-251-28/+38
| | | | | | | | | | | | | | | | | | | | | | | Summary: This is a preparatory commit for D22914, where I'd like to replace this mutex by an R/W lock (which is also not recursive). This required a couple of changes: - The only caller of Read/WriteRegister, GDBRemoteRegisterContext class, was already acquiring the mutex, so these functions do not need to. All functions which now do not take a lock, take an lock argument instead, to remind the caller of this fact. - GetThreadSuffixSupported() was being called from locked and unlocked contexts (including contexts where the process was running, and the call would fail if it did not have the result cached). I have split this into two functions, one which computes the thread suffix support and caches it (this one always takes the lock), and another, which returns the cached value (and never needs to take the lock). This feels quite natural as ProcessGdbRemote was already pre-caching this value at the start. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D23802 llvm-svn: 279725
* Fix 32-bit builds after r279232Pavel Labath2016-08-191-2/+3
| | | | | | | GetByteSize() of a DataBuffer returns a uint64_t (it probably shouldn't), which isn't implicitly convertible to size_t. llvm-svn: 279238
* Remove the last manually constructed packet from gdb-remote register context ↵Pavel Labath2016-08-191-97/+45
| | | | | | | | | | | | | | | | | | | | | + small refactor Summary: The tricky part here was that the exisiting implementation of WriteAllRegisters was expecting hex-encoded data (as that was what the first implementation I replaced was using, but here we had binary data to begin with. I thought the read/write register functions would be more useful if they handled the hex-encoding themselves (all the other client functions provide the responses in a more-or-less digested form). The read functions return a DataBuffer, so they can allocate as much memory as they need to, while the write functions functions take an llvm::ArrayRef, as that can be constructed from pretty much anything. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D23659 llvm-svn: 279232
* Move QSyncThreadState packet generation to the gdb-remote clientPavel Labath2016-08-181-23/+2
| | | | llvm-svn: 279057
* Remove manual packet construction from ↵Pavel Labath2016-08-171-18/+5
| | | | | | GDBRemoteRegisterContext::SetPrimordialRegister llvm-svn: 278916
* Move packet construction from GDBRemoteRegisterContext go the communication ↵Pavel Labath2016-08-171-269/+157
| | | | | | | | | | | | | | | | | | | | | | | | class Summary: When saving/restoring registers the GDBRemoteRegisterContext class was manually constructing the register save/restore packets. This creates appropriate helper functions in GDBRemoteCommunicationClient, and switches the class to use those. It also removes what a duplicate packet send in some of those functions, a thing that I can only attribute to a bad merge artefact. I also add a test framework for testing gdb-remote client functionality and add tests for the new functions I introduced. I'd like to be able to test the register context changes in isolation as well, but currently there doesn't seem to be a way to reasonably construct a standalone register context object, so we'll have to rely on the end-to-end tests to verify that. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D23553 llvm-svn: 278915
* Reapply "Rewrite gdb-remote's SendContinuePacketAndWaitForResponse"Pavel Labath2016-08-091-12/+6
| | | | | | | | | | | | Resumbitting the commit after fixing the following problems: - broken unit tests on windows: incorrect gtest usage on my part (TEST vs. TEST_F) - the new code did not correctly handle the case where we went to interrupt the process, but it stopped due to a different reason - the interrupt request would remain queued and would interfere with the following "continue". I also added a unit test for this case. This reapplies r277156 and r277139. llvm-svn: 278118
* Fix uninitialized field warnings in GDBRemoteRegisterContextPavel Labath2016-08-081-109/+111
| | | | | | | also take the opportunity to replace NULL with nullptr and add clang-format guards to prevent it from messing up the nice table there. llvm-svn: 278005
* [LLVM][MIPS] Fix FPU Size Based on Dynamic FR.Nitesh Jain2016-08-011-1/+9
| | | | | | | | | | Reviewers: jingham, clayborg Subscribers: jaydeep, bhushan, mohit.bhakkad, slthakur, lldb-commits, emaste, nemanjai, labath, sdardis Differential Revision: https://reviews.llvm.org/D20357 llvm-svn: 277343
* Revert "Rewrite gdb-remote's SendContinuePacketAndWaitForResponse"Pavel Labath2016-07-291-6/+12
| | | | | | | | This reverts commit r277139, because: - broken unittest on windows (likely typo on my part) - seems to break TestCallThatRestart (needs investigation) llvm-svn: 277154
* Rewrite gdb-remote's SendContinuePacketAndWaitForResponsePavel Labath2016-07-291-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SendContinuePacketAndWaitForResponse was huge function with very complex interactions with several other functions (SendAsyncSignal, SendInterrupt, SendPacket). This meant that making any changes to how packet sending functions and threads interact was very difficult and error-prone. This change does not add any functionality yet, it merely paves the way for future changes. In a follow-up, I plan to add the ability to have multiple query packets in flight (i.e., request,request,response,response instead of the usual request,response sequences) and use that to speed up qModuleInfo packet processing. Here, I introduce two special kinds of locks: ContinueLock, which is used by the continue thread, and Lock, which is used by everyone else. ContinueLock (atomically) sends a continue packet, and blocks any other async threads from accessing the connection. Other threads create an instance of the Lock object when they want to access the connection. This object, while in scope prevents the continue from being send. Optionally, it can also interrupt the process to gain access to the connection for async processing. Most of the syncrhonization logic is encapsulated within these two classes. Some of it still had to bleed over into the SendContinuePacketAndWaitForResponse, but the function is still much more manageable than before -- partly because of most of the work is done in the ContinueLock class, and partly because I have factored out a lot of the packet processing code separate functions (this also makes the functionality more easily testable). Most importantly, there is none of syncrhonization code in the async thread users -- as far as they are concerned, they just need to declare a Lock object, and they are good to go (SendPacketAndWaitForResponse is now a very thin wrapper around the NoLock version of the function, whereas previously it had over 100 lines of synchronization code). This will make my follow up changes there easy. I have written a number of unit tests for the new code and I have ran the test suite on linux and osx with no regressions. Subscribers: tberghammer Differential Revision: https://reviews.llvm.org/D22629 llvm-svn: 277139
* Clean up vestigial remnants of locking primitivesSaleem Abdulrasool2016-07-281-6/+6
| | | | | | | | | | | | | | | | This finally removes the use of the Mutex and Condition classes. This is an intricate patch as the Mutex and Condition classes were tied together. Furthermore, many places had slightly differing uses of time values. Convert timeout values to relative everywhere to permit the use of std::chrono::duration, which is required for the use of std::condition_variable's timeout. Adjust all Condition and related Mutex classes over to std::{,recursive_}mutex and std::condition_variable. This change primarily comes at the cost of breaking the TracingMutex which was based around the Mutex class. It would be possible to write a wrapper to provide similar functionality, but that is beyond the scope of this change. llvm-svn: 277011
* Use Process Plugin register indices when communicating with remoteFrancis Ricci2016-04-251-7/+8
| | | | | | | | | | | | | | | | | | Summary: eRegisterKindProcessPlugin is used to store the register indices used by the remote, and eRegisterKindLLDB is used to store the internal lldb register indices. However, we're currently using the lldb indices instead of the process plugin indices when sending p/P packets. This will break if the remote uses non-contiguous register indices. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19305 llvm-svn: 267466
* The lldb side changes to go along with r255711 where a newJason Molenda2015-12-181-0/+46
| | | | | | | | | | | | | | | | | | | | | | "thread-pcs" key is added to the T (questionmark) packet in gdb-remote protocol so that lldb doesn't need to query the pc values of every thread before it resumes a process. The only odd part with this is that I'm sending the pc values in big endian order, so we need to know the endianness of the remote process before we can use them. All other register values in gdb-remote protocol are sent in native-endian format so this requirement doesn't exist. This addition is a performance enhancement -- lldb will fall back to querying the pc of each thread individually if it needs to -- so when we don't have the byte order for the process yet, we don't use these values. Practically speaking, the only way I've been able to elicit this condition is for the first T packet when we attach to a process. <rdar://problem/21963031> llvm-svn: 255942
* Make lldb::endian::InlHostByteOrder() private.Bruce Mitchener2015-11-071-9/+9
| | | | | | | | | | | | | | | | | | Summary: Since this is within the lldb namespace, the compiler tries to export a symbol for it. Unfortunately, since it is inlined, the symbol is hidden and this results in a mess of warnings when building on OS X with cmake. Moving it to the lldb_private namespace eliminates that problem. Reviewers: clayborg Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D14417 llvm-svn: 252396
* Silence -Wqual-cast warnings from GCC 5.2Saleem Abdulrasool2015-10-181-1/+2
| | | | | | | | There were a number of const qualifiers being cast away which caused warnings. This cluttered the output hiding real errors. Silence them by explicit casting. NFC. llvm-svn: 250662
* Clean up register naming conventions inside lldb. Jason Molenda2015-09-151-110/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "gcc" register numbers are now correctly referred to as "ehframe" register numbers. In almost all cases, ehframe and dwarf register numbers are identical (the one exception is i386 darwin where ehframe regnums were incorrect). The old "gdb" register numbers, which I incorrectly thought were stabs register numbers, are now referred to as "Process Plugin" register numbers. This is the register numbering scheme that the remote process controller stub (lldb-server, gdbserver, core file support, kdp server, remote jtag devices, etc) uses to refer to the registers. The process plugin register numbers may not be contiguous - there are remote jtag devices that have gaps in their register numbering schemes. I removed all of the enums for "gdb" register numbers that we had in lldb - these were meaningless - and I put LLDB_INVALID_REGNUM in all of the register tables for the Process Plugin regnum slot. This change is almost entirely mechnical; the one actual change in here is to ProcessGDBRemote.cpp's ParseRegisters() which parses the qXfer:features:read:target.xml response. As it parses register definitions from the xml, it will assign sequential numbers as the eRegisterKindLLDB numbers (the lldb register numberings must be sequential, without any gaps) and if the xml file specifies register numbers, those will be used as the eRegisterKindProcessPlugin register numbers (and those may have gaps). A J-Link jtag device's target.xml does contain a gap in register numbers, and it only specifies the register numbers for the registers after that gap. The device supports many different ARM boards and probably selects different part of its register file as appropriate. http://reviews.llvm.org/D12791 <rdar://problem/22623262> llvm-svn: 247741
* A messy bit of cleanup: Move towards more descriptive namesJason Molenda2015-08-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for eh_frame and stabs register numberings. This is not complete but it's a step in the right direction. It's almost entirely mechanical. lldb informally uses "gcc register numbering" to mean eh_frame. Why? Probably because there's a notorious bug with gcc on i386 darwin where the register numbers in eh_frame were incorrect. In all other cases, eh_frame register numbering is identical to dwarf. lldb informally uses "gdb register numbering" to mean stabs. There are no official definitions of stabs register numbers for different architectures, so the implementations of gdb and gcc are the de facto reference source. There were some incorrect uses of these register number types in lldb already. I fixed the ones that I saw as I made this change. This commit changes all references to "gcc" and "gdb" register numbers in lldb to "eh_frame" and "stabs" to make it clear what is actually being represented. lldb cannot parse the stabs debug format, and given that no one is using stabs any more, it is unlikely that it ever will. A more comprehensive cleanup would remove the stabs register numbers altogether - it's unnecessary cruft / complication to all of our register structures. In ProcessGDBRemote, when we get register definitions from the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo) or "gcc_regnum" (qXfer:features:read: packet to get xml payload). This patch changes ProcessGDBRemote to also accept "ehframe:" and "ehframe_regnum" from these remotes. I did not change GDBRemoteCommunicationServerLLGS or debugserver to send these new packets. I don't know what kind of interoperability constraints we might be working under. At some point in the future we should transition to using the more descriptive names. Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0", for eh_frame and stabs register numberings. These should be cleaned up eventually too. The sources link cleanly on macosx native with xcode build. I don't think we'll see problems on other platforms but please let me know if I broke anyone. llvm-svn: 245141
* Convert the ScriptInterpreter system to a plugin-based one.Zachary Turner2015-07-301-3/+0
| | | | | | | | | | | | | | | | | | | | | | | Previously embedded interpreters were handled as ad-hoc source files compiled into source/Interpreter. This made it hard to disable a specific interpreter, or to add support for other interpreters and allow the developer to choose which interpreter(s) were enabled for a particular build. This patch converts script interpreters over to a plugin-based system. Script interpreters now live in source/Plugins/ScriptInterpreter, and the canonical LLDB interpreter, ScriptInterpreterPython, is moved there as well. Any new code interfacing with the Python C API must live in this location from here on out. Additionally, generic code should never need to reference or make assumptions about the presence of a specific interpreter going forward. Differential Revision: http://reviews.llvm.org/D11431 Reviewed By: Greg Clayton llvm-svn: 243681
* Fixed a ton of gcc compile warningsVince Harron2015-05-131-5/+6
| | | | | | | | | | Removed some unused variables, added some consts, changed some casts to const_cast. I don't think any of these changes are very controversial. Differential Revision: http://reviews.llvm.org/D9674 llvm-svn: 237218
* Move several plugin to its own namespaceTamas Berghammer2015-03-311-5/+6
| | | | | | | | | | | | | Affected paths: * Plugins/Platform/Android/* * Plugins/Platform/Linux/* * Plugins/Platform/gdb-server/* * Plugins/Process/Linux/* * Plugins/Process/gdb-remote/* Differential revision: http://reviews.llvm.org/D8654 llvm-svn: 233679
* Add debug asserts / sanity checks toJason Molenda2014-07-241-0/+19
| | | | | | | | | | | | | | GDBRemoteRegisterContext::ReadRegisterBytes and GDBRemoteRegisterContext::WriteRegisterBytes to ensure we don't try to read/write off the end of the register buffer. This should never happen but we've had some target confusion in the past where it did; adding the checks is prudent to avoid crashing here if it happens again. <rdar://problem/16450971> <rdar://problem/16458182> llvm-svn: 213829
* Update lldb to track recent Triple arm64 enum removal and collapse into aarch64.Todd Fiala2014-07-231-1/+1
| | | | | | | | | | | See the following llvm change for details: r213743 | tnorthover | 2014-07-23 05:32:47 -0700 (Wed, 23 Jul 2014) | 9 lines AArch64: remove arm64 triple enumerator. This change fixes build breaks on Linux and MacOSX lldb. llvm-svn: 213755
* Start converting usages of off_t to other types.Zachary Turner2014-07-021-7/+7
| | | | | | | | | | | | | | | | | | | | | | | off_t is a type which is used for file offsets. Even more specifically, it is only used by a limited number of C APIs that deal with files. Any usage of off_t where the variable is not intended to be used with one of these APIs is a bug, by definition. This patch corrects some easy mis-uses of off_t, generally by converting them to lldb::offset_t, but sometimes by using other types such as size_t, when appropriate. The use of off_t to represent these offsets has worked fine in practice on linux-y platforms, since we used _FILE_OFFSET_64 to guarantee that off_t was a uint64. On Windows, however, _FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit. So the usage of off_t on Windows actually leads to legitimate bugs. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D4358 llvm-svn: 212192
* Replace uint32_t by lldb::RegisterKing in register context API.Jean-Daniel Dupas2014-07-021-1/+1
| | | | llvm-svn: 212172
* Fix a few typos.Bruce Mitchener2014-06-271-4/+4
| | | | llvm-svn: 211851
* sanitise sign comparisonsSaleem Abdulrasool2014-04-021-4/+4
| | | | | | | | This is a mechanical change addressing the various sign comparison warnings that are identified by both clang and gcc. This helps cleanup some of the warning spew that occurs during builds. llvm-svn: 205390
* lldb arm64 import.Jason Molenda2014-03-291-64/+239
| | | | | | | | | | | | | | | | These changes were written by Greg Clayton, Jim Ingham, Jason Molenda. It builds cleanly against TOT llvm with xcodebuild. I updated the cmake files by visual inspection but did not try a build. I haven't built these sources on any non-Mac platforms - I don't think this patch adds any code that requires darwin, but please let me know if I missed something. In debugserver, MachProcess.cpp and MachTask.cpp were renamed to MachProcess.mm and MachTask.mm as they picked up some new Objective-C code needed to launch processes when running on iOS. llvm-svn: 205113
* Fixed the GDBRemoteCommuncation to return a new ↵Greg Clayton2013-12-061-6/+6
| | | | | | | | | | | | | | GDBRemoteCommuncation::PacketResult enum for all packet sends/receives. <rdar://problem/15600045> Due to other recent changes, all connections to GDB servers that didn't support the "QStartNoAckMode" packet would cause us to fail to attach to the remote GDB server. The problem was that SendPacket* and WaitForResponse* packets would return a size_t indicating the number of bytes sent/received. The other issue was WaitForResponse* packets would strip the leading '$' and the trailing "#CC" (checksum) bytes, so the unimplemented response packet of "$#00" would get stripped and the WaitForResponse* packets would return 0. These new error codes give us flexibility to to more intelligent things in response to what is returned. llvm-svn: 196610
* <rdar://problem/15172417>Greg Clayton2013-11-131-88/+87
| | | | | | | | | | | | | | | Added two new GDB server packets to debugserver: "QSaveRegisterState" and "QRestoreRegiterState". "QSaveRegisterState" makes the remote GDB server save all register values and it returns a save identifier as an unsigned integer. This packet can be used prior to running expressions to save all registers. All registers can them we later restored with "QRestoreRegiterState:SAVEID" what SAVEID is the integer identifier that was returned from the call to QSaveRegisterState. Cleaned up redundant code in lldb_private::Thread, lldb_private::ThreadPlanCallFunction. Moved the lldb_private::Thread::RegisterCheckpoint into its own header file and it is now in the lldb_private namespace. Trimmed down the RegisterCheckpoint class to omit stuff that wasn't used (the stack ID). Added a few new virtual methods to lldb_private::RegisterContext that allow subclasses to efficiently save/restore register states and changed the RegisterContextGDBRemote to take advantage of these new calls. llvm-svn: 194621
* Fix python-free build.Joerg Sonnenberger2013-10-201-0/+2
| | | | llvm-svn: 193053
OpenPOWER on IntegriCloud