gdb/gdbarch: remove the 'invalid=None' state from gdbarch_components.py
authorAndrew Burgess <aburgess@redhat.com>
Mon, 6 Mar 2023 14:39:28 +0000 (14:39 +0000)
committerAndrew Burgess <aburgess@redhat.com>
Mon, 13 Mar 2023 21:51:04 +0000 (21:51 +0000)
commit6e2d282d74bfd961e64348199b92beb1cb648f6a
tree7b70d530cd09b99de5d24f51c27943abf43e48c3
parent74b1406e90bfa156aa324f9ecde424a5488cac51
gdb/gdbarch: remove the 'invalid=None' state from gdbarch_components.py

This commit ensures that the 'invalid' property of all components is
either True, False, or a string.

Additionally, this commit allows a component to have both a predicate
and for the 'invalid' property to be a string.

Removing the option for 'invalid' to be None allows us to simplify the
algorithms in gdbarch.py a little.

Allowing a component to have both a predicate and an 'invalid' string
means that we can validate the value that a tdep sets into a field,
but also allow a predicate to ensure that the field has changed from
the default.

This functionality isn't going to be used in this series, but I have
tested it locally and believe that it would work, and this might make
it easier for others to add new components in the future.

In gdbarch_types.py, I've updated the type annotations to show that
the 'invalid' field should not be None, and I've changed the default
for this field from None to False.

The change to using False as the default is temporary.  Later in this
series I'm going to change the default to True, but we need more fixes
before that can be done.

Additionally, in gdbarch_types.py I've removed an assert from
Component.get_predicate.  This assert ensured that we didn't have the
predicate field set to True and the invalid field set to a string.
However, no component currently uses this configuration, and after
this commit, that combination is now supported, so the assert can be
removed.

As a consequence of the gdbarch_types.py changes we see some
additional comments generated in gdbarch.c about verification being
skipped due to the invalid field being False.  This comment is inline
with plenty of other getters that also have a similar comment.  Plenty
of the getters do have validation, so I think it is reasonable to have
a comment noting that the validation has been skipped for a specific
reason, rather than due to some bug.

In gdbarch_components.py I've had to add 'invalid=True' for two
components: gcore_bfd_target and max_insn_length, without this the
validation in the gdbarch getter would disappear.

And in gdbarch.py I've reworked the logic for generating the
verify_gdbarch function, and for generating the getter functions.

The logic for generating the getter functions is still not ideal,  I
ended up having to add this additional logic block:

  elif c.postdefault is not None and c.predefault is not None:
      print("  /* Check variable changed from pre-default.  */", file=f)
      print(f"  gdb_assert (gdbarch->{c.name} != {c.predefault});", file=f)

which was needed to ensure we continued to generate the same code as
before, without this the fact that invalid is now False when it would
previously have been None, meant that we dropped the gdb_assert in
favour of a comment like:

  print(f"  /* Skip verify of {c.name}, invalid_p == 0 */", file=f)

which is clearly not a good change.  We could potentially look at
improving this in a later commit, but I don't plan to do that in this
series.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdb/gdbarch.c
gdb/gdbarch.py
gdb/gdbarch_components.py
gdb/gdbarch_types.py