Revision tags: llvmorg-21-init |
|
#
e87f94a6 |
| 14-Jan-2025 |
Jay Foad <jay.foad@amd.com> |
[llvm-project] Fix typos mutli and mutliple. NFC. (#122880)
|
Revision tags: llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
f838f08c |
| 17-Jun-2024 |
David Spickett <david.spickett@linaro.org> |
[lldb] Add register field enum class (#90063)
This represents the enum type that can be assigned to a field using the
`<enum>` element in the target XML.
https://sourceware.org/gdb/current/onlin
[lldb] Add register field enum class (#90063)
This represents the enum type that can be assigned to a field using the
`<enum>` element in the target XML.
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Enum-Target-Types.html
Each enumerator has:
* A non-empty name
* A value that is within the range of the field it's applied to
The XML includes a "size" but we don't need that for anything and it's a
pain to verify so I've left it out of our internal structures. When
emitting XML we'll set size to the size of the register using the enum.
An Enumerator class is added to RegisterFlags and hooked up to the
existing ToXML so lldb-server can use it to emit enums as well.
As enums are elements on the same level as flags, when emitting XML
we'll do so via the registers. Before emitting a flags element we look
at all the fields and see what enums they reference. Then print all of
those if we haven't already done so.
Functions are added to dump enum information for `register info` to use
to show the enum information.
show more ...
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4 |
|
#
d1556e5e |
| 26-Oct-2023 |
David Spickett <david.spickett@linaro.org> |
[lldb][lldb-server] Enable sending RegisterFlags as XML (#69951)
This adds ToXML methods to encode RegisterFlags and its fields into XML
according to GDB's target XML format:
https://sourceware.
[lldb][lldb-server] Enable sending RegisterFlags as XML (#69951)
This adds ToXML methods to encode RegisterFlags and its fields into XML
according to GDB's target XML format:
https://sourceware.org/gdb/onlinedocs/gdb/Target-Description-Format.html#Target-Description-Format
lldb-server does not use libXML to build XML, so this follows the
existing code that uses strings. Indentation is used so the result is
still human readable.
```
<flags id=\"Foo\" size=\"4\">
<field name=\"abc\" start=\"0\" end=\"0\"/>
</flags>
```
This is used by lldb-server when building target XML, though no one sets
any fields yet. That'll come in a later commit.
show more ...
|
#
fe929770 |
| 23-Oct-2023 |
David Spickett <david.spickett@linaro.org> |
[lldb] Add a single bit constructor for RegisterFlags::Field (#69315)
This means you don't have to do RegisterField("", 0, 0), you can do
RegisterField("", 0).
Which is useful for testing and ev
[lldb] Add a single bit constructor for RegisterFlags::Field (#69315)
This means you don't have to do RegisterField("", 0, 0), you can do
RegisterField("", 0).
Which is useful for testing and even more useful when we are writing
definitions of real registers which have 10s of single bit fields.
show more ...
|
Revision tags: llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6 |
|
#
8b73a2e8 |
| 05-Jun-2023 |
David Spickett <david.spickett@linaro.org> |
[LLDB] Add table formatting for register fields
This will be used by the "register info" command to show the layout of register contents. For example if we have these fields coming in from XML: ```
[LLDB] Add table formatting for register fields
This will be used by the "register info" command to show the layout of register contents. For example if we have these fields coming in from XML: ``` <field name="D" start="0" end="7"/> <field name="C" start="8" end="15"/> <field name="B" start="16" end="23"/> <field name="A" start="24" end="31"/> ``` We get: ``` | 31-24 | 23-16 | 15-8 | 7-0 | |-------|-------|------|-----| | A | B | C | D | ``` Note that this is only the layout, not the values. For values, use "register read".
The tables' columns are center padded (left bias if there's an odd padding) and will wrap if the terminal width is too low.
``` | 31-24 | 23-16 | |-------|-------| | A | B |
| 15-8 | 7-0 | |------|-----| | C | D | ```
This means we match the horizontal format seen in many architecture manuals but don't spam the user with lots of misaligned text when the output gets very long.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D152917
show more ...
|
Revision tags: llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2 |
|
#
0ae342f4 |
| 14-Apr-2023 |
Jie Fu <jiefu@tencent.com> |
[lldb][test] Fix -Wsign-compare in RegisterFlagsTest.cpp (NFC)
/data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1526:11: error: comparison of integers of different signs: 'co
[lldb][test] Fix -Wsign-compare in RegisterFlagsTest.cpp (NFC)
/data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1526:11: error: comparison of integers of different signs: 'const unsigned long long' and 'const int' [-Werror,-Wsign-compare] if (lhs == rhs) { ~~~ ^ ~~~ /data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:1553:12: note: in instantiation of function template specialization 'testing::internal::CmpHelperEQ<unsigned long long, int>' requested here return CmpHelperEQ(lhs_expression, rhs_expression, lhs, rhs); ^ /data/llvm-project/lldb/unittests/Target/RegisterFlagsTest.cpp:128:3: note: in instantiation of function template specialization 'testing::internal::EqHelper::Compare<unsigned long long, int, nullptr>' requested here ASSERT_EQ(0x12345678ULL, rf.ReverseFieldOrder(0x12345678)); ^ /data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:2056:32: note: expanded from macro 'ASSERT_EQ' ^ /data/llvm-project/third-party/unittest/googletest/include/gtest/gtest.h:2040:54: note: expanded from macro 'GTEST_ASSERT_EQ' ASSERT_PRED_FORMAT2(::testing::internal::EqHelper::Compare, val1, val2) ^ 1 error generated.
show more ...
|
Revision tags: llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init |
|
#
e07a421d |
| 13-Jan-2023 |
David Spickett <david.spickett@linaro.org> |
[lldb] Show register fields using bitfield struct types
This change uses the information from target.xml sent by the GDB stub to produce C types that we can use to print register fields.
lldb-serve
[lldb] Show register fields using bitfield struct types
This change uses the information from target.xml sent by the GDB stub to produce C types that we can use to print register fields.
lldb-server *does not* produce this information yet. This will only work with GDB stubs that do. gdbserver or qemu are 2 I know of. Testing is added that uses a mocked lldb-server. ``` (lldb) register read cpsr x0 fpcr fpsr x1 cpsr = 0x60001000 = (N = 0, Z = 1, C = 1, V = 0, TCO = 0, DIT = 0, UAO = 0, PAN = 0, SS = 0, IL = 0, SSBS = 1, BTYPE = 0, D = 0, A = 0, I = 0, F = 0, nRW = 0, EL = 0, SP = 0) ```
Only "register read" will display fields, and only when we are not printing a register block.
For example, cpsr is a 32 bit register. Using the target's scratch type system we construct a type: ``` struct __attribute__((__packed__)) cpsr { uint32_t N : 1; uint32_t Z : 1; ... uint32_t EL : 2; uint32_t SP : 1; }; ```
If this register had unallocated bits in it, those would have been filled in by RegisterFlags as anonymous fields. A new option "SetChildPrintingDecider" is added so we can disable printing those.
Important things about this type: * It is packed so that sizeof(struct cpsr) == sizeof(the real register). (this will hold for all flags types we create) * Each field has the same storage type, which is the same as the type of the raw register value. This prevents fields being spilt over into more storage units, as is allowed by most ABIs. * Each bitfield size matches that of its register field. * The most significant field is first.
The last point is required because the most significant bit (MSB) being on the left/top of a print out matches what you'd expect to see in an architecture manual. In addition, having lldb print a different field order on big/little endian hosts is not acceptable.
As a consequence, if the target is little endian we have to reverse the order of the fields in the value. The value of each field remains the same. For example 0b01 doesn't become 0b10, it just shifts up or down.
This is needed because clang's type system assumes that for a struct like the one above, the least significant bit (LSB) will be first for a little endian target. We need the MSB to be first.
Finally, if lldb's host is a different endian to the target we have to byte swap the host endian value to match the endian of the target's typesystem.
| Host Endian | Target Endian | Field Order Swap | Byte Order Swap | |-------------|---------------|------------------|-----------------| | Little | Little | Yes | No | | Big | Little | Yes | Yes | | Little | Big | No | Yes | | Big | Big | No | No |
Testing was done as follows: * Little -> Little * LE AArch64 native debug. * Big -> Little * s390x lldb running under QEMU, connected to LE AArch64 target. * Little -> Big * LE AArch64 lldb connected to QEMU's GDB stub, which is running an s390x program. * Big -> Big * s390x lldb running under QEMU, connected to another QEMU's GDB stub, which is running an s390x program.
As we are not allowed to link core code to plugins directly, I have added a new plugin RegisterTypeBuilder. There is one implementation of this, RegisterTypeBuilderClang, which uses TypeSystemClang to build the CompilerType from the register fields.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D145580
show more ...
|
Revision tags: llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2 |
|
#
6ea45e30 |
| 05-Aug-2022 |
David Spickett <david.spickett@linaro.org> |
[lldb] Add RegisterFlags class
This models the "flags" node from GDB's target XML: https://sourceware.org/gdb/onlinedocs/gdb/Target-Description-Format.html
This node is used to describe the fields
[lldb] Add RegisterFlags class
This models the "flags" node from GDB's target XML: https://sourceware.org/gdb/onlinedocs/gdb/Target-Description-Format.html
This node is used to describe the fields of registers like cpsr on AArch64.
RegisterFlags is a class that contains a list of register fields. These fields will be extracted from the XML sent by the remote.
We assume that there is at least one field, that the fields are sorted in descending order and do not overlap. That will be enforced by the XML processor (the GDB client code in our case).
The fields may not cover the whole register. To account for this RegisterFields will add anonymous padding fields so that sizeof(all fields) == sizeof(register). This will save a lot of hasssle later.
Reviewed By: jasonmolenda, JDevlieghere
Differential Revision: https://reviews.llvm.org/D145566
show more ...
|