diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-03-10 15:35:52 +0000 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2023-03-13 21:51:04 +0000 |
commit | 564cddf8edc75c1b043fcab93cc28861e0d48fa2 (patch) | |
tree | 7053e4d5ca5e113d413d4fa6f3cedd69048b5ed9 /gdb/gdbarch-gen.h | |
parent | a3e200efc1524368937a793e02614fecf8856168 (diff) | |
download | gdb-564cddf8edc75c1b043fcab93cc28861e0d48fa2.zip gdb-564cddf8edc75c1b043fcab93cc28861e0d48fa2.tar.gz gdb-564cddf8edc75c1b043fcab93cc28861e0d48fa2.tar.bz2 |
gdbarch: make invalid=True the default for all Components
This commit switches the default value for the 'invalid' field from
False to True. All components that previous set the invalid field to
True explicitly have had the field removed.
I think that True is a good choice for the default, this means that we
now get the validity checks by default, and if anyone adds a new
Component they need to make a choice to add an 'invalid=False' line
and disable the validation.
The flip side of this is that 'invalid=False' seems to be far more
common than 'invalid=True'. But I don't see a huge problem with this,
we shouldn't be aiming to reduce our typing, rather we should choose
based on which is least likely to introduce bugs. I think assuming
that we should do a validity check will achieve that.
Some additional components need to have an 'invalid=False' line added
to their definition, these are components that have a predefault
value, which is sufficient; the tdep code doesn't need to replace this
value if it doesn't want to.
Without adding the 'invalid=False' these components would be
considered to be invalid if they have not changed from their
predefault value -- but the predefault is fine.
There's no change in the generated code after this commit, so there
will be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Diffstat (limited to 'gdb/gdbarch-gen.h')
0 files changed, 0 insertions, 0 deletions