aboutsummaryrefslogtreecommitdiff
path: root/gdb/f-exp.y
AgeCommit message (Collapse)AuthorFilesLines
2024-07-31[gdb/exp] Fix gdb.fortran/intrinsics.exp fail on armTom de Vries1-11/+28
When running test-case gdb.fortran/intrinsics.exp on arm-linux, I get: ... (gdb) p cmplx (4,4,16)^M /home/linux/gdb/src/gdb/f-lang.c:1002: internal-error: eval_op_f_cmplx: \ Assertion `kind_arg->code () == TYPE_CODE_COMPLEX' failed.^M A problem internal to GDB has been detected,^M further debugging may prove unreliable.^M ----- Backtrace -----^M FAIL: gdb.fortran/intrinsics.exp: p cmplx (4,4,16) (GDB internal error) ... The problem is that 16-byte floats are unsupported: ... $ gfortran test.f90 test.f90:2:17: 2 | REAL(kind=16) :: foo = 1 | 1 Error: Kind 16 not supported for type REAL at (1) ... and consequently we end up with a builtin_real_s16 and builtin_complex_s16 with code TYPE_CODE_ERROR. Fix this by bailing out asap when encountering such a type. Without this patch we're able to do the rather useless: ... (gdb) ptype real*16 type = real*16 (gdb) ptype real_16 type = real*16 ... but with this patch we get: ... (gdb) ptype real*16 unsupported kind 16 for type real*4 (gdb) ptype real_16 unsupported type real*16 ... Tested on arm-linux. PR fortran/30537 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30537
2024-04-21Remove some alloca usesTom Tromey1-7/+2
A few spots (mostly in the parsers) use alloca to ensure that a string is terminated before passing it to a printf-like function (mostly 'error'). However, this isn't needed as the "%.*s" format can be used instead. This patch makes this change. In one spot the alloca is dead code and is simply removed. Regression tested on x86-64 Fedora 38. Approved-By: John Baldwin <jhb@FreeBSD.org>
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-01-28Use domain_search_flags in lookup_symbol et alTom Tromey1-4/+4
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.
2024-01-04gdb: merge error handling from different expression parsersAndrew Burgess1-4/+1
Many (all?) of the expression parsers implement yyerror to handle parser errors, and all of these functions are basically identical. This commit adds a new parser_state::parse_error() function, which implements the common error handling code, this function can then be called from all the different yyerror functions. The benefit of this is that (in a future commit) I can improve the error output, and all the expression parsers will benefit. This commit is pure refactoring though, and so, there should be no user visible changes after this commit. Approved-By: John Baldwin <jhb@FreeBSD.org>
2023-11-29Use C++17 [[fallthrough]] attributeTom Tromey1-2/+2
This changes gdb to use the C++17 [[fallthrough]] attribute rather than special comments. This was mostly done by script, but I neglected a few spellings and so also fixed it up by hand. I suspect this fixes the bug mentioned below, by switching to a standard approach that, presumably, clang supports. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159 Approved-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-08-14[gdb/build] Fix struct token odr violationTom de Vries1-4/+4
When building gdb with -O2 -flto I run into: ... /data/vries/gdb/src/gdb/c-exp.y:2450:8: warning: type 'struct token' \ violates the C++ One Definition Rule [-Wodr] struct token ^ /data/vries/gdb/src/gdb/d-exp.y:939:8: note: a different type is defined in \ another translation unit struct token ^ ... Fix this by renaming to c_token and d_token. Likewise in: - fortran-exp.y, renaming to f_token, - go-exp.y, renaming to go_token, and - p-exp.y, renaming to p_token. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR build/22395 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
2023-08-07gdb/fortran: Align intrinsic/variable precedenceRichard Bunt1-19/+38
Fortran allows variables and function to be named after language defined intrinsics as they are not reserved keywords. For example, the abs maths intrinsic can be hidden by a user declaring a variable called abs. The behavior before this patch was to favour the intrinsic, which meant that any variables named, for example "allocated", could not be inspected by GDB. This patch inverts this priority to bring GDB's behaviour closer to the Fortran language, where the user defined symbol can hide the intrinsic. Special care was need to prevent any C symbols from overriding either Fortran intrinsics or user defined variables. This was observed to be the case when GDB has access to symbols for abs from libm. This was solved by only allowing symbols not marked with language_fortran to be overridden. In total this brings the order of precedence to the following (highest first): 1. User defined Fortran variable or function. 2. Fortran intrinsic. 3. Symbols from languages other than Fortran. The sizeof intrinsic is now case insensitive. This is closer to the Fortran language. I believe this change is safe enough as it increases the acceptance of the grammar, rather than restricts it. I.e. it should not break any existing scripts which rely on it. Unless of course they rely on SIZEOF being rejected. GDB built with GCC 13. No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel LLVM, NVHPC; Platforms: x86_64, aarch64. Existing tests in gdb.fortran cover the invocation of intrinsics including: intrinsics.exp, shape.exp, rank.exp, lbound-ubound.exp. Approved-By: Tom Tromey <tom@tromey.com>
2023-05-23Add PARSER_DEBUG flagTom Tromey1-1/+1
This adds a new PARSER_DEBUG constant and changes the parser code to use it. This lets us make the 'parser_debug' global 'static'.
2023-03-20Remove some unnecessary includes from *-exp.yTom Tromey1-3/+0
I noticed a weird comment in one of the .y files, and then ended up removing some unnecessary #includes from these files. Tested by rebuilding. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-18Use type allocator for array typesTom Tromey1-3/+3
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-3/+4
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-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-1/+1
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-06-04[gdb/fortran] Fix literal truncationTom de Vries1-16/+15
As mentioned in commit 5b758627a18 ("Make gdb.base/parse_number.exp test all architectures"): ... There might be a bug that 32-bit fortran truncates 64-bit values to 32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff". ... More concretely, we have: ... $ for arch in i386:x86-64 i386; do \ gdb -q -batch -ex "set arch $arch" -ex "set lang fortran" \ -ex "p /x 0xffffffffffffffff"; \ done The target architecture is set to "i386:x86-64". $1 = 0xffffffffffffffff The target architecture is set to "i386". $1 = 0xffffffff ... Fix this by adding a range check in parse_number in gdb/f-exp.y. Furthermore, make sure we error out on overflow instead of truncating in all other cases. Tested on x86_64-linux.
2022-04-28Remove "typedef enum ..."Tom Tromey1-1/+1
I noticed a few spots in GDB that use "typedef enum". However, in C++ this isn't as useful, as the tag is automatically entered as a typedef. This patch removes most uses of "typedef enum" -- the exceptions being in some nat-* code I can't compile, and glibc_thread_db.h, which I think is more or less a copy of some C code from elsewhere. Tested by rebuilding.
2022-04-11gdb/fortran: rewrite intrinsic handling and add some missing overloadsNils-Christian Kempke1-86/+229
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: rename f77_keywords to f_keywordsNils-Christian Kempke1-2/+2
Rename f77_keywords to f_keywords since some of the introduced keywords in the array are f90 only.
2022-04-11gdb/fortran: clean-up Fortran intrinsic typesNils-Christian Kempke1-17/+33
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: fix complex type in Fortran builtin typesNils-Christian Kempke1-13/+13
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: add Integer*1 to Fortran builtin typesNils-Christian Kempke1-1/+3
Add builtin_integer_s1 of size TARGET_CHAR_BIT to Fortran builtin types.
2022-04-08Fix undefined behavior in the Fortran, Go and Pascal number parsersPedro Alves1-4/+4
This commit ports these two fixes to the C parser: commit ebf13736b42af47c9907b5157c8e80c78dbe00e1 CommitDate: Thu Sep 4 21:46:28 2014 +0100 parse_number("0") reads uninitialized memory commit 20562150d8a894bc91657c843ee88c508188e32e CommitDate: Wed Oct 3 15:19:06 2018 -0600 Avoid undefined behavior in parse_number ... to the Fortran, Go, and Fortran number parsers, fixing the same problems there. Also add a new testcase that exercises printing 0xffffffffffffffff (max 64-bit) in all languages, which crashes a GDB built with UBsan without the fix. I moved get_set_option_choices out of all-architectures.exp.tcl to common code to be able to extract all the supported languages. I did a tweak to it to generalize it a bit -- you now have to pass down the "set" part of the command as well. This is so that the proc can be used with "maintenance set" commands as well in future. Change-Id: I8e8f2fdc1e8407f63d923c26fd55d98148b9e16a
2022-04-08gdb/fortran: add support for accessing fields of extended typesBernhard Heckel1-2/+5
Fortran 2003 supports type extension. This patch allows access to inherited members by using their fully qualified name as described in the Fortran standard. In doing so the patch also fixes a bug in GDB when trying to access the members of a base class in a derived class via the derived class' base class member. This patch fixes PR22497 and PR26373 on GDB side. Using the example Fortran program from PR22497 program mvce implicit none type :: my_type integer :: my_int end type my_type type, extends(my_type) :: extended_type end type extended_type type(my_type) :: foo type(extended_type) :: bar foo%my_int = 0 bar%my_int = 1 print*, foo, bar end program mvce and running this with GDB and setting a BP at 17: Before: (gdb) p bar%my_type A syntax error in expression, near `my_type'. (gdb) p bar%my_int There is no member named my_int. (gdb) p bar%my_type%my_int A syntax error in expression, near `my_type%my_int'. (gdb) p bar $1 = ( my_type = ( my_int = 1 ) ) After: (gdb) p bar%my_type $1 = ( my_int = 1 ) (gdb) p bar%my_int $2 = 1 # this line requires DW_TAG_inheritance to work (gdb) p bar%my_type%my_int $3 = 1 (gdb) p bar $4 = ( my_type = ( my_int = 1 ) ) In the above example "p bar%my_int" requires the compiler to emit information about the inheritance relationship between extended_type and my_type which gfortran and flang currently do not de. The respective issue gcc/49475 has been put as kfail. Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26373 https://sourceware.org/bugzilla/show_bug.cgi?id=22497
2022-02-06gdb: remove SYMBOL_TYPE macroSimon Marchi1-1/+1
Add a getter and a setter for a symbol's type. Remove the corresponding macro and adjust all callers. Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
2022-02-06gdb: remove SYMBOL_CLASS macro, add getterSimon Marchi1-1/+1
Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
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-08Use for-each more in gdbTom Tromey1-23/+23
There are some loops in gdb that use ARRAY_SIZE (or a wordier equivalent) to loop over a static array. This patch changes some of these to use foreach instead. Regression tested on x86-64 Fedora 34.
2021-04-07gdb/fortran: handle dynamic types within arrays and structuresAndrew Burgess1-4/+5
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/+4
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/+4
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/+8
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/+4
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.
2021-03-08Remove BINOP_ENDTom Tromey1-37/+37
BINOP_END is used only as a "meaningless" value in various tables. This patch changes these to use OP_NULL instead, and removes BINOP_END. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * std-operator.def (BINOP_END): Remove. * p-exp.y (tokentab3, tokentab2): Use OP_NULL, not BINOP_END. * go-exp.y (tokentab2): Use OP_NULL, not BINOP_END. * f-exp.y (dot_ops, f77_keywords): Use OP_NULL, not BINOP_END. * d-exp.y (tokentab2, ident_tokens): Use OP_NULL, not BINOP_END. * c-exp.y (tokentab3, tokentab2, ident_tokens): Use OP_NULL, not BINOP_END.
2021-03-08Convert f-exp.y to use operationsTom Tromey1-132/+225
This converts the Fortran parser to generate operations rather than exp_elements. A couple of tests of expression debug dumping are updated to follow the new output. gdb/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * f-exp.y: Create operations. (f_language::parser): Update. gdb/testsuite/ChangeLog 2021-03-08 Tom Tromey <tom@tromey.com> * gdb.fortran/debug-expr.exp: Update tests.
2021-02-25gdb/fortran: add support for ASSOCIATED builtinAndrew Burgess1-0/+1
This commit adds support for the ASSOCIATED builtin to the Fortran expression evaluator. The ASSOCIATED builtin takes one or two arguments. When passed a single pointer argument GDB returns a boolean indicating if the pointer is associated with anything. When passed two arguments the second argument should either be some a pointer could point at or a second pointer. If the second argument is a pointer target, then the result from associated indicates if the pointer is pointing at this target. If the second argument is another pointer, then the result from associated indicates if the two pointers are pointing at the same thing. gdb/ChangeLog: * f-exp.y (f77_keywords): Add 'associated'. * f-lang.c (fortran_associated): New function. (evaluate_subexp_f): Handle FORTRAN_ASSOCIATED. (operator_length_f): Likewise. (print_unop_or_binop_subexp_f): New function. (print_subexp_f): Make use of print_unop_or_binop_subexp_f for FORTRAN_ASSOCIATED, FORTRAN_LBOUND, and FORTRAN_UBOUND. (dump_subexp_body_f): Handle FORTRAN_ASSOCIATED. (operator_check_f): Likewise. * std-operator.def: Add FORTRAN_ASSOCIATED. gdb/testsuite/ChangeLog: * gdb.fortran/associated.exp: New file. * gdb.fortran/associated.f90: New file.
2021-02-25gdb/fortran: add support for legacy .xor. operatorAndrew Burgess1-0/+1
gfortran supports .xor. as an alias for .neqv., see: https://gcc.gnu.org/onlinedocs/gfortran/_002eXOR_002e-operator.html this commit adds support for this operator to GDB. gdb/ChangeLog: * f-exp.y (fortran_operators): Add ".xor.". gdb/testsuite/ChangeLog: * gdb.fortran/dot-ops.exp (dot_operations): Test ".xor.".
2021-02-12gdb/fortran: support ALLOCATED builtinAndrew Burgess1-0/+1
Add support for the ALLOCATED keyword to the Fortran expression parser. gdb/ChangeLog: * f-exp.y (f77_keywords): Add allocated. * f-lang.c (evaluate_subexp_f): Handle UNOP_FORTRAN_ALLOCATED. (operator_length_f): Likewise. (print_subexp_f): Likewise. (dump_subexp_body_f): Likewise. (operator_check_f): Likewise. * std-operator.def (UNOP_FORTRAN_ALLOCATED): New operator. gdb/testsuite/ChangeLog: * gdb.fortran/allocated.exp: New file. * gdb.fortran/allocated.f90: New file.
2021-02-10gdb/fortran: add parser support for lbound and uboundAndrew Burgess1-0/+18
Add support for the LBOUND and UBOUND built in functions to the Fortran expression parser. Both support taking one or two arguments. A single argument, which must be an array, returns an array containing all of the lower or upper bound data. When passed two arguments, the second argument is the dimension being asked about. In this case the result is a scalar containing the lower or upper bound just for that dimension. Some examples of usage taken from the new test: # Given: # integer, dimension (-8:-1,-10:-2) :: neg_array # (gdb) p lbound (neg_array) $1 = (-8, -10) (gdb) p lbound (neg_array, 1) $3 = -8 (gdb) p lbound (neg_array, 2) $5 = -10 gdb/ChangeLog: * f-exp.y (UNOP_OR_BINOP_INTRINSIC): New token. (exp): New pattern using UNOP_OR_BINOP_INTRINSIC. (one_or_two_args): New pattern. (f77_keywords): Add lbound and ubound. * f-lang.c (fortran_bounds_all_dims): New function. (fortran_bounds_for_dimension): New function. (evaluate_subexp_f): Handle FORTRAN_LBOUND and FORTRAN_UBOUND. (operator_length_f): Likewise. (print_subexp_f): Likewise. (dump_subexp_body_f): Likewise. (operator_check_f): Likewise. * std-operator.def (FORTRAN_LBOUND): Define. (FORTRAN_UBOUND): Define. gdb/testsuite/ChangeLog: * gdb.fortran/lbound-ubound.F90: New file. * gdb.fortran/lbound-ubound.exp: New file.
2021-02-05Extract symbol-writing function from parsersTom Tromey1-26/+3
I noticed that several parsers shared the same code to write a symbol reference to an expression. This patch factors this code out into a new function. Regression tested on x86-64 Fedora 32. gdb/ChangeLog 2021-02-05 Tom Tromey <tom@tromey.com> * parser-defs.h (write_exp_symbol_reference): Declare. * parse.c (write_exp_symbol_reference): New function. * p-exp.y (variable): Use write_exp_symbol_reference. * m2-exp.y (variable): Use write_exp_symbol_reference. * f-exp.y (variable): Use write_exp_symbol_reference. * d-exp.y (PrimaryExpression): Use write_exp_symbol_reference. * c-exp.y (variable): Use write_exp_symbol_reference.
2021-01-12gdb/fortran: add symbol base comparison operatorsAndrew Burgess1-18/+18
Fortran supports symbol based comparison operators as well as the classic text based comparison operators, so we have: Text | Symbol Operator | Operator ---------|--------- .eq. | == .ne. | /= .le. | <= .ge. | >= .gt. | > .lt. | < This commit adds the symbol based operators as well as some tests. gdb/ChangeLog: * f-exp.y (dot_ops): Rename to... (fortran_operators): ...this. Add a header comment. Add symbol based operators. (yylex): Update to use fortran_operators not dot_ops. Remove special handling for '**', this is now included in fortran_operators. gdb/testsuite/ChangeLog: * gdb.fortran/dot-ops.exp: Add new tests.
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-12-11Avoid side effects in expression lexersTom Tromey1-6/+4
I noticed that some of the lexers were calling write_dollar_variable from the lexer. This seems like a bad practice, so this patch moves the side effects into the parsers. I tested this by re-running gdb.fortran and gdb.modula2; the Pascal compiler on my machine seems not to work, so I couldn't test gdb.pascal. I note that the type-tracking in the Pascal is also incorrect, in that a convenience variable's type may change between parsing and evaluation (or even during the course of evaluation). gdb/ChangeLog 2020-12-11 Tom Tromey <tom@tromey.com> * p-exp.y (intvar): Remove global. (DOLLAR_VARIABLE): Change type. (start): Update. (exp): Call write_dollar_variable here... (yylex): ... not here. * m2-exp.y (DOLLAR_VARIABLE): Change type. (variable): Call write_dollar_variable here... (yylex): ... not here. * f-exp.y (DOLLAR_VARIABLE): Change type. (exp): Call write_dollar_variable here... (yylex): ... not here.
2020-11-14gdb: add tab completion of type field names for FortranAndrew Burgess1-4/+47
Add support for tab-completion on Fortran field names. Consider this test case: program test type my_type integer :: field_a integer :: other_field integer :: last_field end type my_type type(my_type) :: var print *, var end program test And the GDB session before this patch: (gdb) start ... (gdb) p var% <- Trigger TAB completion here. Display all 200 possibilities? (y or n) n (gdb) p var% And the GDB session with this patch: (gdb) start ... (gdb) p var% <- Trigger TAB completion here. field_a last_field other_field (gdb) p var% The implementation for this is basically copied from c-exp.y, I tweaked the parser patterns to be appropriate for Fortran, and it "just worked". gdb/ChangeLog: PR cli/26879 * f-exp.y (COMPLETE): New token. (exp): Two new rules for tab-completion. (saw_name_at_eof): New static global. (last_was_structop): Likewise. (yylex): Set new variables, and return COMPLETE token at the end of the input stream in some cases. gdb/testsuite/ChangeLog: PR cli/26879 * gdb.fortran/completion.exp: New file. * gdb.fortran/completion.f90: New file.
2020-11-02gdb, gdbserver, gdbsupport: fix leading space vs tabs issuesSimon Marchi1-13/+13
Many spots incorrectly use only spaces for indentation (for example, there are a lot of spots in ada-lang.c). I've always found it awkward when I needed to edit one of these spots: do I keep the original wrong indentation, or do I fix it? What if the lines around it are also wrong, do I fix them too? I probably don't want to fix them in the same patch, to avoid adding noise to my patch. So I propose to fix as much as possible once and for all (hopefully). One typical counter argument for this is that it makes code archeology more difficult, because git-blame will show this commit as the last change for these lines. My counter counter argument is: when git-blaming, you often need to do "blame the file at the parent commit" anyway, to go past some other refactor that touched the line you are interested in, but is not the change you are looking for. So you already need a somewhat efficient way to do this. Using some interactive tool, rather than plain git-blame, makes this trivial. For example, I use "tig blame <file>", where going back past the commit that changed the currently selected line is one keystroke. It looks like Magit in Emacs does it too (though I've never used it). Web viewers of Github and Gitlab do it too. My point is that it won't really make archeology more difficult. The other typical counter argument is that it will cause conflicts with existing patches. That's true... but it's a one time cost, and those are not conflicts that are difficult to resolve. I have also tried "git rebase --ignore-whitespace", it seems to work well. Although that will re-introduce the faulty indentation, so one needs to take care of fixing the indentation in the patch after that (which is easy). gdb/ChangeLog: * aarch64-linux-tdep.c: Fix indentation. * aarch64-ravenscar-thread.c: Fix indentation. * aarch64-tdep.c: Fix indentation. * aarch64-tdep.h: Fix indentation. * ada-lang.c: Fix indentation. * ada-lang.h: Fix indentation. * ada-tasks.c: Fix indentation. * ada-typeprint.c: Fix indentation. * ada-valprint.c: Fix indentation. * ada-varobj.c: Fix indentation. * addrmap.c: Fix indentation. * addrmap.h: Fix indentation. * agent.c: Fix indentation. * aix-thread.c: Fix indentation. * alpha-bsd-nat.c: Fix indentation. * alpha-linux-tdep.c: Fix indentation. * alpha-mdebug-tdep.c: Fix indentation. * alpha-nbsd-tdep.c: Fix indentation. * alpha-obsd-tdep.c: Fix indentation. * alpha-tdep.c: Fix indentation. * amd64-bsd-nat.c: Fix indentation. * amd64-darwin-tdep.c: Fix indentation. * amd64-linux-nat.c: Fix indentation. * amd64-linux-tdep.c: Fix indentation. * amd64-nat.c: Fix indentation. * amd64-obsd-tdep.c: Fix indentation. * amd64-tdep.c: Fix indentation. * amd64-windows-tdep.c: Fix indentation. * annotate.c: Fix indentation. * arc-tdep.c: Fix indentation. * arch-utils.c: Fix indentation. * arch/arm-get-next-pcs.c: Fix indentation. * arch/arm.c: Fix indentation. * arm-linux-nat.c: Fix indentation. * arm-linux-tdep.c: Fix indentation. * arm-nbsd-tdep.c: Fix indentation. * arm-pikeos-tdep.c: Fix indentation. * arm-tdep.c: Fix indentation. * arm-tdep.h: Fix indentation. * arm-wince-tdep.c: Fix indentation. * auto-load.c: Fix indentation. * auxv.c: Fix indentation. * avr-tdep.c: Fix indentation. * ax-gdb.c: Fix indentation. * ax-general.c: Fix indentation. * bfin-linux-tdep.c: Fix indentation. * block.c: Fix indentation. * block.h: Fix indentation. * blockframe.c: Fix indentation. * bpf-tdep.c: Fix indentation. * break-catch-sig.c: Fix indentation. * break-catch-syscall.c: Fix indentation. * break-catch-throw.c: Fix indentation. * breakpoint.c: Fix indentation. * breakpoint.h: Fix indentation. * bsd-uthread.c: Fix indentation. * btrace.c: Fix indentation. * build-id.c: Fix indentation. * buildsym-legacy.h: Fix indentation. * buildsym.c: Fix indentation. * c-typeprint.c: Fix indentation. * c-valprint.c: Fix indentation. * c-varobj.c: Fix indentation. * charset.c: Fix indentation. * cli/cli-cmds.c: Fix indentation. * cli/cli-decode.c: Fix indentation. * cli/cli-decode.h: Fix indentation. * cli/cli-script.c: Fix indentation. * cli/cli-setshow.c: Fix indentation. * coff-pe-read.c: Fix indentation. * coffread.c: Fix indentation. * compile/compile-cplus-types.c: Fix indentation. * compile/compile-object-load.c: Fix indentation. * compile/compile-object-run.c: Fix indentation. * completer.c: Fix indentation. * corefile.c: Fix indentation. * corelow.c: Fix indentation. * cp-abi.h: Fix indentation. * cp-namespace.c: Fix indentation. * cp-support.c: Fix indentation. * cp-valprint.c: Fix indentation. * cris-linux-tdep.c: Fix indentation. * cris-tdep.c: Fix indentation. * darwin-nat-info.c: Fix indentation. * darwin-nat.c: Fix indentation. * darwin-nat.h: Fix indentation. * dbxread.c: Fix indentation. * dcache.c: Fix indentation. * disasm.c: Fix indentation. * dtrace-probe.c: Fix indentation. * dwarf2/abbrev.c: Fix indentation. * dwarf2/attribute.c: Fix indentation. * dwarf2/expr.c: Fix indentation. * dwarf2/frame.c: Fix indentation. * dwarf2/index-cache.c: Fix indentation. * dwarf2/index-write.c: Fix indentation. * dwarf2/line-header.c: Fix indentation. * dwarf2/loc.c: Fix indentation. * dwarf2/macro.c: Fix indentation. * dwarf2/read.c: Fix indentation. * dwarf2/read.h: Fix indentation. * elfread.c: Fix indentation. * eval.c: Fix indentation. * event-top.c: Fix indentation. * exec.c: Fix indentation. * exec.h: Fix indentation. * expprint.c: Fix indentation. * f-lang.c: Fix indentation. * f-typeprint.c: Fix indentation. * f-valprint.c: Fix indentation. * fbsd-nat.c: Fix indentation. * fbsd-tdep.c: Fix indentation. * findvar.c: Fix indentation. * fork-child.c: Fix indentation. * frame-unwind.c: Fix indentation. * frame-unwind.h: Fix indentation. * frame.c: Fix indentation. * frv-linux-tdep.c: Fix indentation. * frv-tdep.c: Fix indentation. * frv-tdep.h: Fix indentation. * ft32-tdep.c: Fix indentation. * gcore.c: Fix indentation. * gdb_bfd.c: Fix indentation. * gdbarch.sh: Fix indentation. * gdbarch.c: Re-generate * gdbarch.h: Re-generate. * gdbcore.h: Fix indentation. * gdbthread.h: Fix indentation. * gdbtypes.c: Fix indentation. * gdbtypes.h: Fix indentation. * glibc-tdep.c: Fix indentation. * gnu-nat.c: Fix indentation. * gnu-nat.h: Fix indentation. * gnu-v2-abi.c: Fix indentation. * gnu-v3-abi.c: Fix indentation. * go32-nat.c: Fix indentation. * guile/guile-internal.h: Fix indentation. * guile/scm-cmd.c: Fix indentation. * guile/scm-frame.c: Fix indentation. * guile/scm-iterator.c: Fix indentation. * guile/scm-math.c: Fix indentation. * guile/scm-ports.c: Fix indentation. * guile/scm-pretty-print.c: Fix indentation. * guile/scm-value.c: Fix indentation. * h8300-tdep.c: Fix indentation. * hppa-linux-nat.c: Fix indentation. * hppa-linux-tdep.c: Fix indentation. * hppa-nbsd-nat.c: Fix indentation. * hppa-nbsd-tdep.c: Fix indentation. * hppa-obsd-nat.c: Fix indentation. * hppa-tdep.c: Fix indentation. * hppa-tdep.h: Fix indentation. * i386-bsd-nat.c: Fix indentation. * i386-darwin-nat.c: Fix indentation. * i386-darwin-tdep.c: Fix indentation. * i386-dicos-tdep.c: Fix indentation. * i386-gnu-nat.c: Fix indentation. * i386-linux-nat.c: Fix indentation. * i386-linux-tdep.c: Fix indentation. * i386-nto-tdep.c: Fix indentation. * i386-obsd-tdep.c: Fix indentation. * i386-sol2-nat.c: Fix indentation. * i386-tdep.c: Fix indentation. * i386-tdep.h: Fix indentation. * i386-windows-tdep.c: Fix indentation. * i387-tdep.c: Fix indentation. * i387-tdep.h: Fix indentation. * ia64-libunwind-tdep.c: Fix indentation. * ia64-libunwind-tdep.h: Fix indentation. * ia64-linux-nat.c: Fix indentation. * ia64-linux-tdep.c: Fix indentation. * ia64-tdep.c: Fix indentation. * ia64-tdep.h: Fix indentation. * ia64-vms-tdep.c: Fix indentation. * infcall.c: Fix indentation. * infcmd.c: Fix indentation. * inferior.c: Fix indentation. * infrun.c: Fix indentation. * iq2000-tdep.c: Fix indentation. * language.c: Fix indentation. * linespec.c: Fix indentation. * linux-fork.c: Fix indentation. * linux-nat.c: Fix indentation. * linux-tdep.c: Fix indentation. * linux-thread-db.c: Fix indentation. * lm32-tdep.c: Fix indentation. * m2-lang.c: Fix indentation. * m2-typeprint.c: Fix indentation. * m2-valprint.c: Fix indentation. * m32c-tdep.c: Fix indentation. * m32r-linux-tdep.c: Fix indentation. * m32r-tdep.c: Fix indentation. * m68hc11-tdep.c: Fix indentation. * m68k-bsd-nat.c: Fix indentation. * m68k-linux-nat.c: Fix indentation. * m68k-linux-tdep.c: Fix indentation. * m68k-tdep.c: Fix indentation. * machoread.c: Fix indentation. * macrocmd.c: Fix indentation. * macroexp.c: Fix indentation. * macroscope.c: Fix indentation. * macrotab.c: Fix indentation. * macrotab.h: Fix indentation. * main.c: Fix indentation. * mdebugread.c: Fix indentation. * mep-tdep.c: Fix indentation. * mi/mi-cmd-catch.c: Fix indentation. * mi/mi-cmd-disas.c: Fix indentation. * mi/mi-cmd-env.c: Fix indentation. * mi/mi-cmd-stack.c: Fix indentation. * mi/mi-cmd-var.c: Fix indentation. * mi/mi-cmds.c: Fix indentation. * mi/mi-main.c: Fix indentation. * mi/mi-parse.c: Fix indentation. * microblaze-tdep.c: Fix indentation. * minidebug.c: Fix indentation. * minsyms.c: Fix indentation. * mips-linux-nat.c: Fix indentation. * mips-linux-tdep.c: Fix indentation. * mips-nbsd-tdep.c: Fix indentation. * mips-tdep.c: Fix indentation. * mn10300-linux-tdep.c: Fix indentation. * mn10300-tdep.c: Fix indentation. * moxie-tdep.c: Fix indentation. * msp430-tdep.c: Fix indentation. * namespace.h: Fix indentation. * nat/fork-inferior.c: Fix indentation. * nat/gdb_ptrace.h: Fix indentation. * nat/linux-namespaces.c: Fix indentation. * nat/linux-osdata.c: Fix indentation. * nat/netbsd-nat.c: Fix indentation. * nat/x86-dregs.c: Fix indentation. * nbsd-nat.c: Fix indentation. * nbsd-tdep.c: Fix indentation. * nios2-linux-tdep.c: Fix indentation. * nios2-tdep.c: Fix indentation. * nto-procfs.c: Fix indentation. * nto-tdep.c: Fix indentation. * objfiles.c: Fix indentation. * objfiles.h: Fix indentation. * opencl-lang.c: Fix indentation. * or1k-tdep.c: Fix indentation. * osabi.c: Fix indentation. * osabi.h: Fix indentation. * osdata.c: Fix indentation. * p-lang.c: Fix indentation. * p-typeprint.c: Fix indentation. * p-valprint.c: Fix indentation. * parse.c: Fix indentation. * ppc-linux-nat.c: Fix indentation. * ppc-linux-tdep.c: Fix indentation. * ppc-nbsd-nat.c: Fix indentation. * ppc-nbsd-tdep.c: Fix indentation. * ppc-obsd-nat.c: Fix indentation. * ppc-ravenscar-thread.c: Fix indentation. * ppc-sysv-tdep.c: Fix indentation. * ppc64-tdep.c: Fix indentation. * printcmd.c: Fix indentation. * proc-api.c: Fix indentation. * producer.c: Fix indentation. * producer.h: Fix indentation. * prologue-value.c: Fix indentation. * prologue-value.h: Fix indentation. * psymtab.c: Fix indentation. * python/py-arch.c: Fix indentation. * python/py-bpevent.c: Fix indentation. * python/py-event.c: Fix indentation. * python/py-event.h: Fix indentation. * python/py-finishbreakpoint.c: Fix indentation. * python/py-frame.c: Fix indentation. * python/py-framefilter.c: Fix indentation. * python/py-inferior.c: Fix indentation. * python/py-infthread.c: Fix indentation. * python/py-objfile.c: Fix indentation. * python/py-prettyprint.c: Fix indentation. * python/py-registers.c: Fix indentation. * python/py-signalevent.c: Fix indentation. * python/py-stopevent.c: Fix indentation. * python/py-stopevent.h: Fix indentation. * python/py-threadevent.c: Fix indentation. * python/py-tui.c: Fix indentation. * python/py-unwind.c: Fix indentation. * python/py-value.c: Fix indentation. * python/py-xmethods.c: Fix indentation. * python/python-internal.h: Fix indentation. * python/python.c: Fix indentation. * ravenscar-thread.c: Fix indentation. * record-btrace.c: Fix indentation. * record-full.c: Fix indentation. * record.c: Fix indentation. * reggroups.c: Fix indentation. * regset.h: Fix indentation. * remote-fileio.c: Fix indentation. * remote.c: Fix indentation. * reverse.c: Fix indentation. * riscv-linux-tdep.c: Fix indentation. * riscv-ravenscar-thread.c: Fix indentation. * riscv-tdep.c: Fix indentation. * rl78-tdep.c: Fix indentation. * rs6000-aix-tdep.c: Fix indentation. * rs6000-lynx178-tdep.c: Fix indentation. * rs6000-nat.c: Fix indentation. * rs6000-tdep.c: Fix indentation. * rust-lang.c: Fix indentation. * rx-tdep.c: Fix indentation. * s12z-tdep.c: Fix indentation. * s390-linux-tdep.c: Fix indentation. * score-tdep.c: Fix indentation. * ser-base.c: Fix indentation. * ser-mingw.c: Fix indentation. * ser-uds.c: Fix indentation. * ser-unix.c: Fix indentation. * serial.c: Fix indentation. * sh-linux-tdep.c: Fix indentation. * sh-nbsd-tdep.c: Fix indentation. * sh-tdep.c: Fix indentation. * skip.c: Fix indentation. * sol-thread.c: Fix indentation. * solib-aix.c: Fix indentation. * solib-darwin.c: Fix indentation. * solib-frv.c: Fix indentation. * solib-svr4.c: Fix indentation. * solib.c: Fix indentation. * source.c: Fix indentation. * sparc-linux-tdep.c: Fix indentation. * sparc-nbsd-tdep.c: Fix indentation. * sparc-obsd-tdep.c: Fix indentation. * sparc-ravenscar-thread.c: Fix indentation. * sparc-tdep.c: Fix indentation. * sparc64-linux-tdep.c: Fix indentation. * sparc64-nbsd-tdep.c: Fix indentation. * sparc64-obsd-tdep.c: Fix indentation. * sparc64-tdep.c: Fix indentation. * stabsread.c: Fix indentation. * stack.c: Fix indentation. * stap-probe.c: Fix indentation. * stubs/ia64vms-stub.c: Fix indentation. * stubs/m32r-stub.c: Fix indentation. * stubs/m68k-stub.c: Fix indentation. * stubs/sh-stub.c: Fix indentation. * stubs/sparc-stub.c: Fix indentation. * symfile-mem.c: Fix indentation. * symfile.c: Fix indentation. * symfile.h: Fix indentation. * symmisc.c: Fix indentation. * symtab.c: Fix indentation. * symtab.h: Fix indentation. * target-float.c: Fix indentation. * target.c: Fix indentation. * target.h: Fix indentation. * tic6x-tdep.c: Fix indentation. * tilegx-linux-tdep.c: Fix indentation. * tilegx-tdep.c: Fix indentation. * top.c: Fix indentation. * tracefile-tfile.c: Fix indentation. * tracepoint.c: Fix indentation. * tui/tui-disasm.c: Fix indentation. * tui/tui-io.c: Fix indentation. * tui/tui-regs.c: Fix indentation. * tui/tui-stack.c: Fix indentation. * tui/tui-win.c: Fix indentation. * tui/tui-winsource.c: Fix indentation. * tui/tui.c: Fix indentation. * typeprint.c: Fix indentation. * ui-out.h: Fix indentation. * unittests/copy_bitwise-selftests.c: Fix indentation. * unittests/memory-map-selftests.c: Fix indentation. * utils.c: Fix indentation. * v850-tdep.c: Fix indentation. * valarith.c: Fix indentation. * valops.c: Fix indentation. * valprint.c: Fix indentation. * valprint.h: Fix indentation. * value.c: Fix indentation. * value.h: Fix indentation. * varobj.c: Fix indentation. * vax-tdep.c: Fix indentation. * windows-nat.c: Fix indentation. * windows-tdep.c: Fix indentation. * xcoffread.c: Fix indentation. * xml-syscall.c: Fix indentation. * xml-tdesc.c: Fix indentation. * xstormy16-tdep.c: Fix indentation. * xtensa-config.c: Fix indentation. * xtensa-linux-nat.c: Fix indentation. * xtensa-linux-tdep.c: Fix indentation. * xtensa-tdep.c: Fix indentation. gdbserver/ChangeLog: * ax.cc: Fix indentation. * dll.cc: Fix indentation. * inferiors.h: Fix indentation. * linux-low.cc: Fix indentation. * linux-nios2-low.cc: Fix indentation. * linux-ppc-ipa.cc: Fix indentation. * linux-ppc-low.cc: Fix indentation. * linux-x86-low.cc: Fix indentation. * linux-xtensa-low.cc: Fix indentation. * regcache.cc: Fix indentation. * server.cc: Fix indentation. * tracepoint.cc: Fix indentation. gdbsupport/ChangeLog: * common-exceptions.h: Fix indentation. * event-loop.cc: Fix indentation. * fileio.cc: Fix indentation. * filestuff.cc: Fix indentation. * gdb-dlfcn.cc: Fix indentation. * gdb_string_view.h: Fix indentation. * job-control.cc: Fix indentation. * signals.cc: Fix indentation. Change-Id: I4bad7ae6be0fbe14168b8ebafb98ffe14964a695
2020-10-23gdb: move f_language class into a header fileAndrew Burgess1-1/+1
Moves the f_language class from f-lang.c into f-lang.h. The benefit of this is that functions declared in other f-*.c files can become member functions without having to go through a level of indirection. Some additional support functions have now become private member functions of the f_language class, these are mostly functions that then called some other function that was itself a member of the language_defn class hierarchy. There should be no user visible changes after this commit. gdb/ChangeLog: * f-exp.y (f_parse): Rename to... (f_language::parser): ...this. * f-lang.c (f_get_encoding): Rename to... (f_language::get_encoding): ...this. (f_op_print_tab): Rename to... (f_language::op_print_tab): ...this. (exp_descriptor_f): Rename to... (f_language::exp_descriptor_tab): ...this. (class f_language): Moved to f-lang.h. (f_language::language_arch_info): New function, moved out of class declaration. (f_language::search_name_hash): Likewise. (f_language::lookup_symbol_nonlocal): Likewise. (f_language::get_symbol_name_matcher_inner): Likewise. * f-lang.h: Add 'valprint.h' include. (class f_language): Moved here from f-lang.c. * f-typeprint.c (f_type_print_args): Delete commented out declaration. (f_print_typedef): Rename to... (f_language::print_typedef): ...this. (f_print_type): Rename to... (f_language::print_type): ...this. (f_type_print_varspec_prefix): Delete declaration and rename to... (f_language::f_type_print_varspec_prefix): ...this. (f_type_print_varspec_suffix): Delete declaration and rename to... (f_language::f_type_print_varspec_suffix): ...this. (f_type_print_base): Delete declaration and rename to... (f_language::f_type_print_base): ...this. * f-valprint.c (f_value_print_inner): Rename to... (f_language::value_print_inner): ...this. * parse.c: Delete 'f-lang.h' include.
2020-10-22gdb/fortran: add support for parsing array strides in expressionsAndrew Burgess1-0/+36
With this commit GDB now understands the syntax of Fortran array strides, a user can type an expression including an array stride, but they will only get an error informing them that array strides are not supported. This alone is an improvement on what we had before in GDB, better to give the user a helpful message that a particular feature is not supported than to just claim a syntax error. Before: (gdb) p array (1:10:2, 2:10:2) A syntax error in expression, near `:2, 2:10:2)'. Now: (gdb) p array (1:10:2, 2:10:2) Fortran array strides are not currently supported Later commits will allow GDB to handle array strides correctly. gdb/ChangeLog: * expprint.c (dump_subexp_body_standard): Print RANGE_HAS_STRIDE. * expression.h (enum range_type): Add RANGE_HAS_STRIDE. * f-exp.y (arglist): Allow for a series of subranges. (subrange): Add cases for subranges with strides. * f-lang.c (value_f90_subarray): Catch use of array strides and throw an error. * parse.c (operator_length_standard): Handle RANGE_HAS_STRIDE. gdb/testsuite/ChangeLog: * gdb.fortran/array-slices.exp: Add a new test.
2020-10-22gdb: Convert enum range_type to a bit field enumAndrew Burgess1-5/+9
The expression range_type enum represents the following ideas: - Lower bound is set to default, - Upper bound is set to default, - Upper bound is exclusive. There are currently 6 entries in the enum to represent the combination of all those ideas. In a future commit I'd like to add stride information to the range, this could in theory appear with any of the existing enum entries, so this would take us to 12 enum entries. This feels like its getting a little out of hand, so in this commit I switch the range_type enum over to being a flags style enum. There's one entry to represent no flags being set, then 3 flags to represent the 3 ideas above. Adding stride information will require adding only one more enum flag. I've then gone through and updated the code to handle this change. There should be no user visible changes after this commit. gdb/ChangeLog: * expprint.c (print_subexp_standard): Update to reflect changes to enum range_type. (dump_subexp_body_standard): Likewise. * expression.h (enum range_type): Convert to a bit field enum, and make the enum unsigned. * f-exp.y (subrange): Update to reflect changes to enum range_type. * f-lang.c (value_f90_subarray): Likewise. * parse.c (operator_length_standard): Likewise. * rust-exp.y (rust_parser::convert_ast_to_expression): Likewise. * rust-lang.c (rust_range): Likewise. (rust_compute_range): Likewise. (rust_subscript): Likewise.
2020-09-14gdb: remove TYPE_UNSIGNEDSimon Marchi1-1/+1
gdb/ChangeLog: * gdbtypes.h (TYPE_UNSIGNED): Remove, replace all uses with type::is_unsigned. Change-Id: I84f76f5cd44ff7294e421d317376a9e476bc8666
2020-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files.