| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
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.
|
|
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 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.
|
|
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.
|
|
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
Consider the following function, which takes no parameter and returns
an integer:
function Something return Integer;
For the purpose of this discussion, our function has been implemented
to always return 124:
function Something return Integer is
begin
return 124;
end Something;
In Ada, such function can been called without using the parentheses.
For instance, in the statement below, variable My_Value is assigned
the returned value from the call to Something:
My_Value := Something;
The Ada expression interpeter in GDB supports this case, as we can
see below:
(gdb) print something
$1 = 124
However, we get fairly strange results when trying to use this feature
as part of a larger expression. For instance:
(gdb) print something + 1
$2 = 248
The problem occurs while doing the resolution pass of the expression.
After prefixying the expression, we obtain the following expression:
0 BINOP_ADD
1 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
5 OP_LONG Type @0x1e3c170 (int), value 1 (0x1)
The resolution pass is then expected to remove the OP_VAR_VALUE
entry, and replace it with an OP_FUNCALL. This is what the call
to replace_operator_with_call in ada-lang.c::resolve_subexp is
expected to do:
if (deprocedure_p
&& (TYPE_CODE (SYMBOL_TYPE (exp->elts[pc + 2].symbol))
== TYPE_CODE_FUNC))
{
replace_operator_with_call (expp, pc, 0, 0,
exp->elts[pc + 2].symbol,
exp->elts[pc + 1].block);
exp = expp->get ();
}
The problem is that we're passing OPLEN (zero -- 4th parameter in
the call), and so replace_operator_with_call ends up removing zero
element from our expression, and inserting the corresponding OP_FUNCALL
instead. As a result, instead of having the OP_LONG (1) as the second
argument of the BINOP_ADD, it is now the OP_VAR_VALUE that we were
meant to replace. That OP_VAR_VALUE then itself gets transformed into
an OP_FUNCALL, with the same issue, and eventually, the resolved
expression now looks like this:
0 BINOP_ADD
1 OP_FUNCALL Number of args: 0
4 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
8 OP_FUNCALL Number of args: 0
11 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
15 OP_VAR_VALUE Block @0x2021550, symbol @0x20213a0 (pck.something)
19 OP_LONG Type @0x1e3c170 (int), value 1 (0x1)
This explains why we get twice the result of the function call
instead of its value plus one. The extra entries in the expression
at the end are just ignored.
This patch fixes the issue by calling replace_operator_with_call
with the correct OPLEN equal to the size of an OP_VAR_VALUE (4).
gdb/ChangeLog:
* ada-lang.c (resolve_subexp): Pass correct OPLEN in call to
replace_operator_with_call.
gdb/testsuite/ChangeLog:
* gdb.ada/expr_with_funcall: New testcase.
|
