summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/Utility/RegisterContext_x86.h
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] [Process] Introduce common helpers to split/recombine YMM dataMichal Gorny2019-06-211-0/+16
| | | | | | | | | | | | | | | | | Introduce two common helpers to take care of splitting and recombining YMM registers to/from XSAVE-like data. Since FreeBSD, Linux and NetBSD all use XSAVE-like data structures but with potentially different field layouts, the function takes two pointers -- to XMM register and to YMM high bits, and copies the data from/to YMMReg type. While at it, remove support for big endian. To mine and Pavel Labath's combined knowledge, there is no such thing on x86. Furthermore, assuming that the YMM register data would be swapped for big endian seems to be a weird assumption. Differential Revision: https://reviews.llvm.org/D63610 llvm-svn: 364042
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-101-8/+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
* Remove alignment from struct XSAVE altogetherPavel Labath2019-02-151-1/+1
| | | | | | | | | | | | | I reduced the alignment of this struct in r342029 to avoid compiler warnings about under-aligned allocations, but it turns out that this still causes problems with some compilers (see r353778). As I hinted in r342029, I don't believe any special aligment is necessary here (the only reason for that would be if we used some aligned SSE instructions to access this buffer, but I don't see any reason why we should do that), so here I go all the way, and remove the alignment requirements (except the ones naturally imposed by basic types) altogether. llvm-svn: 354125
* 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
* Reduce alignment on struct XSAVE, fixing a gcc warningPavel Labath2018-09-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | The warning is about heap-allocating a struct with bigger alignment requirements than the standard heap allocator provides. AFAICT, all uses of the XSAVE struct are already heap-allocated, so this high alignment does not actually have any effect and removing it should be NFC. I have also done some digging in the commit history. This alignment requirement was since the XSAVE struct was introduced in r180572 when adding AVX register support for linux. It does not mention the alignment specifically, so I am guessing this was just put there because the corresponging XSAVE cpu instruction requires its buffer to be 64-byte aligned. However, LLDB will not be normally reading this struct via the XSAVE instruction directly. Instead we will ask the kernel to copy the buffer saved when suspeding the inferior. This should not require such strict alignment (in fact, linux kernel will happily do this for any alignment). llvm-svn: 342029
* Reduce x86 register context boilerplate.Pavel Labath2017-12-181-6/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: The x86 FPR struct was defined as a struct containing a union between two members: XSAVE and FXSAVE. This patch makes FPR a union directly to remove one layer of indirection when trying to access the members. The initial layout of these two structs is identical, which is recognised by the fact that XSAVE has FXSAVE as its first member, so we also considered removing one more layer and leave FPR identical to XSAVE struct, but stopped short of doing that, as the FPR may be used to store different layouts in the future (e.g., ones generated by the FSAVE instruction). Reviewers: clayborg, krytarowski Subscribers: emaste, lldb-commits Differential Revision: https://reviews.llvm.org/D41245 llvm-svn: 320966
* Kill struct IOVECPavel Labath2017-12-011-9/+0
| | | | | | | | | | | struct iovec is used as an interface to system (posix) api's. As such, we shouldn't be using it in os-independent code, and we shouldn't be defining our own iovec replacements. Fortunately, its usage was not very widespread, so the removal was very easy -- I simply moved a couple declarations into os-specific code. llvm-svn: 319536
* Fix floating point register write on new x86 linux kernelsPavel Labath2017-11-281-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: New linux kernels (on systems that support the XSAVES instruction) will not update the inferior registers unless the corresponding flag in the XSAVE header is set. Normally this flag will be set in our image of the XSAVE area (since we obtained it from the kernel), but if the inferior has never used the corresponding register set, the respective flag can be clear. This fixes the issue by making sure we explicitly set the flags corresponding to the registers we modify. I don't try to precisely match the flags to set on each write, as the rules could get quite complicated -- I use a simpler over-approximation instead. This was already caught by test_fp_register_write, but that was only because the code that ran before main() did not use some of the register sets. Since nothing in this test relies on being stopped in main(), I modify the test to stop at the entry point instead, so we can be sure the inferior did not have a chance to access these registers. Reviewers: clayborg, valentinagiusti Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D40434 llvm-svn: 319161
* Process: fix FXSAVE on x86Saleem Abdulrasool2017-08-231-2/+1
| | | | | | | | | The FXSAVE member `ftw` (FPU Tag Word) was given the wrong size (8-bit) instead of the correct width (16-bit) as per the x87 Programmer's Manual. Adjust this to ensure that we print out the complete value for the register. llvm-svn: 311579
* Use Intel CPU flags to determine target supported features.Valentina Giusti2016-09-141-1/+3
| | | | | | | | | | | | | Summary: This patch uses the instruction CPUID to verify that FXSAVE, XSAVE, AVX and MPX are supported by the target hardware. In case the HW supports XSAVE, and at least one of the extended register sets, it further checks if the target software has the kernel support for such features, by verifying that their XSAVE part is correctly managed. Differential Revision: https://reviews.llvm.org/D24559 llvm-svn: 281507
* Fix for rL280668, Intel(R) Memory Protection Extensions (Intel(R) MPX) support.Valentina Giusti2016-09-081-4/+32
| | | | | | | | | | | | Summary: Signed-off-by: Valentina Giusti <valentina.giusti@intel.com> Reviewers: dvlahovski, granata.enrico, clayborg, labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D24255 llvm-svn: 280942
* Put the LLVM_ALIGNAS directive in the right place.Zachary Turner2016-09-061-2/+2
| | | | llvm-svn: 280758
* Make LLDB compile on Windows after the reformat.Zachary Turner2016-09-061-2/+8
| | | | | | | | | | | | | | | | Most of these issues arose as a result of header re-ordering, but it turned up a real bug, which is that MSVC doesn't support __attribute__((packed)) or __attribute__((aligned)). This was working before because there's a Windows header that #defines __attribute__(x) to nothing. We should fix this by removing that #define entirely, and dealing with the fallout separately which may turn up even more bugs. I fixed this by replacing them with the corresponding LLVM macros which understand how to do these operations on all the different compilers. llvm-svn: 280757
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-260/+252
| | | | | | | | | | | | | | | | | | | | | | | *** 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 "Intel(R) Memory Protection Extensions (Intel(R) MPX) support."Dimitar Vlahovski2016-09-061-33/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit rL280668 because the register tests fail on i386 Linux. I investigated a little bit what causes the failure - there are missing registers when running 'register read -a'. This is the output I got at the bottom: """ ... Memory Protection Extensions: bnd0 = {0x0000000000000000 0x0000000000000000} bnd1 = {0x0000000000000000 0x0000000000000000} bnd2 = {0x0000000000000000 0x0000000000000000} bnd3 = {0x0000000000000000 0x0000000000000000} unknown: 2 registers were unavailable. """ Also looking at the packets exchanged between the client and server: """ ... history[308] tid=0x7338 < 19> send packet: $qRegisterInfo4a#d7 history[309] tid=0x7338 < 130> read packet: $name:bnd0;bitsize:128;offset:1032;encoding:vector;format:vector-uint64;set:Memory Protection Extensions;ehframe:101;dwarf:101;#48 history[310] tid=0x7338 < 19> send packet: $qRegisterInfo4b#d8 history[311] tid=0x7338 < 130> read packet: $name:bnd1;bitsize:128;offset:1048;encoding:vector;format:vector-uint64;set:Memory Protection Extensions;ehframe:102;dwarf:102;#52 history[312] tid=0x7338 < 19> send packet: $qRegisterInfo4c#d9 history[313] tid=0x7338 < 130> read packet: $name:bnd2;bitsize:128;offset:1064;encoding:vector;format:vector-uint64;set:Memory Protection Extensions;ehframe:103;dwarf:103;#53 history[314] tid=0x7338 < 19> send packet: $qRegisterInfo4d#da history[315] tid=0x7338 < 130> read packet: $name:bnd3;bitsize:128;offset:1080;encoding:vector;format:vector-uint64;set:Memory Protection Extensions;ehframe:104;dwarf:104;#54 history[316] tid=0x7338 < 19> send packet: $qRegisterInfo4e#db history[317] tid=0x7338 < 76> read packet: $name:bndcfgu;bitsize:64;offset:1096;encoding:vector;format:vector-uint8;#99 history[318] tid=0x7338 < 19> send packet: $qRegisterInfo4f#dc history[319] tid=0x7338 < 78> read packet: $name:bndstatus;bitsize:64;offset:1104;encoding:vector;format:vector-uint8;#8e ... """ The bndcfgu and bndstatus registers don't have the 'Memory Protections Extension' set. I looked at the code and it seems that that is set correctly. So I'm not sure what's the problem or where does it come from. Also there is a second failure related to something like this in the tests: """ registerSet.GetName().lower() """ For some reason the registerSet.GetName() returns None. llvm-svn: 280703
* Intel(R) Memory Protection Extensions (Intel(R) MPX) support.Valentina Giusti2016-09-051-5/+33
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The Intel(R) Memory Protection Extensions (Intel(R) MPX) associates pointers to bounds, against which the software can check memory references to prevent out of bound memory access. This patch allows accessing the MPX registers: * bnd0-3: 128-bit registers to hold the bound values, * bndcfgu, bndstatus: 64-bit configuration registers, This patch also adds read/write tests for the MPX registers in the register command tests and adds a new subdirectory for MPX specific tests. Signed-off-by: Valentina Giusti <valentina.giusti@intel.com> Reviewers: labath, granata.enrico, lldb-commits, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D24187 llvm-svn: 280668
* Make sure files include what they use (part 2/2)Pavel Labath2016-08-111-0/+3
| | | | | | This makes lldb still compile on linux after a project-wide clang-format llvm-svn: 278335
* X86: Change FTAG register size in FXSAVE structureAbhishek Aggarwal2015-10-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Changed from 16 bits to 8 bits for Intel Architecture -- FXSAVE structure now conforms with the layout of FXSAVE area specified by IA Architecture Software Developer Manual - Modified Linux and FreeBSD specific files to support this change -- MacOSX already uses 8 bits for ftag register - Modified TestRegisters.py and a.cpp: -- Change allows 8 bit comparison of ftag values -- Change resolves Bug 24733: Removed XFAIL for Clang as the test works and passes for Clang compiler as well -- Change provides a Generic/Better way of testing Bug 24457 and Bug 25050 by using 'int3' inline assembly in inferior Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com> Reviewers: ovyalov, jingham, clayborg Subscribers: tfiala, emaste Differential Revision: http://reviews.llvm.org/D13587 llvm-svn: 250022
* Clean up register naming conventions inside lldb. Jason Molenda2015-09-151-282/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* gcc_esp_i386 and gcc_ebp_i386 had their values backwards forJason Molenda2014-08-131-2/+10
| | | | | | | | | i386 eh_frame register numbering, encoding a darwin-specific bug in the register numbering. Update the definitions to be the correct values, Darwin can use the register numbers from debugserver. Patch from Tong Shen. llvm-svn: 215488
* Renamed a struct from i386 to i386_.Hafiz Abid Qadeer2014-03-241-1/+1
| | | | | | It is to avoid build error when gcc defines i386. llvm-svn: 204628
* Moved various RegisterContext files from Process/POSIX to Process/Utility ↵Virgile Bello2014-03-121-0/+479
for easier sharing. Fix Windows build by adding JITLoaderGDB and ProcessElfCore. RegisterContext: fixes for Windows build: sizeof(GPR::register) didn't work, switched to sizeof(((GPR*)NULL)->register). llvm-svn: 203667
OpenPOWER on IntegriCloud