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>
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.
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.
I've been running the test-suite on an i686-linux laptop with 1GB of memory,
and 1 GB of swap, and noticed problems after running gdb.base/huge.exp: gdb
not being able to spawn for a large number of test-cases afterwards.
So I investigated the memory usage, on my usual x86_64-linux development
platform.
The test-case is compiled with -DCRASH_GDB=2097152, so this:
...
static int a[CRASH_GDB], b[CRASH_GDB];
...
with sizeof (int) == 4 represents two arrays of 8MB each.
Say we add a loop around the "print a" command and print space usage
statistics:
...
gdb_test "maint set per-command space on"
for {set i 0} {$i < 100} {incr i} {
gdb_test "print a"
}
...
This gets us:
...
(gdb) print a^M
$1 = {0 <repeats 2097152 times>}^M
Space used: 478248960 (+469356544 for this command)^M
(gdb) print a^M
$2 = {0 <repeats 2097152 times>}^M
Space used: 486629376 (+8380416 for this command)^M
(gdb) print a^M
$3 = {0 <repeats 2097152 times>}^M
Space used: 495009792 (+8380416 for this command)^M
...
(gdb) print a^M
$100 = {0 <repeats 2097152 times>}^M
Space used: 1308721152 (+8380416 for this command)^M
...
In other words, we start out at 8MB, and the first print costs us about 469MB,
and subsequent prints 8MB, which accumulates to 1.3 GB usage. [ On the
i686-linux laptop, the first print costs us 335MB. ]
The subsequent 8MBs are consistent with the values being saved into the value
history, but the usage for the initial print seems somewhat excessive.
There is a PR open about needing sparse representation of large arrays
(PR8819), but this memory usage points to an independent problem.
The function value_print_array_elements contains a scoped_value_mark to free
allocated values in the outer loop, but it doesn't prevent the inner loop from
allocating a lot of values.
Fix this by adding a scoped_value_mark in the inner loop, after which we have:
...
(gdb) print a^M
$1 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
(gdb) print a^M
$2 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
(gdb) print a^M
$3 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
...
(gdb) print a^M
$100 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
...
Note that the +0 here just means that the mallocs did not trigger an sbrk.
This is dependent on malloc (which can use either mmap or sbrk or some
pre-allocated memory) and will likely vary between different tunings, versions
and implementations, so this does not give us a reliable way detect the
problem in a minimal way.
A more reliable way of detecting the problem is:
...
void
value_free_to_mark (const struct value *mark)
{
+ size_t before = all_values.size ();
auto iter = std::find (all_values.begin (), all_values.end (), mark);
if (iter == all_values.end ())
all_values.clear ();
else
all_values.erase (iter + 1, all_values.end ());
+ size_t after = all_values.size ();
+ if (before - after >= 1024)
+ fprintf (stderr, "value_free_to_mark freed %zu items\n", before - after);
...
which without the fix tells us:
...
+print a
value_free_to_mark freed 2097152 items
$1 = {0 <repeats 2097152 times>}
...
Fix a similar problem for Fortran:
...
+print array1
value_free_to_mark freed 4194303 items
$1 = (0, <repeats 2097152 times>)
...
in fortran_array_printer_impl::process_element.
The problem also exists for Ada:
...
+print Arr
value_free_to_mark freed 2097152 items
$1 = (0 <repeats 2097152 times>)
...
but is fixed by the fix for C.
Add Fortran and Ada variants of the test-case. The *.exp files are similar
enough to the original to keep the copyright years range.
While writing the Fortran test-case, I ran into needing an additional print
setting to print the entire array in repeat form, filed as PR exp/30817.
I managed to apply the compilation loop for the Ada variant as well, but with
a cumbersome repetition style. I noticed no other test-case uses gnateD, so
perhaps there's a better way of implementing this.
The regression test included in the patch is formulated in its weakest
form, to avoid false positive FAILs, which also means that smaller regressions
may not get detected.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
I noticed many spots checking whether a dynamic property's kind is
PROP_CONST. Some spots, I think, are doing a slightly incorrect check
-- checking for != PROP_UNDEFINED where == PROP_CONST is actually
required, the key thing being that const_val may only be called for
PROP_CONST properties.
This patch adds dynamic::is_constant and then updates these checks to
use it.
Regression tested on x86-64 Fedora 36.
This turns many functions that are related to optimized-out or
availability-checking to be methods of value. The static function
value_entirely_covered_by_range_vector is also converted to be a
private method.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
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>
This changes value_contents_eq to be a method of value. It also
converts the static function value_contents_bits_eq into a private
method.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This commit introduces the idea of loading only part of an array in
order to print it, what I call "limited length" arrays.
The motivation behind this work is to make it possible to print slices
of very large arrays, where very large means bigger than
`max-value-size'.
Consider this GDB session with the current GDB:
(gdb) set max-value-size 100
(gdb) p large_1d_array
value requires 400 bytes, which is more than max-value-size
(gdb) p -elements 10 -- large_1d_array
value requires 400 bytes, which is more than max-value-size
notice that the request to print 10 elements still fails, even though 10
elements should be less than the max-value-size. With a patched version
of GDB:
(gdb) p -elements 10 -- large_1d_array
$1 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...}
So now the print has succeeded. It also has loaded `max-value-size'
worth of data into value history, so the recorded value can be accessed
consistently:
(gdb) p -elements 10 -- $1
$2 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...}
(gdb) p $1
$3 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
20, 21, 22, 23, 24, <unavailable> <repeats 75 times>}
(gdb)
Accesses with other languages work similarly, although for Ada only
C-style [] array element/dimension accesses use history. For both Ada
and Fortran () array element/dimension accesses go straight to the
inferior, bypassing the value history just as with C pointers.
Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
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.
This changes GDB to use frame_info_ptr instead of frame_info *
The substitution was done with multiple sequential `sed` commands:
sed 's/^struct frame_info;/class frame_info_ptr;/'
sed 's/struct frame_info \*/frame_info_ptr /g' - which left some
issues in a few files, that were manually fixed.
sed 's/\<frame_info \*/frame_info_ptr /g'
sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace
problems.
The changed files were then manually checked and some 'sed' changes
undone, some constructors and some gets were added, according to what
made sense, and what Tromey originally did
Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>
Add the `length` and `set_length` methods on `struct type`, in order to remove
the `TYPE_LENGTH` macro. In this patch, the macro is changed to use the
getter, so all the call sites of the macro that are used as a setter are
changed to use the setter method directly. The next patch will remove the
macro completely.
Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4
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.
Now that filtered and unfiltered output can be treated identically, we
can unify the putc family of functions. This is done under the name
"gdb_putc". Most of this patch was written by script.
Now that filtered and unfiltered output can be treated identically, we
can unify the puts family of functions. This is done under the name
"gdb_puts". Most of this patch was written by script.
PR fortran/28801 points out a gdb crash that can be provoked by
certain Fortran code. The bug is that f77_get_upperbound assumes the
property is either a constant or undefined, but in this case it is
PROP_LOCEXPR.
This patch fixes the crash by making this function (and the
lower-bound one as well) do the correct check before calling
'const_val'.
Thanks to Andrew for writing the test case.
Co-authored-by: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28801
Gfortran supports namelists (a Fortran feature); it emits
DW_TAG_namelist and DW_TAG_namelist_item dies. But gdb does not
process these dies and does not support 'print' or 'ptype' commands on
namelist variables.
An attempt to print namelist variables results in gdb bailing out with
the error message as shown below.
(gdb) print nml
No symbol "nml" in current context.
This commit is to make the print and ptype commands work for namelist
variables and its items. Sample output of these commands is shared
below, with fixed gdb.
(gdb) ptype nml
type = Type nml
integer(kind=4) :: a
integer(kind=4) :: b
End Type nml
(gdb) print nml
$1 = ( a = 10, b = 20 )
Add a getter and a setter for a symbol's domain. Remove the
corresponding macro and adjust all callers.
Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3
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.
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>
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.
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
Remove the `TYPE_FIELD_NAME` and `FIELD_NAME` macros, changing all the
call sites to use field::name directly.
Change-Id: I6900ae4e1ffab1396e24fb3298e94bf123826ca6
This variable appears to be unused. Its uses were removed in commit
3e2e34f862 ("fort_dyn_array: Use value constructor instead of
raw-buffer manipulation.") back in 2016.
gdb/ChangeLog:
* f-valprint.c (f77_array_offset_tbl): Remove.
Change-Id: I39ff8d1b402e54ca2ade936f65e540f500cce86e
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.
This commit removes some, but not all, uses of LA_PRINT_STRING. In
this commit I've removed those uses where there is an obvious language
object on which I can instead call the printstr method.
In the remaining 3 uses it is harder to know if the correct thing is
to call printstr on the current language, or on a specific language.
Currently obviously, we always call on the current language (as that's
what LA_PRINT_STRING does), and clearly this behaviour is good enough
right now, but is it "right"? I've left them for now and will give
them more thought in the future.
gdb/ChangeLog:
* expprint.c (print_subexp_standard): Replace uses of
LA_PRINT_STRING.
* f-valprint.c (f_language::value_print_inner): Likewise.
* guile/scm-pretty-print.c (ppscm_print_string_repr): Likewise.
* p-valprint.c (pascal_language::value_print_inner): Likewise.
* python/py-prettyprint.c (print_string_repr): Likewise.
This commit brings array slice support to GDB.
WARNING: This patch contains a rather big hack which is limited to
Fortran arrays, this can be seen in gdbtypes.c and f-lang.c. More
details on this below.
This patch rewrites two areas of GDB's Fortran support, the code to
extract an array slice, and the code to print an array.
After this commit a user can, from the GDB prompt, ask for a slice of
a Fortran array and should get the correct result back. Slices can
(optionally) have the lower bound, upper bound, and a stride
specified. Slices can also have a negative stride.
Fortran has the concept of repacking array slices. Within a compiled
Fortran program if a user passes a non-contiguous array slice to a
function then the compiler may have to repack the slice, this involves
copying the elements of the slice to a new area of memory before the
call, and copying the elements back to the original array after the
call. Whether repacking occurs will depend on which version of
Fortran is being used, and what type of function is being called.
This commit adds support for both packed, and unpacked array slicing,
with the default being unpacked.
With an unpacked array slice, when the user asks for a slice of an
array GDB creates a new type that accurately describes where the
elements of the slice can be found within the original array, a
value of this type is then returned to the user. The address of an
element within the slice will be equal to the address of an element
within the original array.
A user can choose to select packed array slices instead using:
(gdb) set fortran repack-array-slices on|off
(gdb) show fortran repack-array-slices
With packed array slices GDB creates a new type that reflects how the
elements of the slice would look if they were laid out in contiguous
memory, allocates a value of this type, and then fetches the elements
from the original array and places then into the contents buffer of
the new value.
One benefit of using packed slices over unpacked slices is the memory
usage, taking a small slice of N elements from a large array will
require (in GDB) N * ELEMENT_SIZE bytes of memory, while an unpacked
array will also include all of the "padding" between the
non-contiguous elements. There are new tests added that highlight
this difference.
There is also a new debugging flag added with this commit that
introduces these commands:
(gdb) set debug fortran-array-slicing on|off
(gdb) show debug fortran-array-slicing
This prints information about how the array slices are being built.
As both the repacking, and the array printing requires GDB to walk
through a multi-dimensional Fortran array visiting each element, this
commit adds the file f-array-walk.h, which introduces some
infrastructure to support this process. This means the array printing
code in f-valprint.c is significantly reduced.
The only slight issue with this commit is the "rather big hack" that I
mentioned above. This hack allows us to handle one specific case,
array slices with negative strides. This is something that I don't
believe the current GDB value contents model will allow us to
correctly handle, and rather than rewrite the value contents code
right now, I'm hoping to slip this hack in as a work around.
The problem is that, as I see it, the current value contents model
assumes that an object base address will be the lowest address within
that object, and that the contents of the object start at this base
address and occupy the TYPE_LENGTH bytes after that.
( We do have the embedded_offset, which is used for C++ sub-classes,
such that an object can start at some offset from the content buffer,
however, the assumption that the object then occupies the next
TYPE_LENGTH bytes is still true within GDB. )
The problem is that Fortran arrays with a negative stride don't follow
this pattern. In this case the base address of the object points to
the element with the highest address, the contents of the array then
start at some offset _before_ the base address, and proceed for one
element _past_ the base address.
As the stride for such an array would be negative then, in theory the
TYPE_LENGTH for this type would also be negative. However, in many
places a value in GDB will degrade to a pointer + length, and the
length almost always comes from the TYPE_LENGTH.
It is my belief that in order to correctly model this case the value
content handling of GDB will need to be reworked to split apart the
value's content buffer (which is a block of memory with a length), and
the object's in memory base address and length, which could be
negative.
Things are further complicated because arrays with negative strides
like this are always dynamic types. When a value has a dynamic type
and its base address needs resolving we actually store the address of
the object within the resolved dynamic type, not within the value
object itself.
In short I don't currently see an easy path to cleanly support this
situation within GDB. And so I believe that leaves two options,
either add a work around, or catch cases where the user tries to make
use of a negative stride, or access an array with a negative stride,
and throw an error.
This patch currently goes with adding a work around, which is that
when we resolve a dynamic Fortran array type, if the stride is
negative, then we adjust the base address to point to the lowest
address required by the array. The printing and slicing code is aware
of this adjustment and will correctly slice and print Fortran arrays.
Where this hack will show through to the user is if they ask for the
address of an array in their program with a negative array stride, the
address they get from GDB will not match the address that would be
computed within the Fortran program.
gdb/ChangeLog:
* Makefile.in (HFILES_NO_SRCDIR): Add f-array-walker.h.
* NEWS: Mention new options.
* f-array-walker.h: New file.
* f-lang.c: Include 'gdbcmd.h' and 'f-array-walker.h'.
(repack_array_slices): New static global.
(show_repack_array_slices): New function.
(fortran_array_slicing_debug): New static global.
(show_fortran_array_slicing_debug): New function.
(value_f90_subarray): Delete.
(skip_undetermined_arglist): Delete.
(class fortran_array_repacker_base_impl): New class.
(class fortran_lazy_array_repacker_impl): New class.
(class fortran_array_repacker_impl): New class.
(fortran_value_subarray): Complete rewrite.
(set_fortran_list): New static global.
(show_fortran_list): Likewise.
(_initialize_f_language): Register new commands.
(fortran_adjust_dynamic_array_base_address_hack): New function.
* f-lang.h (fortran_adjust_dynamic_array_base_address_hack):
Declare.
* f-valprint.c: Include 'f-array-walker.h'.
(class fortran_array_printer_impl): New class.
(f77_print_array_1): Delete.
(f77_print_array): Delete.
(fortran_print_array): New.
(f_value_print_inner): Update to call fortran_print_array.
* gdbtypes.c: Include 'f-lang.h'.
(resolve_dynamic_type_internal): Call
fortran_adjust_dynamic_array_base_address_hack.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-slices-bad.exp: New file.
* gdb.fortran/array-slices-bad.f90: New file.
* gdb.fortran/array-slices-sub-slices.exp: New file.
* gdb.fortran/array-slices-sub-slices.f90: New file.
* gdb.fortran/array-slices.exp: Rewrite tests.
* gdb.fortran/array-slices.f90: Rewrite tests.
* gdb.fortran/vla-sizeof.exp: Correct expected results.
gdb/doc/ChangeLog:
* gdb.texinfo (Debugging Output): Document 'set/show debug
fortran-array-slicing'.
(Special Fortran Commands): Document 'set/show fortran
repack-array-slices'.
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.
This commit makes the whitespace usage when printing Fortran arrays
more consistent, and more inline with how we print C arrays.
Currently a 2 dimensional Fotran array is printed like this, I find
the marked whitespace unpleasant:
(( 1, 2, 3) ( 4, 5, 6) )
^ ^ ^
After this commit the same array is printed like this:
((1, 2, 3) (4, 5, 6))
Which seems more inline with how we print C arrays, in the case of C
arrays we don't add extra whitespace before the first element.
gdb/ChangeLog:
* f-valprint.c (f77_print_array_1): Adjust printing of whitespace
for arrays.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-slices.exp: Update expected results.
* gdb.fortran/class-allocatable-array.exp: Likewise.
* gdb.fortran/multi-dim.exp: Likewise.
* gdb.fortran/vla-type.exp: Likewise.
* gdb.mi/mi-vla-fortran.exp: Likewise.
I looked through the various language value-print functions, to see if
any code could be consolidated. Pretty much all I found was that
f_value_print_inner does not need to handle TYPE_CODE_INT itself, but
can simply dispatch to the generic printer.
gdb/ChangeLog
2020-09-15 Tom Tromey <tom@tromey.com>
* f-valprint.c (f_value_print_inner) <case TYPE_CODE_INT>:
Remove.
Getting the bounds of an array (or string) type is a common operation,
and is currently done through its index type:
my_array_type->index_type ()->bounds ()
I think it would make sense to let the `type::bounds` methods work for
arrays and strings, as a shorthand for this. It's natural that when
asking for the bounds of an array, we get the bounds of the range type
used as its index type. In a way, it's equivalent as the now-removed
TYPE_ARRAY_{LOWER,UPPER}_BOUND_IS_UNDEFINED and
TYPE_ARRAY_{LOWER,UPPER}_BOUND_VALUE, except it returns the
`range_bounds` object. The caller is then responsible for getting the
property it needs in it.
I updated all the spots I could find that could take advantage of this.
Note that this also makes `type::bit_stride` work on array types, since
`type::bit_stride` uses `type::bounds`. `my_array_type->bit_stride ()`
now returns the bit stride of the array's index type. So some spots
are also changed to take advantage of this.
gdb/ChangeLog:
* gdbtypes.h (struct type) <bounds>: Handle array and string
types.
* ada-lang.c (assign_aggregate): Use type::bounds on
array/string type.
* c-typeprint.c (c_type_print_varspec_suffix): Likewise.
* c-varobj.c (c_number_of_children): Likewise.
(c_describe_child): Likewise.
* eval.c (evaluate_subexp_for_sizeof): Likewise.
* f-typeprint.c (f_type_print_varspec_suffix): Likewise.
(f_type_print_base): Likewise.
* f-valprint.c (f77_array_offset_tbl): Likewise.
(f77_get_upperbound): Likewise.
(f77_print_array_1): Likewise.
* guile/scm-type.c (gdbscm_type_range): Likewise.
* m2-typeprint.c (m2_array): Likewise.
(m2_is_long_set_of_type): Likewise.
* m2-valprint.c (get_long_set_bounds): Likewise.
* p-typeprint.c (pascal_type_print_varspec_prefix): Likewise.
* python/py-type.c (typy_range): Likewise.
* rust-lang.c (rust_internal_print_type): Likewise.
* type-stack.c (type_stack::follow_types): Likewise.
* valarith.c (value_subscripted_rvalue): Likewise.
* valops.c (value_cast): Likewise.
Change-Id: I5c0c08930bffe42fd69cb4bfcece28944dd88d1f
Remove it and update all callers to use the equivalent accessor methods.
A subsequent patch will make type::bit_stride work for array types
(effectively replacing this macro), but I wanted to keep this patch a
simple mechanical change.
gdb/ChangeLog:
* gdbtypes.c (TYPE_ARRAY_BIT_STRIDE): Remove. Update all
callers to use the equivalent accessor methods.
Change-Id: I09e14bd45075f98567adce8a0b93edea7722f812
Remove the macros, use the various equivalent getters instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_ARRAY_LOWER_BOUND_VALUE,
TYPE_ARRAY_UPPER_BOUND_VALUE): Remove. Update all
callers to use the equivalent accessor methods instead.
Change-Id: I7f96d988f872170e7a2f58095832710e62b85cfd
Remove the macros, use the various equivalent getters instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_ARRAY_UPPER_BOUND_IS_UNDEFINED,
TYPE_ARRAY_LOWER_BOUND_IS_UNDEFINED): Remove. Update all
callers to use the equivalent accessor methods instead.
Change-Id: Ifb4c36f440b82533bde5d15a5cbb2fc91f467292
This commit changes the language_data::la_value_print_inner function
pointer member variable into a member function of language_defn.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language_data): Delete la_value_print_inner
initializer.
(ada_language::value_print_inner): New member function.
* c-lang.c (c_language_data): Delete la_value_print_inner
initializer.
(cplus_language_data): Likewise.
(asm_language_data): Likewise.
(minimal_language_data): Likewise.
* d-lang.c (d_language_data): Likewise.
(d_language::value_print_inner): New member function.
* f-lang.c (f_language_data): Delete la_value_print_inner
initializer.
(f_language::value_print_inner): New member function.
* f-lang.h (f_value_print_innner): Rename to...
(f_value_print_inner): ...this (note spelling of 'inner').
* f-valprint.c (f_value_print_innner): Rename to...
(f_value_print_inner): ...this (note spelling of 'inner').
* go-lang.c (go_language_data): Delete la_value_print_inner
initializer.
(go_language::value_print_inner): New member function.
* language.c (language_defn::value_print_inner): Define new member
function.
(unk_lang_value_print_inner): Delete.
(unknown_language_data): Delete la_value_print_inner initializer.
(unknown_language::value_print_inner): New member function.
(auto_language_data): Delete la_value_print_inner initializer.
(auto_language::value_print_inner): New member function.
* language.h (language_data): Delete la_value_print_inner field.
(language_defn::value_print_inner): Delcare new member function.
* m2-lang.c (m2_language_data): Delete la_value_print_inner
initializer.
(m2_language::value_print_inner): New member function.
* objc-lang.c (objc_language_data): Delete la_value_print_inner
initializer.
* opencl-lang.c (opencl_language_data): Likewise.
* p-lang.c (pascal_language_data): Likewise.
(pascal_language::value_print_inner): New member function.
* rust-lang.c (rust_language_data): Delete la_value_print_inner
initializer.
(rust_language::value_print_inner): New member function.
* valprint.c (do_val_print): Update call to value_print_inner.
Remove the `TYPE_FIELD_TYPE` macro, changing all the call sites to use
`type::field` and `field::type` directly.
gdb/ChangeLog:
* gdbtypes.h (TYPE_FIELD_TYPE): Remove. Change all call sites
to use type::field and field::type instead.
Change-Id: Ifda6226a25c811cfd334a756a9fbc5c0afdddff3
Remove `TYPE_INDEX_TYPE` macro, changing all the call sites to use
`type::index_type` directly.
gdb/ChangeLog:
* gdbtypes.h (TYPE_INDEX_TYPE): Remove. Change all call sites
to use type::index_type instead.
Change-Id: I56715df0bdec89463cda6bd341dac0e01b2faf84
Remove `TYPE_NFIELDS`, changing all the call sites to use
`type::num_fields` directly. This is quite a big diff, but this was
mostly done using sed and coccinelle. A few call sites were done by
hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_NFIELDS): Remove. Change all cal sites to use
type::num_fields instead.
Change-Id: Ib73be4c36f9e770e0f729bac3b5257d7cb2f9591
Remove TYPE_CODE, changing all the call sites to use type::code
directly. This is quite a big diff, but this was mostly done using sed
and coccinelle. A few call sites were done by hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_CODE): Remove. Change all call sites to use
type::code instead.
