aboutsummaryrefslogtreecommitdiff
path: root/gdb/gdbarch.py
AgeCommit message (Collapse)AuthorFilesLines
2024-08-13gdb/gdbarch: fix a dot-space-space in generated filesGerlicher, Klaus1-2/+2
This is a very small patch to straighten out dot-space-space in these comments in the gdbarch generated files: - /* Skip verify of short_bit, invalid_p == 0 */ + /* Skip verify of short_bit, invalid_p == 0. */ There is no functional change after this commit. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-08-05gdb: rename gdbarch.c to gdbarch-gen.cSimon Marchi1-1/+1
For clarity and symmetry with `gdbarch-gen.h`. I wouldn't mind if all generated files had the `-gen` suffix. Change-Id: Icb70194fb0e3e2fa9d1c6f0d9331be09b805b428 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-07-27gdb: remove trailing empty line in target-delegates.cSimon Marchi1-0/+2
In a review [1], I pointed out that applying the patch, git would say: .git/rebase-apply/patch:147: new blank line at EOF. However, since the empty line is in target-delegates.c (a generated file), there's nothing the author can do about it. To avoid this comment coming up again in the future, change make-target-delegates.py to avoid the trailing empty line. Do this by making it output empty lines before each entity, not after. Since this needs removing a newline output in gdbcopyright, adjust ada-unicode.py and gdbarch.py to avoid changes in the files they generate. [1] https://inbox.sourceware.org/gdb-patches/20230427210113.45380-1-jhb@FreeBSD.org/T/#m083598405bef19157f67c9d97846d3dd90dc7d1c Change-Id: Ic4c648f06443b432168cb76603402c918aa6e5d2 Approved-By: Tom Tromey <tom@tromey.com>
2023-03-13gdbarch: improve generation of validation in gdbarch gettersAndrew Burgess1-9/+7
We currently generate some validation code within the gdbarch getter methods. This commit adjusts the algorithm used to generate this validation slightly to make the gdbarch.py code (I think) clearer; there's no significant changes to what is generated. The validation algorithm for gdbarch values is now: - If the Value has an 'invalid' field that is a string, use that for validation, - If the Value has its 'predicate' field set to true, then check the predicate returns true, this ensures the predicate has been called, - If the Value has its 'invalid' field set to True, or the Value has 'postdefault' field, then check the fields has changed from its initial value, - Otherwise no validation is performed. The only changes after this commit are: - Some comments change slightly, and - For 'gcore_bfd_target' and 'max_insn_length' we now validate by calling the predicate rather than checking the field value directly, the underlying check being performed is unchanged though. There should be no user visible changes after this commit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-13gdb/gdbarch: remove the 'invalid=None' state from gdbarch_components.pyAndrew Burgess1-21/+15
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>
2023-03-13gdb/gdbarch: split postdefault setup from invalid check in gdbarch.pyAndrew Burgess1-15/+27
Restructure how gdbarch.py generates the verify_gdbarch function. Previously the postdefault handling was bundled together with the validation. This means that a field can't have both a postdefault, and set its invalid attribute to a string. This doesn't seem reasonable to me, I see no reason why a field can't have both a postdefault (used when the tdep doesn't set the field), and an invalid expression, which can be used to validate the value that a tdep might set. In this commit I restructure the verify_gdbarch generation code to allow the above, there is no change in the actual generated code in this commit, that will come in later commit. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-27gdb: gdbarch*.py, copyright.py: add type annotationsSimon Marchi1-4/+4
Add type annotations to gdbarch*.py to fix all errors shown by pyright. There is one change in copyright.py too, to fix this one: /home/simark/src/binutils-gdb/gdb/gdbarch.py /home/simark/src/binutils-gdb/gdb/gdbarch.py:206:13 - error: Type of "copyright" is partially unknown Type of "copyright" is "(tool: Unknown, description: Unknown) -> str" (reportUnknownMemberType) Change-Id: Ia109b53e267f6e2f5bd79a1288d0d5c9508c9ac4 Reviewed-By: Tom Tromey <tom@tromey.com> Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-02-27gdb: split gdbarch component types to gdbarch_types.pySimon Marchi1-168/+5
Editing gdbarch-components.py is not an experience in an editor that is minimally smart about Python. Because gdbarch-components.py is read and exec'd by gdbarch.py, it doesn't import the Info / Method / Function / Value types. And because these types are defined in gdbarch.py, it can't import them, as that would make a cyclic dependency. Solve this by introducing a third file, gdbarch_types.py, to define these types. Make gdbarch.py and gdbarch-components.py import it. Also, replace the read & exec of gdbarch-components.py by a regular import. For this to work though, gdbarch-components.py needs to be renamed to gdbarch_components.py. Change-Id: Ibe994d56ef9efcc0698b3ca9670d4d9bf8bbb853 Reviewed-By: Tom Tromey <tom@tromey.com> Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-02-27gdb: gdbarch.py: remove Info.__init__Simon Marchi1-6/+1
Info.__init__ currently assigns `self.predicate = None`. This was helpful to ensure that all component types had a `predicate` attribute. The generator code could then avoid having code like "if the component is anything but Info, use predicate". Since the previous commit, all component types have a predicate attribute which defaults to False. We can therefore remove the assignment in Info.__init__, and in turn remove Info.__init__. We however need to make the printer parameter of _Component.__init__ optional, as Info don't need a printer. Change-Id: I611edeca9cc9837eb49dddfe038595e1ff3b7239 Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-02-27gdb: gdbarch.py: spell out parameters of _Component.__init__Simon Marchi1-5/+30
The way _Component uses kwargs is handy to save a few characters, but it doesn't play well with static analysis. When editing gdbarch.py, my editor (which uses pylance under the hood) knows nothing about the properties of components. So it's full of squiggly lines, and typing analysis (which I find really helpful) doesn't work. I therefore think it would be better to spell out the parameters. Change-Id: Iaf561beb0d0fbe170ce1c79252a291e0945e1830 Reviewed-By: Tom Tromey <tom@tromey.com> Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-02-27gdb: remove invalid / dead code from gdbarch.pySimon Marchi1-2/+0
My editor flagged that the variable `c` (in the lines removed by this patch) was unknown. I guess it ends up working because there is a `c` variable in the global scope. I tried putting `assert False` inside that if, and it is not hit, showing that we never enter this if. So, remove it. There is no change in the generated files. Change-Id: Id3b9f67719e88cada7c6fde673c8d7842ab13617 Reviewed-By: Tom Tromey <tom@tromey.com> Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-01-17Remove two unused fields from gdbarchTom Tromey1-4/+0
When I converted gdbarch to use the registry, I forgot to remove the two fields that were used to implement the previous approach. This patch removes them. Tested by rebuilding.
2023-01-11gdb: Update gdbarch.py with latest changes in gdbarch.cThiago Jung Bauermann1-3/+3
Commit 2b16913cdca2 ("gdb: make gdbarch_alloc take ownership of the tdep") changed gdbarch.c without updating gdbarch.py. As a result, running gdbarch.py reverts those changes and causes the build to fail. So change gdbarch.py to generate the current version of gdbarch.c. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-03Don't emit gdbarch_return_valueTom Tromey1-33/+37
The previous patch introduced a new overload of gdbarch_return_value. The intent here is that this new overload always be called by the core of gdb -- the previous implementation is effectively deprecated, because a call to the old-style method will not work with any converted architectures (whereas calling the new-style method is will delegate when needed). This patch changes gdbarch.py so that the old gdbarch_return_value wrapper function can be omitted. This will prevent any errors from creeping in.
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-12-05gdbarch.py: Fix indentation in the generated set_gdbarch_* definitionsThiago Jung Bauermann1-7/+14
Use as many tabs as possible for indentation and pad with spaces to keep the argument aligned to the opening parenthesis in the line above. Co-developed-by: Simon Marchi <simon.marchi@efficios.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-12-05gdbarch.py: Fix indentation in the generated gdbarch_dump functionThiago Jung Bauermann1-12/+8
Use tab for the first eight spaces of indentation, and align the gdb_printf arguments to the open parenthesis of the function call. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-10-31Inline initialization of gdbarch membersTom Tromey1-9/+10
This changes gdbarch to use the "predefault" to initialize its members inline. This required changing a couple of the Value instantiations to avoid a use of "gdbarch" during initialization, but on the whole I think this is better -- it removes a hidden ordering dependency.
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-2/+4
Currently, every internal_error call must be passed __FILE__/__LINE__ explicitly, like: internal_error (__FILE__, __LINE__, "foo %d", var); The need to pass in explicit __FILE__/__LINE__ is there probably because the function predates widespread and portable variadic macros availability. We can use variadic macros nowadays, and in fact, we already use them in several places, including the related gdb_assert_not_reached. So this patch renames the internal_error function to something else, and then reimplements internal_error as a variadic macro that expands __FILE__/__LINE__ itself. The result is that we now should call internal_error like so: internal_error ("foo %d", var); Likewise for internal_warning. The patch adjusts all calls sites. 99% of the adjustments were done with a perl/sed script. The non-mechanical changes are in gdbsupport/errors.h, gdbsupport/gdb_assert.h, and gdb/gdbarch.py. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
2022-10-02gdb: add asserts to gdbarch_register_nameAndrew Burgess1-1/+20
This commit adds asserts to gdbarch_register_name that validate the parameters, and the return value. The interesting thing here is that gdbarch_register_name is generated by gdbarch.py, and so, to add these asserts, I need to update the generation script. I've added two new arguments for Functions and Methods (as declared in gdbarch-components.py), these arguments are 'param_checks' and 'result_checks'. Each of these new arguments can be used to list some expressions that are then used within gdb_assert calls in the generated code. The asserts that validate the API as described in the comment I added to gdbarch_register_name a few commits back; the register number passed in needs to be a valid cooked register number, and the result being returned should not be nullptr.
2022-08-04Use registry in gdbarchTom Tromey1-2/+2
gdbarch implements its own registry-like approach. This patch changes it to instead use registry.h. It's a rather large patch but largely uninteresting -- it's mostly a straightforward conversion from the old approach to the new one. The main benefit of this change is that it introduces type safety to the gdbarch registry. It also removes a bunch of code. One possible drawback is that, previously, the gdbarch registry differentiated between pre- and post-initialization setup. This doesn't seem very important to me, though.
2022-08-04Use new and delete for gdbarchTom Tromey1-17/+9
This changes gdbarch to use new and delete.
2022-08-04Use bool in gdbarchTom Tromey1-1/+1
This changes gdbarch to use bool for initialized_p.
2022-07-26gdb: rename gdbarch_tdep struct to fix g++ 4.8 buildAndrew Burgess1-2/+2
After the commit: commit 08106042d9f5fdff60c129bf33190639f1a98b2a Date: Thu May 19 13:20:17 2022 +0100 gdb: move the type cast into gdbarch_tdep GDB would no longer build using g++ 4.8. The issue appears to be some confusion caused by GDB having 'struct gdbarch_tdep', but also a templated function called 'gdbarch_tdep'. Prior to the above commit the gdbarch_tdep function was not templated, and this compiled just fine. Note that the above commit compiles just fine with later versions of g++, so this issue was clearly fixed at some point, though I've not tried to track down exactly when. In this commit I propose to fix the g++ 4.8 build problem by renaming 'struct gdbarch_tdep' to 'struct gdbarch_tdep_base'. This rename better represents that the struct is only ever used as a base class, and removes the overloading of the name, which allows GDB to build with g++ 4.8. I've also updated the comment on 'struct gdbarch_tdep_base' to fix a typo, and the comment on the 'gdbarch_tdep' function, to mention that in maintainer mode a run-time type check is performed.
2022-03-29Unify gdb printf functionsTom Tromey1-7/+7
Now that filtered and unfiltered output can be treated identically, we can unify the printf family of functions. This is done under the name "gdb_printf". Most of this patch was written by script.
2022-03-18gdb: run black to format some Python filesSimon Marchi1-0/+1
Seems like some leftovers from previous commits. Change-Id: I7155ccdf7a4fef83bcb3d60320252c3628efdb83
2022-03-14gdb/gdbarch: compare some fields against 0 verify_gdbarchAndrew Burgess1-0/+10
After the previous commit, which removes the predicate function gdbarch_register_type_p, I noticed that the gdbarch->register_type field was not checked at in the verify_gdbarch function. More than not being checked, the field wasn't mentioned at all. I find this strange, I would expect that every field would at least be mentioned - we already generate comments for some fields saying that this field is _not_ being checked, so the fact that this field isn't being checked looks (to me), like this field is somehow slipping through the cracks. The comment at the top of gdbarch-components.py tries to explain how the validation is done. I didn't understand this comment completely, but, I think this final sentence: "Otherwise, the check is done against 0 (really NULL for function pointers, but same idea)." Means that, if non of the other cases apply, then the field should be checked against 0, with 0 indicating that the field is invalid (was not set by the tdep code). However, this is clearly not being done. Looking in gdbarch.py at the code to generate verify_gdbarch we do find that there is a case that is not handled, the case where the 'invalid' field is set true True, but non of the other cases apply. In this commit I propose two changes: 1. Handle the case where the 'invalid' field of a property is set to True, this should perform a check for the field of gdbarch still being set to 0, and 2. If the if/else series that generates verify_gdbarch doesn't handle a property then we should raise an exception. This means that if a property is added which isn't handled, we should no longer silently ignore it. After doing this, I re-generated the gdbarch files and saw that the following gdbarch fields now had new validation checks: register_type believe_pcc_promotion register_to_value value_to_register frame_red_zone_size displaced_step_restore_all_in_ptid solib_symbols_extension Looking at how these are currently set in the various -tdep.c files, I believe the only one of these that is required to be set for all architectures is the register_type field. And so, for all of the other fields, I've changed the property definition on gdbarch-components.py, setting the 'invalid' field to False. Now, after re-generation, the register_type field is checked against 0, thus an architecture that doesn't set_gdbarch_register_type will now fail during validation. For all the other fields we skip the validation, in which case, it is find for an architecture to not set this field. My expectation is that there should be no user visible changes after this commit. Certainly for all fields except register_type, all I've really done is cause some extra comments to be generated, so I think that's clearly fine. For the register_type field, my claim is that any architecture that didn't provide this would fail when creating its register cache, and I couldn't spot an architecture that doesn't provide this hook. As such, I think this change should be fine too.
2022-03-02Move copyright code from gdbarch.py to new fileTom Tromey1-25/+4
This moves the copyright code from gdbarch.py to a new Python source file, gdbcopyright.py. The function in this file will find the copyright dates by scanning the calling script. This will be reused in a future patch. This involved minor changes to the output of gdbarch.py. Also, I've updated copyright.py to remove the reference to gdbarch.sh. We don't need to mention gdbarch.py there, either.
2022-01-05Use filtered output for gdbarch dumpTom Tromey1-4/+4
This changes gdbarch dumping to use filtered output. This seems a bit better to me, both on the principle that this is an ordinary command, and because the output can be voluminous, so it may be nice to stop in the middle.
2022-01-01Manual copyright year update of various GDB filesJoel Brobecker1-1/+1
This commit updates the copyright year in some files where we have a copyright year outside of the copyright year, and thus are not included in gdb's copyright.py script.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-12-17Add new gdbarch generatorSimon Marchi1-0/+526
The new gdbarch generator is a Python program. It reads the "components.py" that was created in the previous patch, and generates gdbarch.c and gdbarch-gen.h. This is a relatively straightforward translation of the existing .sh code. It doesn't try very hard to be idiomatic Python or to be especially smart. It is, however, incredibly faster: $ time ./gdbarch.sh real 0m8.197s user 0m5.779s sys 0m3.384s $ time ./gdbarch.py real 0m0.065s user 0m0.053s sys 0m0.011s Co-Authored-By: Tom Tromey <tom@tromey.com>