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.
Is there a library layering violation?
I assume that lldb/Target/*.h files depend on lldb/include/lldb/lldb-private-types.h, so lldb/include/lldb/lldb-private-types.h cannot include lldb/Target/*.h files...