================
@@ -4179,21 +4179,124 @@ struct GdbServerTargetInfo {
RegisterSetMap reg_set_map;
};
-static std::vector<RegisterFlags::Field> ParseFlagsFields(XMLNode flags_node,
- unsigned size) {
+static FieldEnum::Enumerators ParseEnumEvalues(const XMLNode &enum_node) {
+ Log *log(GetLog(GDBRLog::Process));
+ // We will use the last instance of each value. Also we preserve the order
+ // of declaration in the XML, as it may not be numerical.
+ std::map<uint64_t, FieldEnum::Enumerator> enumerators;
----------------
DavidSpickett wrote:
In theory it's an enum so you'd start from 0 then 1, 2,3,4, etc. but this is
hardware, so it's not going to be as regular as software enums.
The other problem with IndexedMap is that you've got to have a function
uint64_t -> size_t to make the index, so for a 32 bit lldb the naive version
ends up clipping off the top half of values. Are we likely to get a 64 bit
enumerator value? No, but it's simpler to handle it than decide on another
arbitrary cut off point.
If we ignore that issue, there is the issue of order of insertion. I'm assuming
you iterate an IndexedMap using the indexes, but if the values of the
enumerator are used for the indexes we may lose the original order.
Maybe if that requirement didn't come across clearly enough, I need to expand
the comment with an example?
Or maybe I have the wrong end of the stick entirely.
https://github.com/llvm/llvm-project/pull/95768
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
