aboutsummaryrefslogtreecommitdiff
path: root/gdb/target-descriptions.c
AgeCommit message (Collapse)AuthorFilesLines
2023-10-10gdb: remove target_gdbarchSimon Marchi1-2/+2
This function is just a wrapper around the current inferior's gdbarch. I find that having that wrapper just obscures where the arch is coming from, and that it's often used as "I don't know which arch to use so I'll use this magical target_gdbarch function that gets me an arch" when the arch should in fact come from something in the context (a thread, objfile, symbol, etc). I think that removing it and inlining `current_inferior ()->arch ()` everywhere will make it a bit clearer where that arch comes from and will trigger people into reflecting whether this is the right place to get the arch or not. Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-09-20Remove explanatory comments from includesTom Tromey1-1/+1
I noticed a comment by an include and remembered that I think these don't really provide much value -- sometimes they are just editorial, and sometimes they are obsolete. I think it's better to just remove them. Tested by rebuilding. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-08-31gdb: introduce field::bitsize / field::set_bitsizeSimon Marchi1-1/+1
Add these two methods, rename the field to m_bitsize to make it pseudo private. Change-Id: Ief95e5cf106e72f2c22ae47b033d0fa47202b413 Approved-By: Tom Tromey <tom@tromey.com>
2023-03-18Unify arch_float_type and init_float_typeTom Tromey1-6/+7
This unifies arch_float_type and init_float_type by using a type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Remove arch_typeTom Tromey1-2/+3
This removes arch_type, replacing all uses with the new type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-15Do not record a rejected target descriptionTom Tromey1-1/+4
When connecting to a certain target, gdb issues a warning about the target description: (gdb) target remote localhost:7947 Remote debugging using localhost:7947 warning: Architecture rejected target-supplied description If you then kill the inferior and change the exec-file, this will happen: (gdb) file bar Architecture of file not recognized. After this, debugging doesn't work very well. What happens here is that, despite the warning, target_find_description records the downloaded description in the target_desc_info. Then the "file" command ends up calling set_gdbarch_from_file, which uses that description. It seems to me that, because the architecture rejected the description, it should not be used. That is what this patch implements.
2023-02-03gdb: make target_desc_info_from_user_p a method of target_desc_infoSimon Marchi1-8/+0
Move the implementation over to target_desc_info. Remove the target_desc_info forward declaration in target-descriptions.h, it's no longer needed. Change-Id: Ic95060341685afe0b73af591ca6efe32f5e7e892
2023-02-03gdb: remove copy_inferior_target_desc_infoSimon Marchi1-11/+0
This function is now trivial, we can just copy inferior::tdesc_info where needed. Change-Id: I25185e2cd4ba1ef24a822d9e0eebec6e611d54d6
2023-02-03gdb: remove get_tdesc_infoSimon Marchi1-18/+10
Remove this function, since it's now a trivial access to inferior::tdesc_info. Change-Id: I3e88a8214034f1a4163420b434be11f51eef462c
2023-02-03gdb: change inferior::tdesc_info to non-pointerSimon Marchi1-14/+2
I initially made this field a unique pointer, to have automatic memory management. But I then thought that the field didn't really need to be allocated separately from struct inferior. So make it a regular non-pointer field of inferior. Remove target_desc_info_free, as it's no longer needed. Change-Id: Ica2b97071226f31c40e86222a2f6922454df1229
2023-02-03gdb: move target_desc_info to inferior.hSimon Marchi1-26/+0
In preparation for the following patch, where struct inferior needs to "see" struct target_desc_info, move target_desc_info to the header file. I initially moved the structure to target-descriptions.h, and later made inferior.h include target-descriptions.h. This worked, but it then occured to me that target_desc_info is really an inferior property that involves a target description, so I think it makes sense to have it in inferior.h. Change-Id: I3e81d04faafcad431e294357389f3d4c601ee83d
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-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-12/+6
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-09-29Constify target_desc declarationsKeith Seitz1-1/+1
This patch changes various global target_desc declarations to const, thereby correcting a prominent source of ODR violations in PowerPC-related target code. The majority of files/changes are mechanical const-ifications accomplished by regenerating the C files in features/. This also required manually updating mips-linux-tdep.h, s390-linux-tdep.h, nios2-tdep.h, s390-tdep.h, arch/ppc-linux-tdesc.h, arch/ppc-linux-common.c, and rs6000-tdep.c. Patch tested against the sourceware trybot, and fully regression tested against our (Red Hat's) internal test infrastructure on Rawhide aarch64, s390x, x86_64, and powerpcle. With this patch, I can finally enable LTO in our GDB package builds. [Tested with a rawhide scratch build containing this patch.] Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24835
2022-09-21gdb: add type::length / type::set_lengthSimon Marchi1-1/+1
Add the `length` and `set_length` methods on `struct type`, in order to remove the `TYPE_LENGTH` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4
2022-08-31gdb: Add tdesc_found_register function to tdesc APIAndrew Burgess1-0/+11
This commit adds a new function to the target description API within GDB. This new function is not used in this commit, but will be used in the next commit, I'm splitting it out into a separate patch for easier review. What I want to do in the next commit is check to see if a target description supplied a particular register, however, the register in question could appear in one of two possible features. The new function allows me to ask the tdesc_arch_data whether a register was found and assigned a particular GDB register number once all of the features have been checked. I think this is a much simpler solution than adding code such that, while checking each feature, I spot if the register I'm processing is the one I care about. No tests here as the new code is not used, but this code will be exercised in the next commit.
2022-08-04Use registry in gdbarchTom Tromey1-31/+21
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-04-07gdb: move struct reggroup into reggroups.h headerAndrew Burgess1-1/+1
Move 'struct reggroup' into the reggroups.h header. Remove the reggroup_name and reggroup_type accessor functions, and just use the name/type member functions within 'struct reggroup', update all uses of these removed functions. There should be no user visible changes after this commit.
2022-04-07gdb: make gdbarch_register_reggroup_p take a const reggroup *Andrew Burgess1-2/+2
Change gdbarch_register_reggroup_p to take a 'const struct reggroup *' argument. This requires a change to the gdb/gdbarch-components.py script, regeneration of gdbarch.{c,h}, and then updates to all the architectures that implement this method. There should be no user visible changes after this commit.
2022-03-29Unify gdb printf functionsTom Tromey1-91/+91
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-29Unify gdb puts functionsTom Tromey1-1/+1
Now that filtered and unfiltered output can be treated identically, we can unify the puts family of functions. This is done under the name "gdb_puts". Most of this patch was written by script.
2022-03-29Unify vprintf functionsTom Tromey1-1/+1
Now that filtered and unfiltered output can be treated identically, we can unify the vprintf family of functions: vprintf_filtered, vprintf_unfiltered, vfprintf_filtered and vfprintf_unfiltered. (For the gdb_stdout variants, recall that only printf_unfiltered gets truly unfiltered output at this point.) This removes one such function and renames the remaining two to "gdb_vprintf". All callers are updated. Much of this patch was written by script.
2022-01-18Move gdb obstack code to gdbsupportTom Tromey1-1/+1
This moves the gdb-specific obstack code -- both extensions like obconcat and obstack_strdup, and things like auto_obstack -- to gdbsupport.
2022-01-05Use filtered output in target-descriptions.cTom Tromey1-76/+76
target-descriptions.c uses unfiltered output. However, if you happen to invoke this command interactively, it's probably better for it to use filtering. For non-interactive use, this doesn't matter.
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-29Consistently Use ui_file parameter to show callbacksTom Tromey1-4/+6
I happened to notice that one "show" callback was printing to gdb_stdout rather than to the passed-in ui_file parameter. I went through all such callbacks and fixed them to consistently use the ui_file. Regression tested on x86-64 Fedora 34.
2021-10-28gdb: add add_setshow_prefix_cmdSimon Marchi1-8/+6
There's a common pattern to call add_basic_prefix_cmd and add_show_prefix_cmd to add matching set and show commands. Add the add_setshow_prefix_cmd function to factor that out and use it at a few places. Change-Id: I6e9e90a30e9efb7b255bf839cac27b85d7069cfd
2021-10-07gdb: add accessors for field (and call site) locationSimon Marchi1-3/+3
Add accessors for the various location values in struct field. This lets us assert that when we get a location value of a certain kind (say, bitpos), the field's location indeed contains a value of that kind. Remove the SET_FIELD_* macros, instead use the new setters directly. Update the FIELD_* macros used to access field locations to go through the getters. They will be removed in a subsequent patch. There are places where the FIELD_* macros are used on call_site_target structures, because it contains members of the same name (loc_kind and loc). For now, I have replicated the getters/setters in call_site_target. But we could perhaps eventually factor them in a "location" structure that can be used at both places. Note that the field structure, being zero-initialized, defaults to a bitpos location with value 0. While writing this patch, I tried to make it default to an "unset" location, to catch places where we would miss setting a field's location. However, I found that some places relied on the default being "bitpos 0", so I left it as-is. This change could always be done as follow-up work, making these places explicitly set the "bitpos 0" location. I found two issues to fix: - I got some failures in the gdb.base/infcall-nested-structs-c++.exp test. They were caused by two functions in amd64-tdep.c using TYPE_FIELD_BITPOS before checking if the location is of the bitpos kind, which they do indirectly through `field_is_static`. Simply move getting the bitpos below the field_is_static call. - I got a failure in gdb.xml/tdesc-regs.exp. It turns out that in make_gdb_type_enum, we set enum field values using SET_FIELD_BITPOS, and later access them through FIELD_ENUMVAL. Fix that by using set_loc_enumval to set the value. Change-Id: I53d3734916c46457576ba11dd77df4049d2fc1e8
2021-10-03gdb: make string-like set show commands use std::string variableSimon Marchi1-1/+1
String-like settings (var_string, var_filename, var_optional_filename, var_string_noescape) currently take a pointer to a `char *` storage variable (typically global) that holds the setting's value. I'd like to "mordernize" this by changing them to use an std::string for storage. An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management. Another interesting reason is that, with `char *`, nullptr and an empty string often both have the same meaning of "no value". String settings are initially nullptr (unless initialized otherwise). But when doing "set foo" (where `foo` is a string setting), the setting now points to an empty string. For example, solib_search_path is nullptr at startup, but points to an empty string after doing "set solib-search-path". This leads to some code that needs to check for both to check for "no value". Or some code that converts back and forth between NULL and "" when getting or setting the value. I find this very error-prone, because it is very easy to forget one or the other. With std::string, we at least know that the variable is not "NULL". There is only one way of representing an empty string setting, that is with an empty string. I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional<string> anyway. Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests). Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function. In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects. This patch started by changing all relevant add_setshow_* commands to take an `std::string *` instead of a `char **` and fixing everything that failed to build. That includes of course all string setting variable and their uses. string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options). The add_path function in source.c is really complex and twisted, I'd rather not try to change it to work on an std::string right now. Instead, I added an overload that copies the std:string to a `char *` and back. This means more copying, but this is not used in a hot path at all, so I think it is acceptable. Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
2021-06-28gdb: remove gdbarch_info_initSimon Marchi1-2/+0
While reviewing another patch, I realized that gdbarch_info_init could easily be removed in favor of initializing gdbarch_info fields directly in the struct declaration. The only odd part is the union. I don't know if it's actually important for it to be zero-initialized, but I presume it is. I added a constructor to gdbarch_info to take care of that. A proper solution would be to use std::variant. Or, these could also be separate fields, the little extra space required wouldn't matter. gdb/ChangeLog: * gdbarch.sh (struct gdbarch_info): Initialize fields, add constructor. * gdbarch.h: Re-generate. * arch-utils.h (gdbarch_info_init): Remove, delete all usages. * arch-utils.c (gdbarch_info_init): Remove. Change-Id: I7502e08fe0f278d84eef1667a072e8a97bda5ab5
2021-05-12gdb: generate the prefix name for prefix commands on demandMarco Barisione1-3/+3
Previously, the prefixname field of struct cmd_list_element was manually set for prefix commands. This seems verbose and error prone as it required every single call to functions adding prefix commands to specify the prefix name while the same information can be easily generated. Historically, this was not possible as the prefix field was null for many commands, but this was fixed in commit 3f4d92ebdf7f848b5ccc9e8d8e8514c64fde1183 by Philippe Waroquiers, so we can rely on the prefix field being set when generating the prefix name. This commit also fixes a use after free in this scenario: * A command gets created via Python (using the gdb.Command class). The prefix name member is dynamically allocated. * An alias to the new command is created. The alias's prefixname is set to point to the prefixname for the original command with a direct assignment. * A new command with the same name as the Python command is created. * The object for the original Python command gets freed and its prefixname gets freed as well. * The alias is updated to point to the new command, but its prefixname is not updated so it keeps pointing to the freed one. gdb/ChangeLog: * command.h (add_prefix_cmd): Remove the prefixname argument as it can now be generated automatically. Update all callers. (add_basic_prefix_cmd): Ditto. (add_show_prefix_cmd): Ditto. (add_prefix_cmd_suppress_notification): Ditto. (add_abbrev_prefix_cmd): Ditto. * cli/cli-decode.c (add_prefix_cmd): Ditto. (add_basic_prefix_cmd): Ditto. (add_show_prefix_cmd): Ditto. (add_prefix_cmd_suppress_notification): Ditto. (add_prefix_cmd_suppress_notification): Ditto. (add_abbrev_prefix_cmd): Ditto. * cli/cli-decode.h (struct cmd_list_element): Replace the prefixname member variable with a method which generates the prefix name at runtime. Update all code reading the prefix name to use the method, and remove all code setting it. * python/py-cmd.c (cmdpy_destroyer): Remove code to free the prefixname member as it's now a method. (cmdpy_function): Determine if the command is a prefix by looking at prefixlist, not prefixname.
2021-05-07gdb: make target_desc_info::filename an std::stringSimon Marchi1-20/+14
To make the management of memory automatic. As to why I chose to make this an std::string and not an std::unique_xmalloc_ptr<char>: some parts of the code consider both a NULL value and an empty string value to mean "no filename". target_desc_info_from_user_p, however, doesn't check for a non-NULL but empty string value. So it seems like having two ways of denoting "no filename" can lead to these kinds of inconsistencies. Using std::string, "no filename" is only represented by an empty value. As a bonus, using an std::string lets us copy target_desc_info objects using the default assignment operator. gdb/ChangeLog: * target-descriptions.c (struct target_desc_info) <filename>: Make std::string. (copy_inferior_target_desc_info): Adjust. (target_desc_info_free): Adjust. (target_find_description): Adjust. (set_tdesc_filename_cmd): Adjust. (show_tdesc_filename_cmd): Adjust. (unset_tdesc_filename_cmd): Adjust. (maint_print_c_tdesc_cmd): Adjust. Change-Id: I4e3a6ad8ccda2b88c202471d4f54249753cad127
2021-05-07gdb: (de-)allocate target_desc_info with new/deleteSimon Marchi1-5/+6
In preparation for using non-POD types in the struct. gdb/ChangeLog: * target-descriptions.c (struct target_desc_info): Initialize fields. (get_tdesc_info): Use new. (target_desc_info_free): Use delete. Change-Id: I10fdaeeae7cdbd7930ae7adeeb13f7f363c67c7a
2021-05-07gdb: change target_desc_info::fetched to boolSimon Marchi1-3/+3
gdb/ChangeLog: * target-descriptions.c (struct target_desc_info) <fetched>: bool. (target_find_description): Adjust. (target_clear_description): Adjust. Change-Id: Ib69e097b38cf270e674f1249105d535a312954e1
2021-05-07gdb: remove target description macrosSimon Marchi1-38/+37
In my opinion, the target_desc_fetched, current_target_desc and target_description_filename macros in target-descriptions.c are not very useful. I don't think it's useful to hide that they operate on the current inferior, as everything currently works under the assumption that the various tdesc commands operate on the current inferior, and I don't see that changing in the foreseeable future. This change also avoids having multiple unnecessary calls to current_inferior and get_tdesc_info per function. gdb/ChangeLog: * target-descriptions.c (struct target_desc_info) <tdesc>: Adjust doc. (target_desc_fetched): Remove. (current_target_desc): Remove. (target_description_filename): Remove. (target_find_description): Adjust. (target_clear_description): Adjust. (target_current_description): Adjust. (set_tdesc_filename_cmd): Adjust. (show_tdesc_filename_cmd): Adjust. (unset_tdesc_filename_cmd): Adjust. (maint_print_c_tdesc_cmd): Adjust. (maint_print_xml_tdesc_cmd): Adjust. Change-Id: Ibfb581490e949c16d59924e2cac633ede5c26c5b
2021-03-24gdb: remove current_top_target functionSimon Marchi1-2/+4
The current_top_target function is a hidden dependency on the current inferior. Since I'd like to slowly move towards reducing our dependency on the global current state, remove this function and make callers use current_inferior ()->top_target () There is no expected change in behavior, but this one step towards making those callers use the inferior from their context, rather than refer to the global current inferior. gdb/ChangeLog: * target.h (current_top_target): Remove, make callers use the current inferior instead. * target.c (current_top_target): Remove. Change-Id: Iccd457036f84466cdaa3865aa3f9339a24ea001d
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-11-12gdb: add an option flag to 'maint print c-tdesc'Andrew Burgess1-12/+73
GDB has two approaches to generating the target descriptions found in gdb/features/, the whole description approach, where the XML file contains a complete target description which is then used to generate a single C file that builds that target description. Or, the split feature approach, where the XML files contain a single target feature, each feature results in a single C file to create that one feature, and then a manually written C file is used to build a complete target description from individual features. There's a Makefile, gdb/features/Makefile, which is responsible for managing the regeneration of the C files from the XML files. However, some of the logic that selects between the whole description approach, or the split feature approach, is actually hard-coded into GDB, inside target-descriptions.c:maint_print_c_tdesc_cmd we check the path to the incoming XML file and use this to choose which type of C file we should generate. This commit removes this hard coding from GDB, and makes the Makefile entirely responsible for choosing the approach. This makes sense as the Makefile already has the XML files partitioned based on which approach they should use. In order to allow this change the 'maint print c-tdesc' command is given a new command option '-single-feature', which tells GDB which type of C file should be created. The makefile now supplies this flag to GDB. This did reveal a bug in features/Makefile, the rx.xml file was in the wrong list, this didn't matter previously as the actual choice of which approach to use was done in GDB. Now the Makefile decides, so placing each XML file in the correct list is critical. Tested this by doing 'make GDB=/path/to/gdb clean-cfiles cfiles' to regenerate all the C files from their XML source. There are no changes after this commit. gdb/ChangeLog: * features/Makefile (XMLTOC): Add rx.xml. (FEATURE_XMLFILES): Remove rx.xml. (FEATURE_CFILES rule): Pass '-single-feature' flag. * features/rx.c: Regenerate. * features/rx.xml: Wrap in `target` tags, and reindent. * target-descriptions.c (struct maint_print_c_tdesc_options): New structure. (maint_print_c_tdesc_opt_def): New typedef. (maint_print_c_tdesc_opt_defs): New static global. (make_maint_print_c_tdesc_options_def_group): New function. (maint_print_c_tdesc_cmd): Make use of command line flags, only print single feature C file for target descriptions containing a single feature. (maint_print_c_tdesc_cmd_completer): New function. (_initialize_target_descriptions): Update call to register command completer, and include command line flag in help text. gdb/doc/ChangeLog: * gdb.texinfo (Maintenance Commands): Update description of 'maint print c-tdesc'.
2020-10-08gdb: Have allocate_target_description return a unique_ptrAndrew Burgess1-9/+9
Update allocate_target_description to return a target_desc_up, a specialisation of unique_ptr. This commit does not attempt to make use of the unique_ptr in the best possible way, in almost all cases we immediately release the pointer from within the unique_ptr and then continue as before. There are a few places where it was easy to handle the unique_ptr, and in these cases I've done that. Everything under gdb/features/* is auto-regenerated. There should be no user visible changes after this commit. gdb/ChangeLog: * arch/aarch32.c (aarch32_create_target_description): Release unique_ptr returned from allocate_target_description. * arch/aarch64.c (aarch64_create_target_description): Likewise. * arch/amd64.c (amd64_create_target_description): Likewise. * arch/arc.c (arc_create_target_description): Likewise. * arch/arm.c (arm_create_target_description): Likewise. * arch/i386.c (i386_create_target_description): Likewise. * arch/riscv.c (riscv_create_target_description): Update return type. Handle allocate_target_description returning a unique_ptr. (riscv_lookup_target_description): Update to handle unique_ptr. * arch/tic6x.c (tic6x_create_target_description): Release unique_ptr returned from allocate_target_description. * features/microblaze-with-stack-protect.c: Regenerate. * features/microblaze.c: Regenerate. * features/mips-dsp-linux.c: Regenerate. * features/mips-linux.c: Regenerate. * features/mips64-dsp-linux.c: Regenerate. * features/mips64-linux.c: Regenerate. * features/nds32.c: Regenerate. * features/nios2.c: Regenerate. * features/or1k.c: Regenerate. * features/rs6000/powerpc-32.c: Regenerate. * features/rs6000/powerpc-32l.c: Regenerate. * features/rs6000/powerpc-403.c: Regenerate. * features/rs6000/powerpc-403gc.c: Regenerate. * features/rs6000/powerpc-405.c: Regenerate. * features/rs6000/powerpc-505.c: Regenerate. * features/rs6000/powerpc-601.c: Regenerate. * features/rs6000/powerpc-602.c: Regenerate. * features/rs6000/powerpc-603.c: Regenerate. * features/rs6000/powerpc-604.c: Regenerate. * features/rs6000/powerpc-64.c: Regenerate. * features/rs6000/powerpc-64l.c: Regenerate. * features/rs6000/powerpc-7400.c: Regenerate. * features/rs6000/powerpc-750.c: Regenerate. * features/rs6000/powerpc-860.c: Regenerate. * features/rs6000/powerpc-altivec32.c: Regenerate. * features/rs6000/powerpc-altivec32l.c: Regenerate. * features/rs6000/powerpc-altivec64.c: Regenerate. * features/rs6000/powerpc-altivec64l.c: Regenerate. * features/rs6000/powerpc-e500.c: Regenerate. * features/rs6000/powerpc-e500l.c: Regenerate. * features/rs6000/powerpc-isa205-32l.c: Regenerate. * features/rs6000/powerpc-isa205-64l.c: Regenerate. * features/rs6000/powerpc-isa205-altivec32l.c: Regenerate. * features/rs6000/powerpc-isa205-altivec64l.c: Regenerate. * features/rs6000/powerpc-isa205-ppr-dscr-vsx32l.c: Regenerate. * features/rs6000/powerpc-isa205-ppr-dscr-vsx64l.c: Regenerate. * features/rs6000/powerpc-isa205-vsx32l.c: Regenerate. * features/rs6000/powerpc-isa205-vsx64l.c: Regenerate. * features/rs6000/powerpc-isa207-htm-vsx32l.c: Regenerate. * features/rs6000/powerpc-isa207-htm-vsx64l.c: Regenerate. * features/rs6000/powerpc-isa207-vsx32l.c: Regenerate. * features/rs6000/powerpc-isa207-vsx64l.c: Regenerate. * features/rs6000/powerpc-vsx32.c: Regenerate. * features/rs6000/powerpc-vsx32l.c: Regenerate. * features/rs6000/powerpc-vsx64.c: Regenerate. * features/rs6000/powerpc-vsx64l.c: Regenerate. * features/rs6000/rs6000.c: Regenerate. * features/rx.c: Regenerate. * features/s390-gs-linux64.c: Regenerate. * features/s390-linux32.c: Regenerate. * features/s390-linux32v1.c: Regenerate. * features/s390-linux32v2.c: Regenerate. * features/s390-linux64.c: Regenerate. * features/s390-linux64v1.c: Regenerate. * features/s390-linux64v2.c: Regenerate. * features/s390-te-linux64.c: Regenerate. * features/s390-tevx-linux64.c: Regenerate. * features/s390-vx-linux64.c: Regenerate. * features/s390x-gs-linux64.c: Regenerate. * features/s390x-linux64.c: Regenerate. * features/s390x-linux64v1.c: Regenerate. * features/s390x-linux64v2.c: Regenerate. * features/s390x-te-linux64.c: Regenerate. * features/s390x-tevx-linux64.c: Regenerate. * features/s390x-vx-linux64.c: Regenerate. * mips-tdep.c (_initialize_mips_tdep): Release unique_ptr returned from allocate_target_description. * target-descriptions.c (allocate_target_description): Update return type. (print_c_tdesc::visit_pre): Release unique_ptr returned from allocate_target_description. gdbserver/ChangeLog: * linux-low.cc (linux_process_target::handle_extended_wait): Release the unique_ptr returned from allocate_target_description. * linux-riscv-low.cc (riscv_target::low_arch_setup): Likewise. * linux-x86-low.cc (tdesc_amd64_linux_no_xml): Change type. (tdesc_i386_linux_no_xml): Change type. (x86_linux_read_description): Borrow pointer from unique_ptr object. (x86_target::get_ipa_tdesc_idx): Likewise. (initialize_low_arch): Likewise. * tdesc.cc (allocate_target_description): Update return type. gdbsupport/ChangeLog: * tdesc.h (allocate_target_description): Update return type.
2020-09-17Change management of tdesc_arch_dataTom Tromey1-11/+6
While working on something else, I noticed that tdesc_data_cleanup took a void* parameter. Looking more into this, I found that tdesc_use_registers expected a transfer of ownership. I think it's better to express this sort of thing via the type system, when possible. This patch changes tdesc_data_alloc to return a unique pointer, changes tdesc_use_registers to accept an rvalue reference, and then adapts all the users. Note that a deleter structure is introduced to avoid having to move tdesc_arch_data to the header file. 2020-09-17 Tom Tromey <tromey@adacore.com> * tic6x-tdep.c (tic6x_gdbarch_init): Update. * target-descriptions.h (struct tdesc_arch_data_deleter): New. (tdesc_arch_data_up): New typedef. (tdesc_use_registers, tdesc_data_alloc): Update. (tdesc_data_cleanup): Don't declare. * target-descriptions.c (tdesc_data_alloc): Return a tdesc_arch_data_up. (tdesc_arch_data_deleter::operator()): Rename from tdesc_data_cleanup. Change argument type. (tdesc_use_registers): Change early_data to an rvalue reference. (tdesc_use_registers): Don't use delete. * sparc-tdep.c (sparc32_gdbarch_init): Update. * s390-tdep.c (s390_gdbarch_init): Update. * rx-tdep.c (rx_gdbarch_init): Update. * rs6000-tdep.c (rs6000_gdbarch_init): Update. * riscv-tdep.c (riscv_gdbarch_init): Update. * or1k-tdep.c (or1k_gdbarch_init): Update. * nios2-tdep.c (nios2_gdbarch_init): Update. * nds32-tdep.c (nds32_gdbarch_init): Update. * mips-tdep.c (mips_gdbarch_init): Update. * microblaze-tdep.c (microblaze_gdbarch_init): Update. * m68k-tdep.c (m68k_gdbarch_init): Update. * i386-tdep.c (i386_gdbarch_init): Update. * arm-tdep.c (arm_gdbarch_init): Update. * arc-tdep.c (arc_tdesc_init): Update. (arc_gdbarch_init): Update. * aarch64-tdep.c (aarch64_gdbarch_init): Update.
2020-09-17Use htab_up in target-descriptions.cTom Tromey1-9/+7
This changes target-descriptions.c to use htab_up rather than explicit calls to htab_delete. gdb/ChangeLog 2020-09-17 Tom Tromey <tom@tromey.com> * target-descriptions.c (tdesc_use_registers): Use htab_up.
2020-09-14gdb: remove TYPE_VECTORSimon Marchi1-1/+1
gdb/ChangeLog: * gdbtypes.h (TYPE_VECTOR): Remove, replace all uses with type::is_vector. Change-Id: I1ac28755af44b1585c190553f9961288c8fb9137
2020-09-14gdb: add type::is_vector / type::set_is_vectorSimon Marchi1-1/+1
Add the `is_vector` and `set_is_vector` methods on `struct type`, in order to remove the `TYPE_VECTOR` macro. In this patch, the macro is changed to use the getter, so all the call sites of the macro that are used as a setter are changed to use the setter method directly. The next patch will remove the macro completely. gdb/ChangeLog: * gdbtypes.h (struct type) <is_vector, set_is_vector>: New methods. (TYPE_VECTOR): Use type::is_vector, change all write call sites to use type::set_is_vector. Change-Id: I415e8d169f058662e0750329bfa4017bea3ca0cb
2020-09-14gdb: add type::is_unsigned / type::set_is_unsignedSimon Marchi1-1/+2
Add the `is_unsigned` and `set_is_unsigned` methods on `struct type`, in order to remove the `TYPE_UNSIGNED` macro. In this patch, the `TYPE_UNSIGNED` macro is changed to use `type::is_unsigned`, so all the call sites that are used to set this property on a type are changed to use the new method. The next patch will remove the macro completely. gdb/ChangeLog: * gdbtypes.h (struct type) <is_unsigned, set_is_unsigned>: New methods. (TYPE_UNSIGNED): Use type::is_unsigned. Change all write call sites to use type::set_is_unsigned. Change-Id: Ib09ddce84eda160a801a8f288cccf61c8ef136bc
2020-09-11Add bfloat16 support for AVX512 register view.Felix Willgerodt1-0/+5
This adds support for the bfloat16 datatype, which can be seen as a short version of FP32, skipping the least significant 16 bits of the mantissa. Since the datatype is currently only supported by the AVX512 registers, the printing of bfloat16 values is only supported for xmm, ymm and zmm registers. gdb/ChangeLog: 2020-09-11 Moritz Riesterer <moritz.riesterer@intel.com> Felix Willgerodt <Felix.Willgerodt@intel.com> * gdbarch.sh: Added bfloat16 type. * gdbarch.c: Regenerated. * gdbarch.h: Regenerated. * gdbtypes.c (floatformats_bfloat16): New struct. (gdbtypes_post_init): Add builtin_bfloat16. * gdbtypes.h (struct builtin_type) <builtin_bfloat16>: New member. (floatformats_bfloat16): New struct. * i386-tdep.c (i386_zmm_type): Add field "v32_bfloat16" (i386_ymm_type): Add field "v16_bfloat16" (i386_gdbarch_init): Add set_gdbarch_bfloat16_format. * target-descriptions.c (make_gdb_type): Add case TDESC_TYPE_BFLOAT16. * gdbsupport/tdesc.cc (tdesc_predefined_types): New member bfloat16. * gdbsupport/tdesc.h (tdesc_type_kind): New member TDESC_TYPE_BFLOAT16. * features/i386/64bit-avx512.xml: Add bfloat16 type. * features/i386/64bit-avx512.c: Regenerated. * features/i386/64bit-sse.xml: Add bfloat16 type. * features/i386/64bit-sse.c: Regenerated. gdb/testsuite/ChangeLog: 2020-09-11 Moritz Riesterer <moritz.riesterer@intel.com> Felix Willgerodt <Felix.Willgerodt@intel.com> * x86-avx512bf16.c: New file. * x86-avx512bf16.exp: Likewise. * lib/gdb.exp (skip_avx512bf16_tests): New function.
2020-07-17gdb/riscv: delete target descriptions when gdb exitsAndrew Burgess1-0/+4
It was pointed out on IRC that the RISC-V target allocates target descriptions and stores them in a global map, and doesn't delete these target descriptions when GDB shuts down. This isn't a particular problem, the total number of target descriptions we can create is very limited so creating these on demand and holding them for the entire run on GDB seems reasonable. However, not deleting these objects on GDB exit means extra warnings are printed from tools like valgrind, and the address sanitiser, making it harder to spot real issues. As it's reasonably easy to have GDB correctly delete these objects on exit, lets just do that. I started by noticing that we already have a target_desc_up type, a wrapper around unique_ptr that calls a function that will correctly delete target descriptions, so I want to use that, but.... ...that type is declared in gdb/target-descriptions.h. If I try to include that file in gdb/arch/riscv.c I run into a problem, that file is compiled into both GDB and GDBServer. OK, I could guard the include with #ifdef, but surely we can do better. So then I decided to move the target_desc_up type into gdbsupport/tdesc.h, this is the interface file for generic code shared between GDB and GDBserver (relating to target descriptions). The actual implementation for the delete function still lives in gdb/target-description.c, but now gdb/arch/riscv.c can see the declaration. Problem solved.... ... but, though RISC-V doesn't use it I've now exposed the target_desc_up type to gdbserver, so in future someone _might_ start using it, which is fine, except right now there's no definition of the delete function - remember the delete I used is only defined in GDB code. No problem, I add an implementation of the delete operator into gdbserver/tdesc.cc, and all is good..... except.... I start getting this error from GCC: tdesc.cc:109:10: error: deleting object of polymorphic class type ‘target_desc’ which has non-virtual destructor might cause undefined behavior [-Werror=delete-non-virtual-dtor] Which is caused because gdbserver's target_desc type inherits from tdesc_element which has a virtual method, and so GCC worries that target_desc might be used as a base class. The solution is to declare gdbserver's target_desc class as final. This is fine so long as we never intent to inherit from target_desc (in gdbserver). But if we did then we'd want to make target_desc's destructor virtual anyway, so the error above would be resolved, and there wouldn't be an issue. gdb/ChangeLog: * arch/riscv.c (riscv_tdesc_cache): Change map type. (riscv_lookup_target_description): Return pointer out of unique_ptr. * target-descriptions.c (allocate_target_description): Add comment. (target_desc_deleter::operator()): Likewise. * target-descriptions.h (struct target_desc_deleter): Moved to gdbsupport/tdesc.h. (target_desc_up): Likewise. gdbserver/ChangeLog: * tdesc.cc (allocate_target_description): Add header comment. (target_desc_deleter::operator()): New function. * tdesc.h (struct target_desc): Declare as final. gdbsupport/ChangeLog: * tdesc.h (struct target_desc_deleter): Moved here from gdb/target-descriptions.h, extend comment. (target_desc_up): Likewise.
2020-06-25gdb: Extend target description processing of unknown registersAndrew Burgess1-1/+30
This commit adds a new step to the processing of a target description done in tdesc_use_registers, this new step is about how unknown registers are processed. Currently an architecture looks through the target description and calls tdesc_numbered_register for each register is was expecting (or hoping) to find. This builds up a map from GDB's register numbers to the tdesc_reg object. Later the architecture calls tdesc_use_registers. In tdesc_use_registers we build a hash with keys being all the tdesc_reg object pointers, from this hash we remove all of the tdesc_reg objects that were assigned register numbers using tdesc_numbered_register. Finally we walk through all of the tdesc_reg objects, and if it was not already assigned a number we assign that register the next available number. The problem with this is that the architecture has no visibility of which unknown registers exist, and which tdesc_feature the register came from, in some cases this might be important. For example, on RISC-V GDB overrides the use of tdesc_register_reggroup_p, with riscv_register_reggroup_p to modify some of the register group choices. In this function GDB wants to treat all registers from a particular feature in a certain way. This is fine for registers that GDB knows might be in that feature, but for unknown registers the RISC-V parts of GDB have no easy way to figure out which unknown registers exist, and what numbers they were assigned. We could figure this information out by probing the register structures after calling tdesc_use_registers, but this would be horrible, much better to have tdesc_use_registers tell the architecture about unknown registers. This is what this commit does. A new phase of tdesc_use_registers, just before the unknown registers are assigned a number, we loop over each tdesc_reg object, if it has not been assigned a number then we figure out what number would be assigned and then call back into the architecture passing the tdesc_feature, register name, and the proposed register number. The architecture is free to return the proposed register number, or it can return a different number (which has a result identical to having called tdesc_numbered_register). Alternatively the architecture can return -1 to indicate the register should be numbered later. After calling the callback for every tdesc_reg object any registers still don't have a number assigned (because the architecture returned -1), then a new register number is assigned, which might be different from the proposed number that was suggested earlier. This commit adds the general target-description parts of this mechanism. No targets are currently using this code. The RISC-V target will make use of this in the next commit. There should be no user visible changes after this commit. gdb/ChangeLog: * target-descriptions.c (tdesc_use_registers): Add new parameter a callback, use the callback (when not null) to help number unknown registers. * target-descriptions.h (tdesc_unknown_register_ftype): New typedef. (tdesc_use_registers): Add extra parameter to declaration.
2020-06-23gdb: New maintenance command to print XML target descriptionAndrew Burgess1-1/+38
This commit adds a new maintenance command that dumps the current target description as an XML document. This is a maintenance command as I currently only see this being useful for GDB developers, or for people debugging a new remote target. By default the command will print whatever the current target description is, whether this was delivered by the remote, loaded by the user from a file, or if it is a built in target within GDB. The command can also take an optional filename argument. In this case GDB loads a target description from the file, and then reprints it. This could be useful for testing GDB's parsing of target descriptions, or to check that GDB can successfully parse a particular XML description. It is worth noting that the XML description printed will not be an exact copy of the document fed into GDB. For example this minimal input file: <target> <feature name="abc"> <reg name="r1" bitsize="32"/> </feature> </target> Will produce this output: (gdb) maint print xml-tdesc path/to/file.xml <?xml version="1.0"?> <!DOCTYPE target SYSTEM "gdb-target.dtd"> <target> <feature name="abc"> <reg name="r1" bitsize="32" type="int" regnum="0"/> </feature> </target> Notice that GDB filled in both the 'type' and 'regnum' fields of the <reg>. I think this is actually a positive as it means we get to really understand how GDB processed the document, if GDB made some assumptions that differ to those the user expected then hopefully this will bring those issues to the users attention. To implement this I have tweaked the output produced by the print_xml_feature which is defined within the gdbsupport/ directory. The changes I have made to this class are: 1. The <architecture>...</architecture> tags are now not produced if the architecture name is NULL. 2. The <osabi>...</osabi> tags get a newline at the end. 3. And, the whole XML document is indented using white space in a nested fashion (as in the example output above). I think that these changes should be fine, the print_xml_feature class is used: 1. In gdbserver to generate an XML document to send as the target description to GDB. 2. In GDB as part of a self-check function, a target_desc is converted to XML then parsed back into a target_desc. We then check the before and after target_desc objects are the same. 3. In the new 'maint print xml-tdesc' command. In all of these use cases adding the extra white space should be fine. gdbsupport/ChangeLog: * tdesc.cc (print_xml_feature::visit_pre): Use add_line to add output content, and call indent as needed in all overloaded variants. (print_xml_feature::visit_post): Likewise. (print_xml_feature::visit): Likewise. (print_xml_feature::add_line): Two new overloaded functions. * tdesc.h (print_xml_feature::indent): New member function. (print_xml_feature::add_line): Two new overloaded member functions. (print_xml_feature::m_depth): New member variable. gdb/ChangeLog: * target-descriptions.c (tdesc_architecture_name): Protect against NULL pointer dereference. (maint_print_xml_tdesc_cmd): New function. (_initialize_target_descriptions): Register new 'maint print xml-tdesc' command and give it the filename completer. * NEWS: Mention new 'maint print xml-tdesc' command. gdb/testsuite/ChangeLog: * gdb.xml/tdesc-reload.c: New file. * gdb.xml/tdesc-reload.exp: New file. * gdb.xml/maint-xml-dump-01.xml: New file. * gdb.xml/maint-xml-dump-02.xml: New file. * gdb.xml/maint-xml-dump.exp: New file. gdb/doc/ChangeLog: * gdb.texinfo (Maintenance Commands): Document new 'maint print xml-desc' command.
2020-06-23gdb: Print compatible information within print_xml_featureAndrew Burgess1-10/+51
The gdbsupport directory contains a helper class print_xml_feature that is shared between gdb and gdbserver. This class is used for printing an XML representation of a target_desc object. Currently this class doesn't have the ability to print the <compatible> entities that can appear within a target description, I guess no targets have needed that functionality yet. The print_xml_feature classes API is based around operating on the target_desc class, however, the sharing between gdb and gdbserver is purely textural, we rely on their being a class called target_desc in both gdb and gdbserver, but there is no shared implementation. We then have a set of functions declared that operate on an object of type target_desc, and again these functions have completely separate implementations. Currently then the gdb version of target_desc contains a vector of bfd_arch_info pointers which represents the compatible entries from a target description. The gdbserver version of target_desc has no such information. Further, the gdbserver code doesn't seem to include the bfd headers, and so doesn't know about the bfd types. I was reluctant to include the bfd headers into gdbserver just so I can reference the compatible information, which isn't (currently) even needed in gdbserver. So, the approach I take in this patch is to wrap the compatible information into a new helper class. This class is declared in the gdbsupport library, but implemented separately in both gdb and gdbserver. In gdbserver the class is empty. The compatible information within the gdbserver is an empty list, of empty classes. In gdb the class contains a pointer to the bfd_arch_info object. With this in place we can now add support to print_xml_feature for printing the compatible information if it is present. In the gdbserver code this will never happen, as the gdbserver never has any compatible information. But in gdb, this code will trigger when appropriate. gdb/ChangeLog: * target-descriptions.c (class tdesc_compatible_info): New class. (struct target_desc): Change type of compatible vector. (tdesc_compatible_p): Update for change in type of target_desc::compatible. (tdesc_compatible_info_list): New function. (tdesc_compatible_info_arch_name): New function. (tdesc_add_compatible): Update for change in type of target_desc::compatible. (print_c_tdesc::visit_pre): Likewise. gdbserver/ChangeLog: * tdesc.cc (struct tdesc_compatible_info): New struct. (tdesc_compatible_info_list): New function. (tdesc_compatible_info_arch_name): New function. gdbsupport/ChangeLog: * tdesc.cc (print_xml_feature::visit_pre): Print compatible information. * tdesc.h (struct tdesc_compatible_info): Declare new struct. (tdesc_compatible_info_up): New typedef. (tdesc_compatible_info_list): Declare new function. (tdesc_compatible_info_arch_name): Declare new function.
2020-06-23gdb: Allow target description to be dumped even when it is remoteAndrew Burgess1-4/+7
The maintenance command 'maintenance print c-tdesc' can only print the target description if it was loaded from a local file, or if the local filename is passed to the maintenance command as an argument. Sometimes it would be nice to know what target description GDB was given by the remote, however, if I connect to a remote target and try this command I see this: (gdb) maintenance print c-tdesc The current target description did not come from an XML file. (gdb) Which is not very helpful. This commit changes things so that if the description came from the remote end then GDB will use a fake filename 'fetched from target' as the filename for the description, GDB will then create the C description of the target as though it came from this file. Example output would look like this (I snipped the feature creation from the middle as that hasn't changed): (gdb) maintenance print c-tdesc /* THIS FILE IS GENERATED. -*- buffer-read-only: t -*- vi:set ro: Original: fetched from target */ #include "defs.h" #include "osabi.h" #include "target-descriptions.h" struct target_desc *tdesc_fetched_from_target; static void initialize_tdesc_fetched_from_target (void) { struct target_desc *result = allocate_target_description (); struct tdesc_feature *feature; /* ... features created here ... */ tdesc_fetched_from_target = result; } (gdb) In order to support using 'fetched from target' I had to update the print_c_tdesc code to handle filenames that include a space. This has the benefit that we can now print out real files with spaces in the name, for example the file 'with space.xml': (gdb) maint print c-tdesc with space.xml I originally added this functionality so I could inspect the description passed to GDB by the remote target. After using this for a while I realised that actually having GDB recreate the XML would be even better, so a later commit will add that functionality too. Still, given how small this patch is I thought it might be nice to include this in GDB anyway. While I was working on this anyway I've added filename command completion to this command. gdb/ChangeLog: * target-descriptions.c (print_c_tdesc::print_c_tdesc): Change whitespace to underscore. (maint_print_c_tdesc_cmd): Use fake filename for target descriptions that came from the target. (_initialize_target_descriptions): Add filename command completion for 'maint print c-tdesc'.
generated by cgit v1.1 at 2024-11-22 00:37:01 +0000