| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a test-the-water change about possibilities of reducing duplication in
the register context definitions.
I've named the new class RegisterInfoPOSIX, as RegisterContextPOSIX was already
taken :(. The two files were identical except for a fix by Tamas in D12636,
which was applied to the Linux version only, which fixed a discrepancy between
the definitions of fpsr and fpcr on one hand, and all other floating point
register definitions on the other.
Linux test suite still passes after this change. For freebsd, make the floating
point register behavior consistent, but I don't know whether it will be
consistently fixed, or consistently broken. By eyeballing the code, I have a
feeling that a similar fix to D12636 will be required in
RegisterContextPOSIXProcessMonitor_arm64::ReadRegister, but I can't be sure as I
have no way to test it (the assert in that function should fire upon accessing
the registers if it is wrong though).
Reviewers: emaste, clayborg
Subscribers: aemerson, rengolin, beanz, mgorny, modocache, dmikulin, lldb-commits
Differential Revision: https://reviews.llvm.org/D25947
llvm-svn: 287916
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|
|
This is derived from FreeBSD/mips64 and Darwin and Linux arm64 support.
Differential Revision: http://reviews.llvm.org/D7835
llvm-svn: 233273
|
