summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/Utility/RegisterContextDarwin_arm64.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [RegisterContext] Remove now unneded vestiges.Davide Italiano2019-11-131-6/+0
|
* [RegisterContextDarwin_arm64] Include the headers for getsysctlbyname.Davide Italiano2019-10-021-0/+5
| | | | | | | | This code is only used under __arm64__, use the correct guard. <rdar://problem/55916729> llvm-svn: 373509
* [LLDB] Fix typo in RegisterContextDarwin_arm64Martin Storsjo2019-09-241-1/+1
| | | | | | | | | In these cases, the register number should be calculated from fpu_d0, not fpu_s0. Differential Revision: https://reviews.llvm.org/D67892 llvm-svn: 372738
* [NFC] avoid AlignedCharArray in lldbJF Bastien2019-07-291-2/+2
| | | | | | As discussed in D65249, don't use AlignedCharArray or std::aligned_storage. Just use alignas(X) char Buf[Size];. This will allow me to remove AlignedCharArray entirely, and works on the current minimum version of Visual Studio. llvm-svn: 367275
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-241-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove null checks of results of new expressionsPavel Labath2019-07-011-2/+2
| | | | | | | | operator new doesn't return a null pointer, even if one turns off exceptions (it calls std::terminate instead). Therefore, all of this is dead code. llvm-svn: 364744
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-6/+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
* Fix an out-of-bounds error in RegisterContextDarwin_arm64Pavel Labath2019-03-271-2/+3
| | | | | | | | | | | | | | | | | Summary: gcc diagnoses this as "array subscript 63 is above array bounds of 'RegisterContextDarwin_arm64::VReg [32]'". The correct fix seems to be subtracting the fpu register base index, but I have no way of verifying that this actually works. Reviewers: jasonmolenda Subscribers: javed.absar, kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D59495 llvm-svn: 357055
* Use std::make_shared in LLDB (NFC)Jonas Devlieghere2019-02-111-1/+3
| | | | | | | | | | | 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
* 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-1/+1
| | | | | | | | | | | 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 some UB in RegisterContextDarwin_arm64.cppFrederic Riss2018-12-091-1/+11
| | | | llvm-svn: 348710
* Remove header grouping comments.Jonas Devlieghere2018-11-111-3/+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
* [lldb] Fix compile warnings in r332702Eric Liu2018-05-181-3/+4
| | | | | | | | | | | | | | | | Summary: - Fix #include path - Fix warning: ```` error: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Werror,-Wformat] ``` Reviewers: labath, javed.absar Differential Revision: https://reviews.llvm.org/D47072 llvm-svn: 332733
* Add back #ifdef __APPLE__ to ↵Pavel Labath2018-05-181-1/+1
| | | | | | | | | | | RegisterContextDarwin_xxx::NumSupportedHardwareWatchpoints It turns out these class still contained some os-specific functionality, but I did not notice that originally, as it was #ifdef arm(64). This adds back the __APPLE__ condition to these particular functions, unbreaking arm builds on other OSs. llvm-svn: 332710
* Make ObjectFileMachO work on non-darwin platformsPavel Labath2018-05-181-9/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch we were unable to write cross-platform MachO tests because the parsing code did not compile on other platforms. The reason for that was that ObjectFileMachO depended on RegisterContextDarwin_arm(64)? (presumably for core file parsing) and the two Register Context classes uses constants from the system headers (KERN_SUCCESS, KERN_INVALID_ARGUMENT). As far as I can tell, these two files don't actually interact with the darwin kernel -- they are used only in ObjectFileMachO and MacOSX-Kernel process plugin (even though it has "kernel" in the name, this one communicates with it via network packets and not syscalls). For the time being I have created OS-independent definitions of these constants and made the register context classes use those. Long term, the error handling in these classes should be probably changed to use more standard mechanisms such as Status or Error classes. This is the only change necessary (apart from build system glue) to make ObjectFileMachO work on other platforms. To demonstrate that, I remove REQUIRES:darwin from our (only) cross-platform mach-o test. Reviewers: jasonmolenda, aprantl, clayborg, javed.absar Subscribers: mgorny, lldb-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D46934 llvm-svn: 332702
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix alignment of arm64 fpu register context structureJason Molenda2017-11-161-2/+2
| | | | | | | | | | so it has the same padding as the kernel's definition which is written in terms of uint128_t. Original patch by Ryan Mansfield. <rdar://problem/35468499> llvm-svn: 318357
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-041-2/+2
| | | | llvm-svn: 296943
* Move Log from Core -> Utility.Zachary Turner2017-03-031-1/+1
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* Remove dependencies from Utility to Core and Target.Zachary Turner2017-02-141-1/+1
| | | | | | | | | | With this patch, the only dependency left is from Utility to Host. After this is broken, Utility will finally be standalone. Differential Revision: https://reviews.llvm.org/D29909 llvm-svn: 295088
* Add lldb register definitions for w0-w28, s0-s31, and d0-d31 toJason Molenda2016-10-191-3/+127
| | | | | | | | | | | | | | | | | | | | | | | | RegisterInfos_arm64.h. These register definitions include the offset into the register context, which will vary depending on the endianness of the arm64 target system (e.g. s8 is at offset 0 in v8 on little-endian, it is at offset 12 on big-endian) and I've only added the little-endian definitions to the table. If we want to add a big-endian arm64 target, we'll need a separate table which uses the big-endian offsets for these registers. I changed the name of the register table from g_register_infos_arm64 to g_register_infos_arm64_le to make it explicit that this is the little-endian version of that table, and updated users of the table to use the new name. I added support for the "w", "s", and "d" registers to RegisterContextDarwin_arm64 but it was more an example than anything useful -- this plugin is only used when working with core files and darwin core files do not (today) include the floating point register context, so it only added the support for the "w" pseudo registers. When we're connected to a real arm64 device, we use the ProcessGDBRemote code. llvm-svn: 284666
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-786/+765
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* [LLVM][MIPS] Fix FPU Size Based on Dynamic FR.Nitesh Jain2016-08-011-1/+1
| | | | | | | | | | 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
* Make lldb::endian::InlHostByteOrder() private.Bruce Mitchener2015-11-071-1/+1
| | | | | | | | | | | | | | | | | | 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
* Clean up register naming conventions inside lldb. Jason Molenda2015-09-151-55/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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
* lldb - Register Context Linux ARM64Todd Fiala2014-08-291-301/+9
| | | | | | | | | | | | | Yet another step toward ARM64 support. With this commit, lldb-gdbserver started on ARM64 target can be accessed by lldb running on desktop PC and it can process simple commands (like 'continue'). Still ARM64 support lacks NativeRegisterContextLinux_arm64.* code which waits to be implemented. Based on similar files for Linux x86_64 and Darwin ARM64. Due to common code extraction from Darwin related files, lldb should be tested for any unexpected regression on Darwin ARM64 machines too. See the following for more details: http://reviews.llvm.org/D4580 http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140825/012670.html Change by Paul Osmialowski. llvm-svn: 216737
* __arm64__ and __aarch64__ #ifdef adjustmentsTodd Fiala2014-07-091-1/+1
| | | | | | | | Change by Paul Osmialowski See http://reviews.llvm.org/D4379 for details. llvm-svn: 212583
* Fix typos.Bruce Mitchener2014-07-081-1/+1
| | | | llvm-svn: 212553
* Replace uint32_t by lldb::RegisterKing in register context API.Jean-Daniel Dupas2014-07-021-1/+1
| | | | llvm-svn: 212172
* lldb: remove adhoc implementation of array_sizeofSaleem Abdulrasool2014-06-271-5/+6
| | | | | | | | Replace adhoc inline implementation of llvm::array_lengthof in favour of the implementation in LLVM. This is simply a cleanup change, no functional change intended. llvm-svn: 211868
* lldb arm64 import.Jason Molenda2014-03-291-0/+1235
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
OpenPOWER on IntegriCloud