aboutsummaryrefslogtreecommitdiff
path: root/gdb/f-lang.c
AgeCommit message (Collapse)AuthorFilesLines
2024-04-25gdb: remove gdbcmd.hSimon Marchi1-1/+1
Most files including gdbcmd.h currently rely on it to access things actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make things easy, replace all includes of gdbcmd.h with includes of cli/cli-cmds.h. This might lead to some unused includes of cli/cli-cmds.h, but it's harmless, and much faster than going through the 170 or so files by hand. Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f Approved-By: Tom Tromey <tom@tromey.com>
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi1-1/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-02-05Handling of arrays with optimized-out boundsTom Tromey1-1/+1
In Ada, sometimes the compiler must emit array bounds by referencing an artificial variable that's created for this purpose. However, with optimization enabled, these variables can be optimized away. Currently this can result in displays like: (gdb) print mumble $1 = (warning: unable to get bounds of array, assuming null array ) This patch changes this to report that the array is optimized-out, instead, which is closer to the truth, and more generally useful. For example, Python pretty-printers can now recognize this situation. In order to accomplish this, I introduced a new PROP_OPTIMIZED_OUT enumerator and changed one place to use it. Reusing the "unknown" state wouldn't work properly, because in C it is normal for array bounds to be unknown.
2024-01-28Use domain_search_flags in lookup_symbol et alTom Tromey1-1/+1
This changes lookup_symbol and associated APIs to accept domain_search_flags rather than a domain_enum. Note that this introduces some new constants to Python and Guile. I chose to break out the documentation patch for this, because the internals here do not change until a later patch, and it seemed simpler to patch the docs just once, rather than twice.
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-11-21gdb: Replace gdb::optional with std::optionalLancelot Six1-1/+1
Since GDB now requires C++17, we don't need the internally maintained gdb::optional implementation. This patch does the following replacing: - gdb::optional -> std::optional - gdb::in_place -> std::in_place - #include "gdbsupport/gdb_optional.h" -> #include <optional> This change has mostly been done automatically. One exception is gdbsupport/thread-pool.* which did not use the gdb:: prefix as it already lives in the gdb namespace. Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-08-31gdb: remove TYPE_FIELD_ARTIFICIALSimon Marchi1-1/+1
Replace with type::field + field::is_artificial. Change-Id: Ie3bacae49d9bd02e83e504c1ce01470aba56a081 Approved-By: Tom Tromey <tom@tromey.com>
2023-06-09Use scoped_value_mark in two more placesTom Tromey1-8/+7
I found a couple of spots that could use scoped_value_mark. One of them is a spot that didn't consider the possibility that value_mark can return NULL. I tend to doubt this can be seen in this context, but nevertheless this is safer. Regression tested on x86-64 Fedora 36.
2023-06-05gdb: building inferior strings from within GDBAndrew Burgess1-0/+10
History Of This Patch ===================== This commit aims to address PR gdb/21699. There have now been a couple of attempts to fix this issue. Simon originally posted two patches back in 2021: https://sourceware.org/pipermail/gdb-patches/2021-July/180894.html https://sourceware.org/pipermail/gdb-patches/2021-July/180896.html Before Pedro then posted a version of his own: https://sourceware.org/pipermail/gdb-patches/2021-July/180970.html After this the conversation halted. Then in 2023 I (Andrew) also took a look at this bug and posted two versions: https://sourceware.org/pipermail/gdb-patches/2023-April/198570.html https://sourceware.org/pipermail/gdb-patches/2023-April/198680.html The approach taken in my first patch was pretty similar to what Simon originally posted back in 2021. My second attempt was only a slight variation on the first. Pedro then pointed out his older patch, and so we arrive at this patch. The GDB changes here are mostly Pedro's work, but updated by me (Andrew), any mistakes are mine. The tests here are a combinations of everyone's work, and the commit message is new, but copies bits from everyone's earlier work. Problem Description =================== Bug PR gdb/21699 makes the observation that using $_as_string with GDB's printf can cause GDB to print unexpected data from the inferior. The reproducer is pretty simple: #include <stddef.h> static char arena[100]; /* Override malloc() so value_coerce_to_target() gets a known pointer, and we know we"ll see an error if $_as_string() gives a string that isn't null terminated. */ void *malloc (size_t size) { memset (arena, 'x', sizeof (arena)); if (size > sizeof (arena)) return NULL; return arena; } int main () { return 0; } And then in a GDB session: $ gdb -q test Reading symbols from /tmp/test... (gdb) start Temporary breakpoint 1 at 0x4004c8: file test.c, line 17. Starting program: /tmp/test Temporary breakpoint 1, main () at test.c:17 17 return 0; (gdb) printf "%s\n", $_as_string("hello") "hello"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (gdb) quit The problem above is caused by how value_cstring is used within py-value.c, but once we understand the issue then it turns out that value_cstring is used in an unexpected way in many places within GDB. Within py-value.c we have a null-terminated C-style string. We then pass a pointer to this string, along with the length of this string (so not including the null-character) to value_cstring. In value_cstring GDB allocates an array value of the given character type, and copies in requested number of characters. However value_cstring does not add a null-character of its own. This means that the value created by calling value_cstring is only null-terminated if the null-character is included in the passed in length. In py-value.c this is not the case, and indeed, in most uses of value_cstring, this is not the case. When GDB tries to print one of these strings the value contents are pushed to the inferior, and then read back as a C-style string, that is, GDB reads inferior memory until it finds a null-terminator. For the py-value.c case, no null-terminator is pushed into the inferior, so GDB will continue reading inferior memory until a null-terminator is found, with unpredictable results. Patch Description ================= The first thing this patch does is better define what the arguments for the two function value_cstring and value_string should represent. The comments in the header file are updated to describe whether the length argument should, or should not, include a null-character. Also, the data argument is changed to type gdb_byte. The functions as they currently exist will handle wide-characters, in which case more than one 'char' would be needed for each character. As such using gdb_byte seems to make more sense. To avoid adding casts throughout GDB, I've also added an overload that still takes a 'char *', but asserts that the character type being used is of size '1'. The value_cstring function is now responsible for adding a null character at the end of the string value it creates. However, once we start looking at how value_cstring is used, we realise there's another, related, problem. Not every language's strings are null terminated. Fortran and Ada strings, for example, are just an array of characters, GDB already has the function value_string which can be used to create such values. Consider this example using current GDB: (gdb) set language ada (gdb) p $_gdb_setting("arch") $1 = (97, 117, 116, 111) (gdb) ptype $ type = array (1 .. 4) of char (gdb) p $_gdb_maint_setting("test-settings string") $2 = (0) (gdb) ptype $ type = array (1 .. 1) of char This shows two problems, first, the $_gdb_setting and $_gdb_maint_setting functions are calling value_cstring using the builtin_char character, rather than a language appropriate type. In the first call, the 'arch' case, the value_cstring call doesn't include the null character, so the returned array only contains the expected characters. But, in the $_gdb_maint_setting example we do end up including the null-character, even though this is not expected for Ada strings. This commit adds a new language method language_defn::value_string, this function takes a pointer and length and creates a language appropriate value that represents the string. For C, C++, etc this will be a null-terminated string (by calling value_cstring), and for Fortran and Ada this can be a bounded array of characters with no null terminator. Additionally, this new language_defn::value_string function is responsible for selecting a language appropriate character type. After this commit the only calls to value_cstring are from the C expression evaluator and from the default language_defn::value_string. And the only calls to value_string are from Fortan, Ada, and ObjectC related code. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21699 Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Co-Authored-By: Pedro Alves <pedro@palves.net> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Use type allocator for array typesTom Tromey1-4/+4
This changes the array type creation functions to accept a type allocator, and updates all the callers. Note that symbol readers should generally allocate on the relevant objfile, regardless of the placement of the index type of the array, which is what this patch implements. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Use type allocator for range typesTom Tromey1-4/+8
This changes the range type creation functions to accept a type allocator, and updates all the callers. Note that symbol readers should generally allocate on the relevant objfile, regardless of the underlying type of the range, which is what this patch implements. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Unify arch_float_type and init_float_typeTom Tromey1-4/+4
This unifies arch_float_type and init_float_type by using a type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Unify arch_boolean_type and init_boolean_typeTom Tromey1-4/+4
This unifies arch_boolean_type and init_boolean_type by using a type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Unify arch_integer_type and init_integer_typeTom Tromey1-4/+4
This unifies arch_integer_type and init_integer_type by using a type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Remove arch_typeTom Tromey1-3/+5
This removes arch_type, replacing all uses with the new type allocator. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Reuse existing builtin typesTom Tromey1-2/+1
This changes a few spots to reuse the existing builting "void" type, rather than construct a new one. Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Remove deprecated_lval_hackTom Tromey1-4/+4
This removes deprecated_lval_hack and the VALUE_LVAL macro, replacing all uses with a call to value::lval. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn various value copying-related functions into methodsTom Tromey1-4/+4
This patch turns a grab bag of value functions to methods of value. These are done together because their implementations are interrelated. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn remaining value_contents functions into methodsTom Tromey1-11/+11
This turns the remaining value_contents functions -- value_contents, value_contents_all, value_contents_for_printing, and value_contents_for_printing_const -- into methods of value. It also converts the static functions require_not_optimized_out and require_available to be private methods. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_zero into static "constructor"Tom Tromey1-2/+2
This turns value_zero into a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn allocate_value into a static "constructor"Tom Tromey1-3/+3
This changes allocate_value to be a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_address and set_value_address functions into methodsTom Tromey1-9/+9
This changes the value_address and set_value_address functions to be methods of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Convert value_lval_const and deprecated_lval_hack to methodsTom Tromey1-1/+1
This converts the value_lval_const and deprecated_lval_hack functions to be methods on value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_lazy and set_value_lazy functions into methodsTom Tromey1-4/+4
This changes the value_lazy and set_value_lazy functions to be methods of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_type into methodTom Tromey1-57/+57
This changes value_type to be a method of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
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-09-21gdb: remove TYPE_LENGTHSimon Marchi1-30/+30
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-09-21gdb: remove TYPE_TARGET_TYPESimon Marchi1-19/+19
Remove the macro, replace all uses by calls to type::target_type. Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
2022-08-04Use registry in gdbarchTom Tromey1-7/+11
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-11gdb/fortran: rewrite intrinsic handling and add some missing overloadsNils-Christian Kempke1-48/+164
The operators FLOOR, CEILING, CMPLX, LBOUND, UBOUND, and SIZE accept (some only with Fortran 2003) the optional parameter KIND. This parameter determines the kind of the associated return value. So far, implementation of this kind parameter has been missing in GDB. Additionally, the one argument overload for the CMPLX intrinsic function was not yet available. This patch adds overloads for all above mentioned functions to the Fortran intrinsics handling in GDB. It re-writes the intrinsic function handling section to use the helper methods wrap_unop_intrinsic/wrap_binop_intrinsic/wrap_triop_intrinsic. These methods define the action taken when a Fortran intrinsic function is called with a certain amount of arguments (1/2/3). The helper methods fortran_wrap2_kind and fortran_wrap3_kind have been added as equivalents to the existing wrap and wrap2 methods. After adding more overloads to the intrinsics handling, some of the operation names were no longer accurate. E.g. UNOP_FORTRAN_CEILING has been renamed to FORTRAN_CEILING as it is no longer a purely unary intrinsic function. This patch also introduces intrinsic functions with one, two, or three arguments to the Fortran parser and the UNOP_OR_BINOP_OR_TERNOP_INTRINSIC token has been added.
2022-04-11gdb/fortran: Change GDB print for fortran default typesNils-Christian Kempke1-2/+2
Currently, when asking GDB to print the type of a Fortran default type such as INTEGER or REAL, GDB will return the default name of that type, e.g. "integer"/"real": (gdb) ptype integer type = integer (gdb) ptype real type = real For LOGICAL and COMPLEX it would return the actual underlying types (gdb) ptype logical type = logical*4 (gdb) ptype complex type = complex*4 Similarly, GDB would print the default integer type for the underlying default type: (gdb) ptype integer*4 type = integer (gdb) ptype real*4 type = real (gdb) ptype logical type = logical*4 (gdb) ptype complex*4 type = complex*4 This is inconsistent and a bit confusing. Both options somehow indicate what the internal underlying type for the default type is - but I think the logical/complex version is a bit clearer. Consider again: (gdb) ptype integer type = integer This indicates to a user that the type of "integer" is Fortran's default integer type. Without examining "ptype integer*4" I would expect, that any variable declared integer in the actual code would also fit into a GDB integer. But, since we cannot adapt out internal types to the compiler flags used at compile time of a debugged binary, this might be wrong. Consider debugging Fortran code compiled with GNU and e.g. the "-fdefault-integer-8" flag. In this case the gfortran default integer would be integer*8 while GDB internally still would use a builtin_integer, so an integer of the size of an integer*4 type. On the other hand having GDB print (gdb) ptype integer type = integer*4 makes this clearer. I would still be tempted to fit a variable declared integer in the code into a GDB integer - but at least ptype would directly tell me what is going on. Note, that when debugging a binary compiled with "-fdefault-integer-8" a user will always see the actual underlying type of any variable declared "integer" in the Fortran code. So having the code program test integer :: a = 5 print *, a ! breakpt end program test will, when breaking at breakpt print (gdb) ptype var type = integer(kind=4) or (gdb) ptype var type = integer(kind=8) depending on the compiler flag. This patch changes the outputs for the REAL and INTEGER default types to actually print the internally used type over the default type name. The new behavior for the above examples is: (gdb) ptype integer type = integer*4 (gdb) ptype integer*4 type = integer*4 Existing testcases have been adapted to reflect the new behavior.
2022-04-11gdb/fortran: clean-up Fortran intrinsic typesNils-Christian Kempke1-12/+12
The currently implemented intrinsic type handling for Fortran missed some tokens and their parsing. While still not all Fortran type kinds are implemented this patch at least makes the currently handled types consistent. As an example for what this patch does, consider the intrinsic type INTEGER. GDB implemented the handling of the keywords "integer" and "integer_2" but missed "integer_4" and "integer_8" even though their corresponding internal types were already available as the Fortran builtin types builtin_integer and builtin_integer_s8. Similar problems applied to LOGICAL, REAL, and COMPLEX. This patch adds all missing tokens and their parsing. Whenever a section containing the type handling was touched, it also was reordered to be in a more easy to grasp order. All INTEGER/REAL/LOGICAL/COMPLEX types were grouped together and ordered ascending in their size making a missing one more easy to spot. Before this change GDB would print the following when tyring to use the INTEGER keywords: (gdb) set language fortran (gdb) ptype integer*1 unsupported kind 1 for type integer (gdb) ptype integer_1 No symbol table is loaded. Use the "file" command. (gdb) ptype integer*2 type = integer*2 (gdb) ptype integer_2 type = integer*2 (gdb) ptype integer*4 type = integer (gdb) ptype integer_4 No symbol table is loaded. Use the "file" command. (gdb) ptype integer*8 type = integer*8 (gdb) ptype integer_8 No symbol table is loaded. Use the "file" command. (gdb) ptype integer type = integer With this patch all keywords are available and the GDB prints: (gdb) set language fortran (gdb) ptype integer*1 type = integer*1 (gdb) ptype integer_1 type = integer*1 (gdb) ptype integer*2 type = integer*2 (gdb) ptype integer_2 type = integer*2 (gdb) ptype integer*4 type = integer*4 (gdb) ptype integer_4 type = integer*4 (gdb) ptype integer*8 type = integer*8 (gdb) ptype integer_8 type = integer*8 (gdb) ptype integer type = integer The described changes have been applied to INTEGER, REAL, COMPLEX, and LOGICAL. Existing testcases have been adapted to reflect the new behavior. Tests for formerly missing types have been added.
2022-04-11gdb/fortran: change default logical type to builtin_logicalNils-Christian Kempke1-1/+1
According to the Fortran standard, logical is of the size of a 'single numeric storage unit' (just like real and integer). For gfortran, flang and ifx/ifort this storage unit (or the default logical type) is of size kind 4, actually occupying 4 bytes of storage, and so the default type for logical expressions in Fortran should probably also be Logical*4 and not Logical*2. I adapted GDB's behavior to be in line with gfortran/ifort/ifx/flang.
2022-04-11gdb/fortran: reformat build_fortran_types in f-lang.cNils-Christian Kempke1-10/+8
Add a few newlines after the type definitions and remove some unnecessary linebreaks.
2022-04-11gdb/fortran: fix complex type in Fortran builtin typesNils-Christian Kempke1-8/+8
Before this patch things like (gdb) ptype complex*8 complex*16 (gdb) ptype complex*4 complex*8 were possible in GDB, which seems confusing for a user. The reason is a mixup in the implementation of the Fortran COMPLEX type. In Fortran the "*X" after a type would normally (I don't think this is language required) specify the type's size in memory. For the COMPLEX type the kind parameters usually (at least for GNU, Intel, Flang) specify not the size of the whole type but the size of the individual two REALs used to form the COMPLEX. Thus, a COMPLEX*4 will usually consist of two REAL*4s. Internally this type was represented by a builtin_complex_s8 - but here I think the s8 actually meant the raw size of the type. This is confusing and I renamed the types (e.g. builting_complex_s8 became builtin_complex_s4 according to its most common useage) and their printed names to their language equivalent. Additionally, I added the default COMPLEX type "COMPLEX" being the same as a COMPLEX*4 (as is normally the case) and removed the latter. I added a few tests for this new behavior as well. The new behavior is (gdb) ptype complex*8 complex*8 (gdb) ptype complex*4 complex*4
2022-04-11gdb/f-lang: remove hidden ^L charactersNils-Christian Kempke1-3/+0
2022-04-11gdb/f-lang: add Integer*1 to Fortran builtin typesNils-Christian Kempke1-0/+4
Add builtin_integer_s1 of size TARGET_CHAR_BIT to Fortran builtin types.
2022-03-29Unify gdb printf functionsTom Tromey1-6/+6
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-01-19Respect `set print array-indexes' with Fortran arraysMaciej W. Rozycki1-3/+19
Add `set print array-indexes' handling for Fortran arrays. Currently the setting is ignored and indices are never shown. Keep track of the most recent index handled so that any outstanding repeated elements printed when the limit set by `set print elements' is hit have the correct index shown. Output now looks like: (gdb) set print array-indexes on (gdb) print array_1d $1 = ((-2) = 1, (-1) = 1, (0) = 1, (1) = 1, (2) = 1) (gdb) set print repeats 4 (gdb) set print elements 12 (gdb) print array_2d $2 = ((-2) = ((-2) = 2, <repeats 5 times>) (-1) = ((-2) = 2, <repeats 5 times>) (0) = ((-2) = 2, (-1) = 2, ...) ...) (gdb) for a 5-element vector and a 5 by 5 array filled with the value of 2.
2022-01-19Respect `set print repeats' with Fortran arraysMaciej W. Rozycki1-1/+1
Implement `set print repeats' handling for Fortran arrays. Currently the setting is ignored and always treated as if no limit was set. Unlike the generic array walker implemented decades ago the Fortran one is a proper C++ class. Rather than trying to mimic the old walker then, which turned out a bit of a challenge where interacting with the `set print elements' setting, write it entirely from scratch, by adding an extra specialization handler method for processing dimensions other than the innermost one and letting the specialization class call the `walk_1' method from the handler as it sees fit. This way repeats can be tracked and the next inner dimension recursed into as a need arises only, or unconditionally in the base class. Keep track of the dimension number being handled in the class rather as a parameter to the walker so that it does not have to be passed across by the specialization class. Use per-dimension element count tracking, needed to terminate processing early when the limit set by `set print elements' is hit. This requires extra care too where the limit triggers exactly where another element that is a subarray begins. In that case rather than recursing we need to terminate processing or lone `(...)' would be printed. Additionally if the skipped element is the last one in the current dimension we need to print `...' by hand, because `continue_walking' won't print it at the upper level, because it can see the last element has already been taken care of. Preserve the existing semantics of `set print elements' where the total count of the elements handled is matched against the trigger level which is unlike with the C/C++ array printer where the per-dimension element count is used instead. Output now looks like: (gdb) set print repeats 4 (gdb) print array_2d $1 = ((2, <repeats 5 times>) <repeats 5 times>) (gdb) set print elements 12 (gdb) print array_2d $2 = ((2, <repeats 5 times>) (2, <repeats 5 times>) (2, 2, ...) ...) (gdb) for a 5 by 5 array filled with the value of 2. Amend existing test cases accordingly that rely on the current incorrect behavior and explicitly request that there be no limit for printing repeated elements there. Add suitable test cases as well covering sliced arrays in particular. Co-Authored-By: Andrew Burgess <andrew.burgess@embecosm.com>
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-10-28gdb: add add_setshow_prefix_cmdSimon Marchi1-7/+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-25gdb: change functions returning value contents to use gdb::array_viewSimon Marchi1-17/+14
The bug fixed by this [1] patch was caused by an out-of-bounds access to a value's content. The code gets the value's content (just a pointer) and then indexes it with a non-sensical index. This made me think of changing functions that return value contents to return array_views instead of a plain pointer. This has the advantage that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view are checked, making bugs more apparent / easier to find. This patch changes the return types of these functions, and updates callers to call .data() on the result, meaning it's not changing anything in practice. Additional work will be needed (which can be done little by little) to make callers propagate the use of array_view and reap the benefits. [1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
2021-06-25gdb: use gdb::optional instead of passing a pointer to gdb::array_viewAndrew Burgess1-1/+1
Following on from the previous commit, this commit changes the API of value_struct_elt to take gdb::optional<gdb::array_view<value *>> instead of a pointer to the gdb::array_view. This makes the optional nature of the array_view parameter explicit. This commit is purely a refactoring commit, there should be no user visible change after this commit. I have deliberately kept this refactor separate from the previous two commits as this is a more extensive change, and I'm not 100% sure that using gdb::optional for the parameter type, instead of a pointer, is going to be to everyone's taste. If there's push back on this patch then this one can be dropped from the series. gdb/ChangeLog: * ada-lang.c (desc_bounds): Use '{}' instead of NULL to indicate an empty gdb::optional when calling value_struct_elt. (desc_data): Likewise. (desc_one_bound): Likewise. * eval.c (structop_base_operation::evaluate_funcall): Pass gdb::array_view, not a gdb::array_view* to value_struct_elt. (eval_op_structop_struct): Use '{}' instead of NULL to indicate an empty gdb::optional when calling value_struct_elt. (eval_op_structop_ptr): Likewise. * f-lang.c (fortran_structop_operation::evaluate): Likewise. * guile/scm-value.c (gdbscm_value_field): Likewise. * m2-lang.c (eval_op_m2_high): Likewise. (eval_op_m2_subscript): Likewise. * opencl-lang.c (opencl_structop_operation::evaluate): Likewise. * python/py-value.c (valpy_getitem): Likewise. * rust-lang.c (rust_val_print_str): Likewise. (rust_range): Likewise. (rust_subscript): Likewise. (eval_op_rust_structop): Likewise. (rust_aggregate_operation::evaluate): Likewise. * valarith.c (value_user_defined_op): Likewise. * valops.c (search_struct_method): Change parameter type, update function body accordingly, and update header comment. (value_struct_elt): Change parameter type, update function body accordingly. * value.h (value_struct_elt): Update declaration.
2021-05-12gdb: generate the prefix name for prefix commands on demandMarco Barisione1-2/+2
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-04-07gdb/fortran: handle dynamic types within arrays and structuresAndrew Burgess1-0/+40
This commit replaces this patch: https://sourceware.org/pipermail/gdb-patches/2021-January/174933.html which was itself a replacement for this patch: https://sourceware.org/pipermail/gdb-patches/2020-July/170335.html The motivation behind the original patch can be seen in the new test, which currently gives a GDB session like this: (gdb) ptype var8 type = Type type6 PTR TO -> ( Type type2 :: ptr_1 ) PTR TO -> ( Type type2 :: ptr_2 ) End Type type6 (gdb) ptype var8%ptr_2 type = PTR TO -> ( Type type2 integer(kind=4) :: spacer Type type1, allocatable :: t2_array(:) <------ Issue #1 End Type type2 ) (gdb) ptype var8%ptr_2%t2_array Cannot access memory at address 0x38 <------ Issue #2 (gdb) Issue #1: Here we see the abstract dynamic type, rather than the resolved concrete type. Though in some cases the user might be interested in the abstract dynamic type, I think that in most cases showing the resolved concrete type will be of more use. Plus, the user can always figure out the dynamic type (by source code inspection if nothing else) given the concrete type, but it is much harder to figure out the concrete type given only the dynamic type. Issue #2: In this example, GDB evaluates the expression in EVAL_AVOID_SIDE_EFFECTS mode (due to ptype). The value returned for var8%ptr_2 will be a non-lazy, zero value of the correct dynamic type. However, when GDB asks about the type of t2_array this requires GDB to access the value of var8%ptr_2 in order to read the dynamic properties. As this value was forced to zero (thanks to the use of EVAL_AVOID_SIDE_EFFECTS) then GDB ends up accessing memory at a base of zero plus some offset. Both this patch, and my previous two attempts, have all tried to resolve this problem by stopping EVAL_AVOID_SIDE_EFFECTS replacing the result value with a zero value in some cases. This new patch is influenced by how Ada handles its tagged typed. There are plenty of examples in ada-lang.c, but one specific case is ada_structop_operation::evaluate. When GDB spots that we are dealing with a tagged (dynamic) type, and we're in EVAL_AVOID_SIDE_EFFECTS mode, then GDB re-evaluates the child operation in EVAL_NORMAL mode. This commit handles two cases like this specifically for Fortran, a new fortran_structop_operation, and the already existing fortran_undetermined, which is where we handle array accesses. In these two locations we spot when we are dealing with a dynamic type and re-evaluate the child operation in EVAL_NORMAL mode so that we are able to access the dynamic properties of the type. The rest of this commit message is my attempt to record why my previous patches failed. To understand my second patch, and why it failed lets consider two expressions, this Fortran expression: (gdb) ptype var8%ptr_2%t2_array --<A> Operation: STRUCTOP_STRUCT --(1) Operation: STRUCTOP_STRUCT --(2) Operation: OP_VAR_VALUE --(3) Symbol: var8 Block: 0x3980ac0 String: ptr_2 String: t2_array And this C expression: (gdb) ptype ptr && ptr->a == 3 --<B> Operation: BINOP_LOGICAL_AND --(4) Operation: OP_VAR_VALUE --(5) Symbol: ptr Block: 0x45a2a00 Operation: BINOP_EQUAL --(6) Operation: STRUCTOP_PTR --(7) Operation: OP_VAR_VALUE --(8) Symbol: ptr Block: 0x45a2a00 String: a Operation: OP_LONG --(9) Type: int Constant: 0x0000000000000003 In expression <A> we should assume that t2_array is of dynamic type. Nothing has dynamic type in expression <B>. This is how GDB currently handles expression <A>, in all cases, EVAL_AVOID_SIDE_EFFECTS or EVAL_NORMAL, an OP_VAR_VALUE operation always returns the real value of the symbol, this is not forced to a zero value even in EVAL_AVOID_SIDE_EFFECTS mode. This means that (3), (5), and (8) will always return a real lazy value for the symbol. However a STRUCTOP_STRUCT will always replace its result with a non-lazy, zero value with the same type as its result. So (2) will lookup the field ptr_2 and create a zero value with that type. In this case the type is a pointer to a dynamic type. Then, when we evaluate (1) to figure out the resolved type of t2_array, we need to read the types dynamic properties. These properties are stored in memory relative to the objects base address, and the base address is in var8%ptr_2, which we already figured out has the value zero. GDB then evaluates the DWARF expressions that take the base address, add an offset and dereference. GDB then ends up trying to access addresses like 0x16, 0x8, etc. To fix this, I proposed changing STRUCTOP_STRUCT so that instead of returning a zero value we instead returned the actual value representing the structure's field in the target. My thinking was that GDB would not try to access the value's contents unless it needed it to resolve a dynamic type. This belief was incorrect. Consider expression <B>. We already know that (5) and (8) will return real values for the symbols being referenced. The BINOP_LOGICAL_AND, operation (4) will evaluate both of its children in EVAL_AVOID_SIDE_EFFECTS in order to get the types, this is required for C++ operator lookup. This means that even if the value of (5) would result in the BINOP_LOGICAL_AND returning false (say, ptr is NULL), we still evaluate (6) in EVAL_AVOID_SIDE_EFFECTS mode. Operation (6) will evaluate both children in EVAL_AVOID_SIDE_EFFECTS mode, operation (9) is easy, it just returns a value with the constant packed into it, but (7) is where the problem lies. Currently in GDB this STRUCTOP_STRUCT will always return a non-lazy zero value of the correct type. When the results of (7) and (9) are back in the BINOP_LOGICAL_AND operation (6), the two values are passed to value_equal which performs the comparison and returns a result. Note, the two things compared here are the immediate value (9), and a non-lazy zero value from (7). However, with my proposed patch operation (7) no longer returns a zero value, instead it returns a lazy value representing the actual value in target memory. When we call value_equal in (6) this code causes GDB to try and fetch the actual value from target memory. If `ptr` is NULL then this will cause GDB to access some invalid address at an offset from zero, this will most likely fail, and cause GDB to throw an error instead of returning the expected type. And so, we can now describe the problem that we're facing. The way GDB's expression evaluator is currently written we assume, when in EVAL_AVOID_SIDE_EFFECTS mode, that any value returned from a child operation can safely have its content read without throwing an error. If child operations start returning real values (instead of the fake zero values), then this is simply not true. If we wanted to work around this then we would need to rewrite almost all operations (I would guess) so that EVAL_AVOID_SIDE_EFFECTS mode does not cause evaluation of an operation to try and read the value of a child operation. As an example, consider this current GDB code from eval.c: struct value * eval_op_equal (struct type *expect_type, struct expression *exp, enum noside noside, enum exp_opcode op, struct value *arg1, struct value *arg2) { if (binop_user_defined_p (op, arg1, arg2)) { return value_x_binop (arg1, arg2, op, OP_NULL, noside); } else { binop_promote (exp->language_defn, exp->gdbarch, &arg1, &arg2); int tem = value_equal (arg1, arg2); struct type *type = language_bool_type (exp->language_defn, exp->gdbarch); return value_from_longest (type, (LONGEST) tem); } } We could change this function to be this: struct value * eval_op_equal (struct type *expect_type, struct expression *exp, enum noside noside, enum exp_opcode op, struct value *arg1, struct value *arg2) { if (binop_user_defined_p (op, arg1, arg2)) { return value_x_binop (arg1, arg2, op, OP_NULL, noside); } else { struct type *type = language_bool_type (exp->language_defn, exp->gdbarch); if (noside == EVAL_AVOID_SIDE_EFFECTS) return value_zero (type, VALUE_LVAL (arg1)); else { binop_promote (exp->language_defn, exp->gdbarch, &arg1, &arg2); int tem = value_equal (arg1, arg2); return value_from_longest (type, (LONGEST) tem); } } } Now we don't call value_equal unless we really need to. However, we would need to make the same, or similar change to almost all operations, which would be a big task, and might not be a direction we wanted to take GDB in. So, for now, I'm proposing we go with the more targeted, Fortran specific solution, that does the minimal required in order to correctly resolve the dynamic types. gdb/ChangeLog: * f-exp.h (class fortran_structop_operation): New class. * f-exp.y (exp): Create fortran_structop_operation instead of the generic structop_operation. * f-lang.c (fortran_undetermined::evaluate): Re-evaluate expression as EVAL_NORMAL if the result type was dynamic so we can extract the actual array bounds. (fortran_structop_operation::evaluate): New function. gdb/testsuite/ChangeLog: * gdb.fortran/dynamic-ptype-whatis.exp: New file. * gdb.fortran/dynamic-ptype-whatis.f90: New file.
2021-03-09gdb/fortran: Add 'LOC' intrinsic support.Felix Willgerodt1-0/+19
LOC(X) returns the address of X as an integer: https://gcc.gnu.org/onlinedocs/gfortran/LOC.html Before: (gdb) p LOC(r) No symbol "LOC" in current context. After: (gdb) p LOC(r) $1 = 0xffffdf48 gdb/ChangeLog: 2021-03-09 Felix Willgerodt <felix.willgerodt@intel.com> * f-exp.h (eval_op_f_loc): Declare. (expr::fortran_loc_operation): New typedef. * f-exp.y (exp): Handle UNOP_FORTRAN_LOC after parsing an UNOP_INTRINSIC. (f77_keywords): Add LOC keyword. * f-lang.c (eval_op_f_loc): New function. * std-operator.def (UNOP_FORTRAN_LOC): New operator. gdb/testsuite/ChangeLog: 2020-03-09 Felix Willgerodt <felix.willgerodt@intel.com> * gdb.fortran/intrinsics.exp: Add LOC tests.
2021-03-09gdb/fotran: add support for the 'shape' keywordAndrew Burgess1-0/+81
Add support for the SHAPE keyword to GDB's Fortran expression parser. gdb/ChangeLog: * f-exp.h (eval_op_f_array_shape): Declare. (fortran_array_shape_operation): New type. * f-exp.y (exp): Handle UNOP_FORTRAN_SHAPE after parsing UNOP_INTRINSIC. (f77_keywords): Add "shape" keyword. * f-lang.c (fortran_array_shape): New function. (eval_op_f_array_shape): New function. * std-operator.def (UNOP_FORTRAN_SHAPE): New operator. gdb/testsuite/ChangeLog: * gdb.fortran/shape.exp: New file. * gdb.fortran/shape.f90: New file.
2021-03-09gdb/fortran: add support for 'SIZE' keywordAndrew Burgess1-0/+97
Add support for the 'SIZE' keyword to the Fortran expression parser. This returns the number of elements either in an entire array (passing a single argument to SIZE), or in a particular dimension of an array (passing two arguments to SIZE). At this point I have not added support for the optional third argument to SIZE, which controls the exact integer type of the result. gdb/ChangeLog: * f-exp.y (eval_op_f_array_size): Declare 1 and 2 argument forms of this function. (expr::fortran_array_size_1arg): New type. (expr::fortran_array_size_2arg): Likewise. * f-exp.y (exp): Handle FORTRAN_ARRAY_SIZE after parsing UNOP_OR_BINOP_INTRINSIC. (f77_keywords): Add "size" keyword. * f-lang.c (fortran_array_size): New function. (eval_op_f_array_size): New function, has a 1 arg and 2 arg form. * std-operator.def (FORTRAN_ARRAY_SIZE): New operator. gdb/testsuite/ChangeLog: * gdb.fortran/size.exp: New file. * gdb.fortran/size.f90: New file.
2021-03-09gdb/fortran: add support for RANK keywordAndrew Burgess1-0/+20
gfortran supports the RANK keyword, see: https://gcc.gnu.org/onlinedocs/gfortran/RANK.html#RANK this commit adds support for this keyword to GDB's Fortran expression parser. gdb/ChangeLog: * f-exp.h (eval_op_f_rank): Declare. (expr::fortran_rank_operation): New typedef. * f-exp.y (exp): Handle UNOP_FORTRAN_RANK after parsing an UNOP_INTRINSIC. (f77_keywords): Add "rank" keyword. * f-lang.c (eval_op_f_rank): New function. * std-operator.def (UNOP_FORTRAN_RANK): New operator. gdb/testsuite/ChangeLog: * gdb.fortran/rank.exp: New file. * gdb.fortran/rank.f90: New file.
generated by cgit v1.1 at 2024-11-26 14:59:49 +0000