Summary: [lldb][x86_64] This patch adds fs_base/gs_base support for Linux x86_64. Originally, I plan to split the diff into two parts, one to refactoring lldb_xxx_x86_64 => x86_64::lldb_xxx across code base and the other one for adding fs_base/gs_base, but it turns out to be a non-trivial effort to split and very error prone so I decided to keep a single diff to get feedback. GDB supports fs_base/gs_base registers while LLDB does not. Since both linux coredump note section and ptrace supports them it is a missing feature. For context, this is a required feature to support getting pthread pointer on linux from both live and dump debugging. See thread below for details: https://discourse.llvm.org/t/how-to-get-pthread-pointer-from-lldb/70542/2?u=jeffreytan81 Implementation wise, we have initially tried `#ifdef` approach to reuse the code but it is introducing very tricky bugs and proves hard to maintain. Instead the diff completely separates the registers between x86_64 and x86_64_with_base so that non-linux related implementations can use x86_64 registers while linux uses x86_64_with_base. Here are the list of changes done in the patch: * Registers in lldb-x86-register-enums.h are separated into two: x86_64 and x86_64_with_base * fs_base/gs_base are added into x86_64_with_base * All linux files are change to use x86_64::lldb_xxx => x86_64_with_base::lldb_xxx * Support linux elf-core: * A new RegisterContextLinuxCore_x86_64 class is added for ThreadElfCore * RegisterContextLinuxCore_x86_64 overrides and uses its own register set supports fs_base/gs_base * RegisterInfos_x86_64_with_base/RegisterInfos_x86_64_with_base_shared ared added to provide g_contained_XXX/g_invalidate_XXX and RegInfo related code sharing. * `RegisterContextPOSIX_x86 ::m_gpr_x86_64` seems to be unused so I removed it. * `NativeRegisterContextDBReg_x86::GetDR()` is overridden in `NativeRegisterContextLinux_x86_64` to make watchpoint work. Reviewers:clayborg,labath,jingham,jdoerfert,JDevlieghere,kusmour,GeorgeHuyubo Subscribers: Tasks: Tags: Differential Revision: https://reviews.llvm.org/D155256
This structure is supposed to be trivial, so we cannot simply do "= nullptr;" on the new member. Doing that means you are non trivial, regardless of whether you emulate the previously implied constructor somehow. The next option is to update every use of brace initialisation. Given that this is some hundreds of lines, this change just adds a dummy pointer that is set to nullptr. Subsequent changes will actually use that to point to register flags information. Note: This change is not clang-format-ted because it changes a bunch of areas that are not themselves formatted. It would just add noise. Reviewed By: jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D145568
"Dynamic register info" is a very overloaded term, and this particular instance of it was only used for passing the information about the "orig_[re]ax" pseudo-register on x86 through some generic code. Since both sides of the code are x86-specific, I have replaced this with a more direct route. Differential Revision: https://reviews.llvm.org/D147045
Currently, lldb-server was opening the executable file to determine the process architecture (to differentiate between 32 and 64 bit architecture flavours). This isn't a particularly trustworthy source of information (the file could have been changed since the process was started) and it is not always available (file could be deleted or otherwise inaccessible). Unfortunately, ptrace does not give us a direct API to access the process architecture, but we can still infer it via some of its responses -- given that the general purpose register set of 64-bit applications is larger [citation needed] than the GPR set of 32-bit ones, we can just ask for the application GPR set and check its size. This is what this patch does. Differential Revision: https://reviews.llvm.org/D130985
The previous version of the patch did not update the definitions in conditionally compiled code. This patch includes changes to ARC and windows targets. Original commit message was: These were added to support some mips registers on linux, but linux mips support has now been removed due. They are still referenced in the freebds mips implementation, but the completeness of that implementation is also unknown. All other architectures just set these fields to zero, which is a cause of significant bloat in our register info definitions. Arm also has registers with variable sizes, but they were implemented in a more gdb-compatible fashion and don't use this feature. Differential Revision: https://reviews.llvm.org/D110914
This reverts commit 00e704bf080ffeeb9e334fb3ab71594f9aa50969. This commit should should have updated llvm/llvm-project/lldb/source/Plugins/ABI/ARC/ABISysV_arc.cpp like the other architectures.
These were added to support some mips registers on linux, but linux mips support has now been removed due. They are still referenced in the freebds mips implementation, but the completeness of that implementation is also unknown. All other architectures just set these fields to zero, which is a cause of significant bloat in our register info definitions. Arm also has registers with variable sizes, but they were implemented in a more gdb-compatible fashion and don't use this feature. Differential Revision: https://reviews.llvm.org/D110914
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
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
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