[all-commits] [llvm/llvm-project] 54981b: [lldb] Read register fields from target XML

[David Spickett via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 54981bb75d374863c6a15530018c6d7ac5be6478
      https://github.com/llvm/llvm-project/commit/54981bb75d374863c6a15530018c6d7ac5be6478
  Author: David Spickett <david.spickett at linaro.org>
  Date:   2023-04-13 (Thu, 13 Apr 2023)

  Changed paths:
    M lldb/include/lldb/Target/DynamicRegisterInfo.h
    M lldb/include/lldb/lldb-private-types.h
    M lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
    M lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
    M lldb/source/Target/DynamicRegisterInfo.cpp

  Log Message:
  -----------
  [lldb] Read register fields from target XML

This teaches ProcessGDBRemote to look for "flags" nodes
in the target XML that tell you what fields a register has.

https://sourceware.org/gdb/onlinedocs/gdb/Target-Description-Format.html

It will check for various invalid inputs like:
* Flags nodes with 0 fields in them.
* Start or end being > the register size.
* Fields that overlap.
* Required properties not being present (e.g. no name).
* Flag sets being redefined.

If anything untoward is found, we'll just drop the field or the
flag set altogether. Register fields are a "nice to have" so LLDB
shouldn't be crashing because of them, instead just log anything
we throw away. So the user can fix their XML/file a bug with their
vendor.

Once that is done it will sort the fields and pass them to
the RegisterFields class I added previously.

There is no way to see these fields yet, so tests for this code
will come later when the formatting code is added.

The fields are stored in a map of unique pointers on the
ProcessGDBRemote class. It will give out raw pointers on the
assumption that the GDB process lives longer than the users
of those pointers do. Which means RegisterInfo is still a trivial struct
but we are properly destroying the fields when the GDB process ends.

We can't store the fields directly in the map because adding new
items may cause its storage to be reallocated, which would invalidate
pointers we've already given out.

Reviewed By: jasonmolenda, JDevlieghere

Differential Revision: https://reviews.llvm.org/D145574