This introduces the new method language_defn::lookup_symbol_local, and
then changes lookup_symbol_local to use it. This removes an explicit
language check from this function, and makes it easier for other
languages to hook into this code.
I noticed that "info locals" on a certain large Ada program was very
slow. I tracked this down to ada_get_tsd_type expanding nearly every
CU in the program.
This patch fixes the problem by changing this code to use the more
efficient lookup_transparent_type which, unlike the Ada-specific
lookup functions, does not try to find all matching instances.
Note that I first tried fixing this by changing ada_find_any_type, but
this did not work -- I may revisit this approach at some later date.
Also note that the copyright dates on the test files are set that way
because I copied them from another test.
New in v2: the new test failed on the Linaro regression tester.
Looking at the logs, it seems that gdb was picking up a 'value' from
libgnat:
$1 = {<text variable, no debug info>} 0xf7e227a4 <ada.calendar.formatting.value>
This version renames the local variable in an attempt to work around
this.
v3: In v2, while trying to reproduce the problem locally, I
accidentally forgot to commit one of the changes.
We currently pass frames to function by value, as `frame_info_ptr`.
This is somewhat expensive:
- the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass
by value
- the constructors and destructor link/unlink the object in the global
`frame_info_ptr::frame_list` list. This is an `intrusive_list`, so
it's not so bad: it's just assigning a few points, there's no memory
allocation as if it was `std::list`, but still it's useless to do
that over and over.
As suggested by Tom Tromey, change many function signatures to accept
`const frame_info_ptr &` instead of `frame_info_ptr`.
Some functions reassign their `frame_info_ptr` parameter, like:
void
the_func (frame_info_ptr frame)
{
for (; frame != nullptr; frame = get_prev_frame (frame))
{
...
}
}
I wondered what to do about them, do I leave them as-is or change them
(and need to introduce a separate local variable that can be
re-assigned). I opted for the later for consistency. It might not be
clear why some functions take `const frame_info_ptr &` while others take
`frame_info_ptr`. Also, if a function took a `frame_info_ptr` because
it did re-assign its parameter, I doubt that we would think to change it
to `const frame_info_ptr &` should the implementation change such that
it doesn't need to take `frame_info_ptr` anymore. It seems better to
have a simple rule and apply it everywhere.
Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0
Approved-By: Andrew Burgess <aburgess@redhat.com>
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 changes quick_symbol_functions::lookup_global_symbol_language to
accept domain_search_flags rather than just a domain_enum, and fixes
up the fallout.
To avoid introducing any regressions, any code passing VAR_DOMAIN now
uses SEARCH_VFT.
That is, no visible changes should result from this patch. However,
it sets the stage to refine some searches later on.
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.
When gdb starts up with a symbol file, it uses the program's "main" to
decide the "static context" and the initial language. With background
DWARF reading, this means that gdb has to wait for a significant
amount of DWARF to be read synchronously.
This patch introduces lazy language setting. The idea here is that in
many cases, the prompt can show up early, making gdb feel more
responsive.
This changes the 'current_language' global to be a macro that wraps a
function call. This change will let a subsequent patch introduce lazy
language setting.
This adds new is_array_like and to_array methods to language_defn.
This will be used in a subsequent patch that generalizes the new
Python array- and string-handling code.
History Of This Patch
=====================
This commit aims to address PR gdb/21699. There have now been a
couple of attempts to fix this issue. Simon originally posted two
patches back in 2021:
https://sourceware.org/pipermail/gdb-patches/2021-July/180894.htmlhttps://sourceware.org/pipermail/gdb-patches/2021-July/180896.html
Before Pedro then posted a version of his own:
https://sourceware.org/pipermail/gdb-patches/2021-July/180970.html
After this the conversation halted. Then in 2023 I (Andrew) also took
a look at this bug and posted two versions:
https://sourceware.org/pipermail/gdb-patches/2023-April/198570.htmlhttps://sourceware.org/pipermail/gdb-patches/2023-April/198680.html
The approach taken in my first patch was pretty similar to what Simon
originally posted back in 2021. My second attempt was only a slight
variation on the first.
Pedro then pointed out his older patch, and so we arrive at this
patch. The GDB changes here are mostly Pedro's work, but updated by
me (Andrew), any mistakes are mine.
The tests here are a combinations of everyone's work, and the commit
message is new, but copies bits from everyone's earlier work.
Problem Description
===================
Bug PR gdb/21699 makes the observation that using $_as_string with
GDB's printf can cause GDB to print unexpected data from the
inferior. The reproducer is pretty simple:
#include <stddef.h>
static char arena[100];
/* Override malloc() so value_coerce_to_target() gets a known
pointer, and we know we"ll see an error if $_as_string() gives
a string that isn't null terminated. */
void
*malloc (size_t size)
{
memset (arena, 'x', sizeof (arena));
if (size > sizeof (arena))
return NULL;
return arena;
}
int
main ()
{
return 0;
}
And then in a GDB session:
$ gdb -q test
Reading symbols from /tmp/test...
(gdb) start
Temporary breakpoint 1 at 0x4004c8: file test.c, line 17.
Starting program: /tmp/test
Temporary breakpoint 1, main () at test.c:17
17 return 0;
(gdb) printf "%s\n", $_as_string("hello")
"hello"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
(gdb) quit
The problem above is caused by how value_cstring is used within
py-value.c, but once we understand the issue then it turns out that
value_cstring is used in an unexpected way in many places within GDB.
Within py-value.c we have a null-terminated C-style string. We then
pass a pointer to this string, along with the length of this
string (so not including the null-character) to value_cstring.
In value_cstring GDB allocates an array value of the given character
type, and copies in requested number of characters. However
value_cstring does not add a null-character of its own. This means
that the value created by calling value_cstring is only
null-terminated if the null-character is included in the passed in
length. In py-value.c this is not the case, and indeed, in most uses
of value_cstring, this is not the case.
When GDB tries to print one of these strings the value contents are
pushed to the inferior, and then read back as a C-style string, that
is, GDB reads inferior memory until it finds a null-terminator. For
the py-value.c case, no null-terminator is pushed into the inferior,
so GDB will continue reading inferior memory until a null-terminator
is found, with unpredictable results.
Patch Description
=================
The first thing this patch does is better define what the arguments
for the two function value_cstring and value_string should represent.
The comments in the header file are updated to describe whether the
length argument should, or should not, include a null-character.
Also, the data argument is changed to type gdb_byte. The functions as
they currently exist will handle wide-characters, in which case more
than one 'char' would be needed for each character. As such using
gdb_byte seems to make more sense.
To avoid adding casts throughout GDB, I've also added an overload that
still takes a 'char *', but asserts that the character type being used
is of size '1'.
The value_cstring function is now responsible for adding a null
character at the end of the string value it creates.
However, once we start looking at how value_cstring is used, we
realise there's another, related, problem. Not every language's
strings are null terminated. Fortran and Ada strings, for example,
are just an array of characters, GDB already has the function
value_string which can be used to create such values.
Consider this example using current GDB:
(gdb) set language ada
(gdb) p $_gdb_setting("arch")
$1 = (97, 117, 116, 111)
(gdb) ptype $
type = array (1 .. 4) of char
(gdb) p $_gdb_maint_setting("test-settings string")
$2 = (0)
(gdb) ptype $
type = array (1 .. 1) of char
This shows two problems, first, the $_gdb_setting and
$_gdb_maint_setting functions are calling value_cstring using the
builtin_char character, rather than a language appropriate type. In
the first call, the 'arch' case, the value_cstring call doesn't
include the null character, so the returned array only contains the
expected characters. But, in the $_gdb_maint_setting example we do
end up including the null-character, even though this is not expected
for Ada strings.
This commit adds a new language method language_defn::value_string,
this function takes a pointer and length and creates a language
appropriate value that represents the string. For C, C++, etc this
will be a null-terminated string (by calling value_cstring), and for
Fortran and Ada this can be a bounded array of characters with no null
terminator. Additionally, this new language_defn::value_string
function is responsible for selecting a language appropriate character
type.
After this commit the only calls to value_cstring are from the C
expression evaluator and from the default language_defn::value_string.
And the only calls to value_string are from Fortan, Ada, and ObjectC
related code.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21699
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Co-Authored-By: Pedro Alves <pedro@palves.net>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
g++ 13.1.1 produces a -Werror=dangling-pointer=
In file included from ../../binutils-gdb/gdb/frame.h:75,
from ../../binutils-gdb/gdb/symtab.h:40,
from ../../binutils-gdb/gdb/language.c:33:
In member function ‘void intrusive_list<T, AsNode>::push_empty(T&) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’,
inlined from ‘void intrusive_list<T, AsNode>::push_back(reference) [with T = frame_info_ptr; AsNode = intrusive_base_node<frame_info_ptr>]’ at gdbsupport/intrusive_list.h:332:24,
inlined from ‘frame_info_ptr::frame_info_ptr(const frame_info_ptr&)’ at gdb/frame.h:241:26,
inlined from ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’ at gdb/language.c:530:49:
gdbsupport/intrusive_list.h:415:12: error: storing the address of local variable ‘<anonymous>’ in ‘frame_info_ptr::frame_list.intrusive_list<frame_info_ptr>::m_back’ [-Werror=dangling-pointer=]
415 | m_back = &elem;
| ~~~~~~~^~~~~~~
gdb/language.c: In function ‘CORE_ADDR skip_language_trampoline(frame_info_ptr, CORE_ADDR)’:
gdb/language.c:530:49: note: ‘<anonymous>’ declared here
530 | CORE_ADDR real_pc = lang->skip_trampoline (frame, pc);
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
gdb/frame.h:359:41: note: ‘frame_info_ptr::frame_list’ declared here
359 | static intrusive_list<frame_info_ptr> frame_list;
| ^~~~~~~~~~
Each new frame_info_ptr is being pushed on a static frame list and g++
cannot see why that is safe in case the frame_info_ptr is created and
destroyed immediately when passed as value.
It isn't clear why only in this one place g++ sees the issue (probably
because it can inline enough code in this specific case).
Since passing the frame_info_ptr as const reference is cheaper, use
that as workaround for this warning.
PR build/30413
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30413
Tested-by: Kevin Buettner <kevinb@redhat.com>
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Reviewed-by: Tom Tromey <tom@tromey.com>
set_language returns the previous language, but nothing uses it. Remove
the return value. This lets us remove the assignment to
current_language, in _initialize_language.
Change-Id: Ifccf9b488434c1addf4626130a74e159a37d8c17
Reviewed-By: Tom Tromey <tom@tromey.com>
I noticed that language_demangle shadows the global
"current_language". When I went to fix this, though, I then saw that
language_demangle is only called in two places, and has a comment
saying it should be removed. This patch removes it. Note that the
NULL check in language_demangle is not needed by either of the
existing callers.
Regression tested on x86-64 Fedora 36.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This commit splits the `set/show print elements' option into two. We
retain `set/show print elements' for controlling how many elements of an
array we print, but a new `set/show print characters' setting is added
which is used for controlling how many characters of a string are
printed.
The motivation behind this change is to allow users a finer level of
control over how data is printed, reflecting that, although strings can
be thought of as arrays of characters, users often want to treat these
two things differently.
For compatibility reasons by default the `set/show print characters'
option is set to `elements', which makes the limit for character strings
follow the setting of the `set/show print elements' option, as it used
to. Using `set print characters' with any other value makes the limit
independent from the `set/show print elements' setting, however it can
be restored to the default with the `set print characters elements'
command at any time.
A corresponding `-characters' option for the `print' command is added,
with the same semantics, i.e. one can use `elements' to make a given
`print' invocation follow the limit of elements, be it set with the
`-elements' option also given with the same invocation or taken from the
`set/show print elements' setting, for characters as well regardless of
the current setting of the `set/show print characters' option.
The GDB changes are all pretty straightforward, just changing references
to the old 'print_max' to use a new `get_print_max_chars' helper which
figures out which of the two of `print_max' and `print_max_chars' values
to use.
Likewise, the documentation is just updated to reference the new setting
where appropriate.
To make people's life easier the message shown by `show print elements'
now indicates if the setting also applies to character strings:
(gdb) set print characters elements
(gdb) show print elements
Limit on string chars or array elements to print is 200.
(gdb) set print characters unlimited
(gdb) show print elements
Limit on array elements to print is 200.
(gdb)
and the help text shows the dependency as well:
(gdb) help set print elements
Set limit on array elements to print.
"unlimited" causes there to be no limit.
This setting also applies to string chars when "print characters"
is set to "elements".
(gdb)
In the testsuite there are two minor updates, one to add `-characters'
to the list of completions now shown for the `print' command, and a bare
minimum pair of checks for the right handling of `set print characters'
and `show print characters', copied from the corresponding checks for
`set print elements' and `show print elements' respectively.
Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.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.
PR exp/28359 points out that 'ptype/o' does not work when the current
language is "asm".
I tracked this down to a hard-coded list of languages in typeprint.c.
This patch replaces this list with a method on 'language_defn'
instead. If all languages are ever updated to have this feature, the
method could be removed; but in the meantime this lets each language
control what happens.
I looked at having each print_type method simply modify the flags
itself, but this doesn't work very well with the feature that disables
method-printing by default (but allows it via a flag).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28359
Approved-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Keith Seitz <keiths@redhat.com>
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>
Make an introduction of a new print setting that can be set by 'set
print nibbles [on|off]'. The default value if OFF, which can be changed
by user manually. Of course, 'show print nibbles' is also included in
the patch.
The new feature displays binary values by group, with four bits per
group. The motivation for this work is to enhance the readability of
binary values.
Here's a GDB session before this patch is applied.
(gdb) print var_a
$1 = 1230
(gdb) print/t var_a
$2 = 10011001110
With this patch applied, we can use the new print setting to display the
new form of the binary values.
(gdb) print var_a
$1 = 1230
(gdb) print/t var_a
$2 = 10011001110
(gdb) set print nibbles on
(gdb) print/t var_a
$3 = 0100 1100 1110
Tested on x86_64 openSUSE Tumbleweed.
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.
I noticed that some methods in language_defn could use
unique_xmalloc_ptr<char> rather than a plain 'char *'. This patch
implements this change, fixing up the fallout and changing
gdb_demangle to also return this type. In one spot, std::string is
used to simplify some related code, and in another, an auto_obstack is
used to avoid manual management.
Regression tested on x86-64 Fedora 34.
In a recent commit I used 'manor' in some comments rather than
'manner'. This commit fixes those two mistakes.
I also looked through the gdb/ tree and found one additional instance
of this mistake that this commit also fixes.
I noticed that value_true is declared in language.h and defined in
language.c. However, as part of the value API, I think it would be
better in one of those files. And, because it is very short, I
changed it to be an inline function in value.h. I've also removed a
comment from the implementation, on the basis that it seems obsolete
-- if the change it suggests was needed, it probably would have been
done by now; and if it is needed in the future, odds are it would be
done differently anyway.
Finally, this patch also changes value_true and value_logical_not to
return a bool, and updates some uses.
I noticed that pointer_type is declared in language.h and defined in
language.c. However, it really has to do with types, so it should
have been in gdbtypes.h all along.
This patch changes it to be a method on struct type. And, I went
through uses of TYPE_IS_REFERENCE and updated many spots to use the
new method as well. (I didn't update ones that were in arch-specific
code, as I couldn't readily test that.)
With current master and gcc 7.5.0/8.5.0, we have this timeout:
...
(gdb) print s^M
Multiple matches for s^M
[0] cancel^M
[1] s at src/gdb/testsuite/gdb.ada/interface/foo.adb:20^M
[2] s at src/gdb/testsuite/gdb.ada/interface/foo.adb:?^M
> FAIL: gdb.ada/interface.exp: print s (timeout)
...
[ The FAIL doesn't reproduce with gcc 9.3.1. This difference in
behaviour bisects to gcc commit d70ba0c10de.
The FAIL with earlier gcc bisects to gdb commit ba8694b650. ]
The FAIL is caused by gcc generating this debug info describing a named
artificial variable:
...
<2><1204>: Abbrev Number: 31 (DW_TAG_variable)
<1205> DW_AT_name : s.14
<1209> DW_AT_type : <0x1213>
<120d> DW_AT_artificial : 1
<120d> DW_AT_location : 5 byte block: 91 e0 7d 23 18 \
(DW_OP_fbreg: -288; DW_OP_plus_uconst: 24)
...
An easy way to fix this would be to simply not put named artificial variables
into the symbol table. However, that causes regressions for Ada. It relies
on being able to get the value from such variables, using a named reference.
Fix this instead by marking the symbol as artificial, and:
- ignoring such symbols in ada_resolve_variable, which fixes the FAIL
- ignoring such ada symbols in do_print_variable_and_value, which prevents
them from showing up in "info locals"
Note that a fix for the latter was submitted here (
https://sourceware.org/pipermail/gdb-patches/2008-January/054994.html ), and
this patch borrows from it.
Tested on x86_64-linux.
Co-Authored-By: Joel Brobecker <brobecker@adacore.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28180
I noticed that language_info is only ever called with a value of '1'.
This patch removes the parameter.
2021-03-29 Tom Tromey <tromey@adacore.com>
* top.c (check_frame_language_change): Update.
* language.c (language_info): Remove parameter.
* language.h (language_info): Remove parameter.
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.
Now that every use of the LA_EMIT_CHAR macro is within a language_defn
member function we can simply call the emitchar member function
directly instead of using the LA_EMIT_CHAR macro.
If we are ever inside a language object, for example, cplus_language,
while current_language points at something other than cplus_language
then this commit will result in a change in behaviour. However, I
believe if we did have such a difference then this would be a bug in
GDB. AS such I'm going to claim there _should_ be no user visible
changes from this commit.
gdb/ChangeLog:
* c-lang.c (language_defn::printchar): Call emitchar, not
LA_EMIT_CHAR.
* f-lang.h (f_language::printchar): Likewise.
* language.h (LA_EMIT_CHAR): Delete macro.
* rust-lang.c (rust_language::printchar): Call emitchar, not
LA_EMIT_CHAR.
In the expression rewrite, Ada type resolution will be done at parse
time rather than in a post-parse pass. At this point,
language_defn::post_parser will be removed. However, for this to
work, the information available to post_parser must be made available
during the actual parse.
This patch refactors this code slightly to make this possible. In
particular, "void_context_p" is passed to the parser_state
constructor, and the parser state is then passed to the post_parser
method.
gdb/ChangeLog
2020-12-16 Tom Tromey <tom@tromey.com>
* rust-exp.y (rust_lex_tests): Update.
* parser-defs.h (parser_state): Add void_p parameter.
<void_context_p>: New member.
* parse.c (parse_exp_in_context): Update.
* language.h (language_defn::post_parser): Remove void_context_p,
completing, tracker parameters. Add parser state.
* ada-lang.c (ada_language::post_parser): Update.
This patch changes void_context_p to bool, as a prerequisite to the
change to post_parser that I submitted here:
https://sourceware.org/pipermail/gdb-patches/2020-December/174080.html
Tested by rebuilding.
Note that nothing in-tree passes true here. I don't know why this is,
but there is a use of this internally in AdaCore's tree. I will try
to submit that patch, if it is needed. (And if not, I will come back
around and remove this.)
gdb/ChangeLog
2020-12-16 Tom Tromey <tom@tromey.com>
* parse.c (parse_exp_1, parse_expression_for_completion): Update.
(parse_exp_in_context): Change void_context_p to bool.
* language.h (struct language_defn) <post_parser>: Change
void_context_p to bool.
* ada-lang.c (class ada_language) <post_parser>: Update.
gdb/ChangeLog:
* language.c (language_arch_info::lookup_primitive_type): Use
gdb::function_view instead of gdb::function.
(template language_lookup_primitive_type): Rename to ...
(language_lookup_primitive_type_1): ... this, and make static.
(language_lookup_primitive_type(const struct language_defn *,
struct gdbarch *, const char *): Make non-template.
(language_lookup_primitive_type(const struct language_defn *,
struct gdbarch *, std::function<bool (struct type *)>): Make
non-template and use gdb::function_view.
* language.h (language_arch_info::lookup_primitive_type): Use
gdb::function_view instead of std::function.
(language_lookup_primitive_type): No longer template.
* opencl-lang.c (lookup_opencl_vector_type): 'filter' is now a
lambda instead of a std::function.
Consider the following GDB session:
$ gdb
(gdb) set language c
(gdb) ptype void
type = void
(gdb) set language fortran
(gdb) ptype void
No symbol table is loaded. Use the "file" command.
(gdb)
With no symbol file loaded GDB and the language set to C GDB knows
about the type void, while when the language is set to Fortran GDB
doesn't know about the void, why is that?
In f-lang.c, f_language::language_arch_info, we do have this line:
lai->primitive_type_vector [f_primitive_type_void]
= builtin->builtin_void;
where we add the void type to the list of primitive types that GDB
should always know about, so what's going wrong?
It turns out that the primitive types are stored in a C style array,
indexed by an enum, so Fortran uses `enum f_primitive_types'. The
array is allocated and populated in each languages language_arch_info
member function. The array is allocated with an extra entry at the
end which is left as a NULL value, and this indicates the end of the
array of types.
Unfortunately for Fortran, a type is not assigned for each element in
the enum. As a result the final populated array has gaps in it, gaps
which are initialised to NULL, and so every time we iterate over the
list (for Fortran) we stop early, and never reach the void type.
This has been the case since 2007 when this functionality was added to
GDB in commit cad351d11d.
Obviously I could just fix Fortran by ensuring that either the enum is
trimmed, or we create types for the missing types. However, I think a
better approach would be to move to C++ data structures and removed
the fixed enum indexing into the array approach.
After this commit the primitive types are pushed into a vector, and
GDB just iterates over the vector in the obvious way when it needs to
hunt for a type. After this commit all the currently defined
primitive types can be found when the language is set to Fortran, for
example:
$ gdb
(gdb) set language fortran
(gdb) ptype void
type = void
(gdb)
A new test checks this functionality.
I didn't see any other languages with similar issues, but I could have
missed something.
gdb/ChangeLog:
* ada-exp.y (find_primitive_type): Make parameter const.
* ada-lang.c (enum ada_primitive_types): Delete.
(ada_language::language_arch_info): Update.
* c-lang.c (enum c_primitive_types): Delete.
(c_language_arch_info): Update.
(enum cplus_primitive_types): Delete.
(cplus_language::language_arch_info): Update.
* d-lang.c (enum d_primitive_types): Delete.
(d_language::language_arch_info): Update.
* f-lang.c (enum f_primitive_types): Delete.
(f_language::language_arch_info): Update.
* go-lang.c (enum go_primitive_types): Delete.
(go_language::language_arch_info): Update.
* language.c (auto_or_unknown_language::language_arch_info):
Update.
(language_gdbarch_post_init): Use obstack_new, use array indexing.
(language_string_char_type): Add header comment, call function in
language_arch_info.
(language_bool_type): Likewise
(language_arch_info::bool_type): Define.
(language_lookup_primitive_type_1): Delete.
(language_lookup_primitive_type): Rewrite as a templated function
to call function in language_arch_info, then instantiate twice.
(language_arch_info::type_and_symbol::alloc_type_symbol): Define.
(language_arch_info::lookup_primitive_type_and_symbol): Define.
(language_arch_info::lookup_primitive_type): Define twice with
different signatures.
(language_arch_info::lookup_primitive_type_as_symbol): Define.
(language_lookup_primitive_type_as_symbol): Rewrite to call a
member function in language_arch_info.
* language.h (language_arch_info): Complete rewrite.
(language_lookup_primitive_type): Make templated.
* m2-lang.c (enum m2_primitive_types): Delete.
(m2_language::language_arch_info): Update.
* opencl-lang.c (OCL_P_TYPE): Delete.
(enum opencl_primitive_types): Delete.
(opencl_type_data): Delete.
(builtin_opencl_type): Delete.
(lookup_opencl_vector_type): Update.
(opencl_language::language_arch_info): Update, lots of content
moved from...
(build_opencl_types): ...here. This function is now deleted.
(_initialize_opencl_language): Delete.
* p-lang.c (enum pascal_primitive_types): Delete.
(pascal_language::language_arch_info): Update.
* rust-lang.c (enum rust_primitive_types): Delete.
(rust_language::language_arch_info): Update.
gdb/testsuite/ChangeLog:
* gdb.fortran/types.exp: Add more tests.
Improves the comment at the declaration of language_defn::print_type.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* language.h (language_defn::print_type): Add variable names in
declaration, and update header comment.
GDB already has a global symbol `demangle` (a boolean), having a
language method called `demangle` is not a good idea as we often want
to reference `demangle` the control variable inside `demangle` the
member function.
This commit renames `demangle` the member function to
`demangle_symbol`.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language::demangle): Rename to...
(ada_language::demangle_symbol): ...this.
* c-lang.c (cplus_language::demangle): Rename to...
(cplus_language::demangle_symbol): ...this.
* d-lang.c (d_language::demangle): Rename to...
(d_language::demangle_symbol): ...this.
* f-lang.c (f_language::demangle): Rename to...
(f_language::demangle_symbol): ...this.
* go-lang.c (go_language::demangle): Rename to...
(go_language::demangle_symbol): ...this.
* language.c (language_demangle): Update call to demangle_symbol.
(auto_or_unknown_language::demangle): Rename to...
(auto_or_unknown_language::demangle_symbol): ...this.
* language.h (language_defn::demangle): Rename to...
(language_defn::demangle_symbol): ...this.
* objc-lang.c (objc_language::demangle): Rename to...
(objc_language::demangle_symbol): ...this.
* rust-lang.c (rust_language::demangle): Rename to...
(rust_language::demangle_symbol): ...this.
Replace the single use of the LA_ITERATE_OVER_SYMBOLS macro with the
macro's definition, and delete the macro.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* language.h (LA_ITERATE_OVER_SYMBOLS): Delete.
(iterate_over_file_blocks): Replace use of macro with the macros
definition.
Replace the single use of the LA_PRINT_ARRAY_INDEX macro with the
macro's definition, and delete the macro.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* language.h (LA_PRINT_ARRAY_INDEX): Delete.
* valprint.c (maybe_print_array_index): Replace use of macro with
the macros definition.
Remove the LA_VALUE_PRINT macro, and replace its uses with direct
calls to the value_print member function on an appropriate language.
In the global 'value_print' function, we call the value_print method
on the current_language, this is a direct inline replacement of the
old LA_VALUE_PRINT macro.
However, in ada-lang.c, and language.c the macro was being used
within the print_array_index member function of a language class. In
these cases we now call the value_print member function of the current
language class.
In theory, when we are inside (for example) the
ada_language::print_array_index function the current_language should
always be set to Ada, so this change should have no effect. However,
if we ever could get into ada_language::print_array_index with the
current language set to something else (which I think would have been
a bug) then we would now see a change in behaviour. I couldn't find
any cases where this happened though.
There should be no user visible changes after this commit, but it is
not impossible in some edge cases.
gdb/ChangeLog:
* ada-lang.c (ada_language::print_array_index): Call value_print
directly.
* language.c (language_defn::print_array_index): Likewise.
* language.h (LA_VALUE_PRINT): Delete.
* valprint.c (value_print): Call value_print on the
current_language directly.
Remove the LA_PRINT_TYPEDEF macro, replace the single use with the
macros definition.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* language.h (LA_PRINT_TYPEDEF): Delete.
* typeprint.c (typedef_print): Call print_typedef directly on the
current_language object.
The language_data type, from which language_defn inherits, is now
empty, and this commit removes it.
Each language is updated to no longer create and use a language_data
struct.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language_data): Delete.
(ada_language): Remove references to ada_language_data.
* c-lang.c (c_language_data): Delete.
(c_language): Remove references to c_language_data.
(cplus_language_data): Delete.
(cplus_language): Remove references to cplus_language_data.
(asm_language_data): Delete.
(asm_language): Remove references to asm_language_data.
(minimal_language_data): Delete.
(minimal_language): Remove references to minimal_language_data.
* d-lang.c (d_language_data): Delete.
(d_language): Remove references to d_language_data.
* f-lang.c (f_language_data): Delete.
(f_language): Remove references to f_language_data.
* go-lang.c (go_language_data): Delete.
(go_language): Remove references to go_language_data.
* language.c (unknown_language_data): Delete.
(unknown_language): Remove references to unknown_language_data.
(auto_language_data): Delete.
(auto_language): Remove references to auto_language_data.
* language.h (language_data): Delete struct.
(language_defn): No longer inherit from language_data.
* m2-lang.c (m2_language_data): Delete.
(m2_language): Remove references to m2_language_data.
* objc-lang.c (objc_language_data): Delete.
(objc_language): Remove references to objc_language_data.
* opencl-lang.c (opencl_language_data): Delete.
(opencl_language): Remove references to opencl_language_data.
* p-lang.c (pascal_language_data): Delete.
(pascal_language): Remove references to pascal_language_data.
* rust-lang.c (rust_language_data): Delete.
(rust_language): Remove references to rust_language_data.
Convert language_data::la_op_print_tab member variable to a virtual
method language_defn::opcode_print_table. I changed the name in order
to make it clearer (I hope) what the method does.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language_data): Remove la_op_print_tab
initializer.
(ada_language::opcode_print_table): New member function.
* c-lang.c (c_language_data): Remove la_op_print_tab initializer.
(c_language::opcode_print_table): New member function.
(cplus_language_data): Remove la_op_print_tab initializer.
(cplus_language::opcode_print_table): New member function.
(asm_language_data): Remove la_op_print_tab initializer.
(asm_language::opcode_print_table): New member function.
(minimal_language_data): Remove la_op_print_tab initializer.
(minimal_language::opcode_print_table): New member function.
* d-lang.c (d_language_data): Remove la_op_print_tab initializer.
(d_language::opcode_print_table): New member function.
* expprint.c (print_subexp_standard): Update call to
opcode_print_table.
(op_string): Likewise.
* f-lang.c (f_language_data): Remove la_op_print_tab initializer.
(f_language::opcode_print_table): New member function.
* go-lang.c (go_language_data): Remove la_op_print_tab
initializer.
(go_language::opcode_print_table): New member function.
* language.c (unknown_language_data): Remove la_op_print_tab
initializer.
(unknown_language::opcode_print_table): New member function.
(auto_language_data): Remove la_op_print_tab initializer.
(auto_language::opcode_print_table): New member function.
* language.h (language_data): Remove la_op_print_tab field.
(language_defn::opcode_print_table): Declare new member function.
* m2-lang.c (m2_language_data): Remove la_op_print_tab
initializer.
(m2_language::opcode_print_table): New member function.
* objc-lang.c (objc_language_data): Remove la_op_print_tab
initializer.
(objc_language::opcode_print_table): New member function.
* opencl-lang.c (opencl_language_data): Remove la_op_print_tab
initializer.
(opencl_language::opcode_print_table): New member function.
* p-lang.c (pascal_language_data): Remove la_op_print_tab
initializer.
(pascal_language::opcode_print_table): New member function.
* rust-lang.c (rust_language_data): Remove la_op_print_tab
initializer.
(rust_language::opcode_print_table): New member function.
Convert language_data::la_exp_desc member variable to a virtual
method language_defn::expression_ops. The change of names brings this
method more into line with the existing varobj_ops method, that also
returns a table of function pointers.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language_data): Remove la_exp_desc initializer.
(ada_language::expression_ops): New member function.
* c-lang.c (c_language_data): Remove la_exp_desc initializer.
(c_language::expression_ops): New member function.
(cplus_language_data): Remove la_exp_desc initializer.
(cplus_language::expression_ops): New member function.
(asm_language_data): Remove la_exp_desc initializer.
(asm_language::expression_ops): New member function.
(minimal_language_data): Remove la_exp_desc initializer.
(minimal_language::expression_ops): New member function.
* d-lang.c (d_language_data): Remove la_exp_desc initializer.
(d_language::expression_ops): New member function.
* eval.c (evaluate_subexp): Update call to expression_ops.
* expprint.c (print_subexp): Likewise.
(op_name): Likewise.
(dump_subexp_body): Likewise.
* f-lang.c (f_language_data): Remove la_exp_desc initializer.
(f_language::expression_ops): New member function.
* go-lang.c (go_language_data): Remove la_exp_desc initializer.
(go_language::expression_ops): New member function.
* language.c (language_defn::expression_ops): New function.
(unknown_language_data): Remove la_exp_desc initializer.
(auto_language_data): Likewise.
* language.h (language_data): Remove la_exp_desc field.
(language_defn::expression_ops): Declare new member function.
* m2-lang.c (m2_language_data): Remove la_exp_desc initializer.
(m2_language::expression_ops): New member function.
* objc-lang.c (objc_language_data): Remove la_exp_desc
initializer.
* opencl-lang.c (opencl_language_data): Remove la_exp_desc
initializer.
(opencl_language::expression_ops): New member function.
* p-lang.c (pascal_language_data): Remove la_exp_desc initializer.
* parse.c (operator_length): Update call to expression_ops.
(exp_iterate): Likewise.
* rust-lang.c (rust_language_data): Remove la_exp_desc
initializer.
(ruse_language::expression_ops): New member function.
Convert language_data::la_macro_expansion member variable to a virtual
method language_defn::macro_expansion.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_language_data): Remove la_macro_expansion
initializer.
* c-lang.c (c_language_data): Likewise.
(c_language::macro_expansion): New member function.
(cplus_language_data): Likewise.
(cplus_language::macro_expansion): New member function.
(asm_language_data): Likewise.
(asm_language::macro_expansion): New member function.
(minimal_language_data): Likewise.
(minimal_language::macro_expansion): New member function.
* d-lang.c (d_language_data): Remove la_macro_expansion
initializer.
* f-lang.c (f_language_data): Likewise.
* go-lang.c (go_language_data): Likewise.
* language.c (unknown_language_data): Likewise.
(auto_language_data): Likewise.
* language.h (language_data): Remove la_macro_expansion field.
(language_defn::macro_expansion): New member function.
* m2-lang.c (m2_language_data): Remove la_macro_expansion
initializer.
* objc-lang.c (objc_language_data): Likewise.
(objc_language::macro_expansion): New member function.
* opencl-lang.c (opencl_language_data): Likewise.
(opencl_language::macro_expansion): New member function.
* p-lang.c (pascal_language_data): Remove la_macro_expansion
initializer.
* rust-lang.c (rust_language_data): Likewise.
* symtab.c (default_collect_symbol_completion_matches_break_on):
Update call to macro_expansion.
