| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Function Create_large returns a large data structure. On PowerPC, register
r3 contains the address of where the data structure to be returned is to
be stored. However, on exit the ABI does not guarantee that r3 has not
been changed. The GDB finish command prints the return value of the
function at the end of the function. GDB needs to use the
DW_TAG_call_site information to determine the value of r3 on entry to
the function to correctly print the return value at the end of the
function. The test must be compiled with -fvar-tracking for the
DW_TAG_call_site information to be included in the executable file.
This patch adds the -fvar-tracking option to the compile line if the
option is supported.
The patch fixes the one regression error for the test on PowerPC.
The patch has been tested on Power 10 and X86-64 with no regressions.
|
|
The original intention of the test appears to be checking to make sure
setting a breakpoint in an inlined function didn't set multiple
breakpoints where one of them was at address 0.
The gdb.ada/inline-section-gc.exp test may pass or fail depending on the
version of gnat. Per the discussion on IRC, the ada inlining appears to
have some target dependencies. In this test there are two functions,
callee and caller. Function calee is inlined into caller. The test sets
a breakpoint in function callee. The reported location where the
breakpoint is set may be at the requested location in callee or the
location in caller after callee has been inlined. The test needs to
accept either location as correct provided the breakpoint address is not
zero.
This patch checks to see if the reported breakpoint is in function callee
or function caller and fails if the breakpoint address is 0x0. The line
number where the breakpoint is set will match the requested line if the
breakpoint location is reported is callee.adb. If the breakpoint is
reported in caller.adb, the line number in caller is the breakpoint
location in callee where it is inlined into caller.
This patch fixes the single regression failure for the test on PowerPC.
It does not introduce any failures on X86-64.
|
|
Simon pointed out that the new file-then-restart.exp test fails with
the extended-remote target board.
The problem is that the test suite doesn't use gdb_file_cmd -- which
handles things like "set remote exec-file". This patch changes
gdb_file_cmd to make the "kill" command optional, and then switches
the test case to use it.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30933
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Following on Tom de Vries' work in the other array-printers, this
patch changes val_print_packed_array_elements to also avoid allocating
too many values when printing an Ada packed array.
|
|
When running test-case gdb.ada/import.exp with gcc 7, most test fail:
...
FAIL: gdb.ada/import.exp: print imported_var_ada
FAIL: gdb.ada/import.exp: print local_imported_var
FAIL: gdb.ada/import.exp: print pkg.imported_var_ada
FAIL: gdb.ada/import.exp: print pkg.exported_var_ada
FAIL: gdb.ada/import.exp: print exported_var_ada
FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at pkg.imported_func_ada
FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at imported_func_ada
FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at local_imported_func
...
When running with gcc 8 or 9, only 2 tests fail:
...
FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at pkg.imported_func_ada
FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at imported_func_ada
...
The test-case passes fully with gcc 10, 11, 12 and 13.
Debug info for pragma import seems to not have been supported before gcc 8, so
require that version.
The two FAILs with gcc 8 and 9 seem to be due to problems in debug info. Add
an xfail for these.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
With gcc 13.2.1, I run into a cluster of fails:
...
FAIL: gdb.ada/str_binop_equal.exp: print my_str = "ABCD"
FAIL: gdb.ada/widewide.exp: print my_wws = " helo"
FAIL: gdb.ada/widewide.exp: print my_ws = "wide"
...
The problem is that the debug info contains information about function
ada.strings.maps."=", and gdb uses it to implement the comparison.
The function is supposed to compare two char sets, not strings, so gdb
shouldn't use it. This is PR ada/30908.
I don't see the same problem with gcc 7.5.0, because the exec doesn't contain
the debug info for the function, because the corresponding object is not
linked in. Adter adding "with Ada.Strings.Maps; use Ada.Strings.Maps;" to
gdb.ada/widewide/foo.adb I run into the same problem with gcc 7.5.0.
Add KFAILs for the PR.
Tested on x86_64-linux:
- openSUSE Leap 15.4 (using gcc 7.5.0), and
- openSUSE Tumbleweed (using gcc 13.2.1).
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30908
|
|
When running test-case gdb.ada/mi_task_arg.exp on openSUSE Tumbleweed using
gcc 13.2.1, I run into (layout adapted for readability):
...
-stack-list-arguments 1^M
^done,stack-args=[
frame={level="0",args=[]},
frame={level="1",args=[{name="<_task>",value="0x464820"},
{name="<_taskL>",value="129"}]},
frame={level="2",args=[{name="self_id",value="0x464840"}]},
frame={level="3",args=[]},
frame={level="4",args=[]}
]^M
(gdb) ^M
FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
...
On openSUSE Leap 15.4 with gcc 7.5.0 I get instead:
...
-stack-list-arguments 1^M
^done,stack-args=[
frame={level="0",args=[]},
frame={level="1",args=[{name="<_task>",value="0x444830"}]},
frame={level="2",args=[{name="self_id",value="0x444850"}]},
frame={level="3",args=[]},
frame={level="4",args=[]}]^M
(gdb) ^M
PASS: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1
...
The difference in gdb output is due to difference in the dwarf generated by
the compiler, so I don't see a problem with gdb here.
Fix this by updating the test-case to accept this output.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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>
|
|
When running test-case gdb.ada/arr_acc_idx_w_gap.exp with target board
cc-with-dwz, I run into:
...
(gdb) print enum_with_gaps'enum_rep(lit3)^M
'Enum_Rep requires argument to have same type as enum^M
(gdb) FAIL: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep
...
With target_board unix, we have instead:
...
(gdb) print enum_with_gaps'enum_rep(lit3)^M
$16 = 13^M
(gdb) PASS: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep
...
Conversely, when I add this test to the test-case:
...
gdb_test "print enum_with_gaps'enum_rep(lit3)" " = 13" \
"enum_rep"
+ gdb_test "print enum_subrange'enum_rep(lit3)" " = 13" \
+ "other enum_rep"
...
the extra test passes with target board cc-with-dwz, but fails with target
board unix.
The problem is here in remove_extra_symbols:
...
if (symbols_are_identical_enums (syms))
syms.resize (1);
...
where one of the two identical enums is picked before the enum_rep handling
can resolve lit3 to one of the two.
Fix this by moving the code to ada_resolve_variable.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR ada/30726
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30726
|
|
Test-case gdb.ada/same_enum.exp is supposed to be a regression test for this
bit of code in remove_extra_symbols:
...
if (symbols_are_identical_enums (syms))
syms.resize (1);
...
The test-case does "print red" and expects one of these two choices to be
picked by remove_extra_symbols:
...
type Color is (Black, Red, Green, Blue, White);
type RGB_Color is new Color range Red .. Blue;
...
but because only the type Color is used:
...
FC : Color := Red;
SC : Color := Green;
...
the RGB_Color type is eliminated from the debug info, and consequently
remove_extra_symbols has no effect for the test-case.
In other words, we have:
...
(gdb) ptype Color ^M
type = (black, red, green, blue, white)^M
(gdb) ptype RGB_Color^M
No definition of "rgb_color" in current context.^M
...
Fix this by changing the type of SC to RGB_Color, and add prints of the two
types to check that they're both available.
With the test-case fixed, if we disable the bit of code in
remove_extra_symbols we get:
...
(gdb) print red^M
Multiple matches for red^M
[0] cancel^M
[1] pck.color'(pck.red) (enumeral)^M
[2] pck.rgb_colorB'(pck.red) (enumeral)^M
> FAIL: gdb.ada/same_enum.exp: print red (timeout)
...
in other words, the test-case now properly functions as a regression test.
Tested on x86_64-linux.
|
|
An upstream bug report points out this bug: if the user switches from
one Ada executable to another without "kill"ing the inferior, then the
"start" command will fail.
What happens here is that the Ada "main" name is found in a constant
string in the executable. But, if the inferior is running, then the
process_stratum target reads from the inferior memory.
This patch fixes the problem by changing the main name code to set
trust-readonly-sections, causing the target stack to read from the
executable instead.
I looked briefly at changing GNAT to emit DW_AT_main_subprogram
instead, but this looks to be pretty involved.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25811
|
|
A user noticed that gdb would crash when showing a backtrace.
Investigation showed this to be a crash in the DWARF reader when
handling a "pragma export" symbol. The bug here is that earlier code
decides to eliminate the symbol, but the export code tries to add it
anyway -- but to a NULL list.
|
|
This commit extends the breakpoint mechanism to allow for inferior
specific breakpoints (but not watchpoints in this commit).
As GDB gains better support for multiple connections, and so for
running multiple (possibly unrelated) inferiors, then it is not hard
to imagine that a user might wish to create breakpoints that apply to
any thread in a single inferior. To achieve this currently, the user
would need to create a condition possibly making use of the $_inferior
convenience variable, which, though functional, isn't the most user
friendly.
This commit adds a new 'inferior' keyword that allows for the creation
of inferior specific breakpoints.
Inferior specific breakpoints are automatically deleted when the
associated inferior is removed from GDB, this is similar to how
thread-specific breakpoints are deleted when the associated thread is
deleted.
Watchpoints are already per-program-space, which in most cases mean
watchpoints are already inferior specific. There is a small window
where inferior-specific watchpoints might make sense, which is after a
vfork, when two processes are sharing the same address space.
However, I'm leaving that as an exercise for another day. For now,
attempting to use the inferior keyword with a watchpoint will give an
error, like this:
(gdb) watch a8 inferior 1
Cannot use 'inferior' keyword with watchpoints
A final note on the implementation: currently, inferior specific
breakpoints, like thread-specific breakpoints, are inserted into every
inferior, GDB then checks once the inferior stops if we are in the
correct thread or inferior, and resumes automatically if we stopped in
the wrong thread/inferior.
An obvious optimisation here is to only insert breakpoint locations
into the specific program space (which mostly means inferior) that
contains either the inferior or thread we are interested in. This
would reduce the number times GDB has to stop and then resume again in
a multi-inferior setup.
I have a series on the mailing list[1] that implements this
optimisation for thread-specific breakpoints. Once this series has
landed I'll update that series to also handle inferior specific
breakpoints in the same way. For now, inferior specific breakpoints
are just slightly less optimal, but this is no different to
thread-specific breakpoints in a multi-inferior debug session, so I
don't see this as a huge problem.
[1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/
|
|
I found an obvious bug in Ada aggregate expression handling:
if (vvo != nullptr)
error (_("Invalid record component association."));
name = vvo->get_symbol ()->natural_name ();
Here the code errors when vvo is not null -- and then proceeds to use
vvo.
This hasn't caused a crash because, I believe, there's currently no
way to reach this code in the null case. However, I'm not really
willing to assert this...
Fixing this shows another bug, which is that due to the way the parser
works, a field name in an aggregate expression might erroneously be
fully qualified if some global variable with the same base name
exists.
The included test case triggers both bugs. Note that the test
includes a confounding case for array aggregates as well, but as these
are harder to fix, I've left it as kfail.
As this is Ada-specific, and has already been tested internally at
AdaCore, I am checking it in.
|
|
The NUMCHILD value for the "A_String_Access" test differs for X86 and
PowerPC. The patch substitutes $decimal instead of "1" to match the value
of NUMCHILD.
The test "-var-update A_String_Access" generates different output depending
on the value of VAROBJ_UPDATE_RESULT.TYPE_CHANGED. If the value is true,
the strings "new_type" and "new_num_children" are printed along with their
values.
The VAROBJ_UPDATE_RESULT.TYPE_CHANGED value is true on PowerPC which
produces the output:
Expecting: ^(-var-update A_String_Access[
]+)?(\^done,changelist=\[\{name="A_String_Access",in_scope="true",type_changed="false",has_more="0"\}\][
]+[(]gdb[)]
[ ]*)
-var-update A_String_Access
^done,changelist=[{name="A_String_Access",in_scope="true",type_changed="true",new_type="pck.string_access",new_num_children="1",has_more="0"}]
(gdb)
FAIL: gdb.ada/mi_var_access.exp: update at stop 2 (unexpected output)
The patch adds a second possible result string for the test
$re_varobj_update_result_type to match the case when type_changed is true.
Currently for the mi_var_access.exp test VAROBJ_UPDATE_RESULT.TYPE_CHANGED
is true on PowerPC and false on X86-64.
Fixes 2 failures on PowerPC.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While working on a GNAT bug, I wanted to also test
arr_acc_idx_w_gap.exp using GNAT encodings. When the GNAT change is
ready, I plan to add a new case here.
Tested on x86-64 Fedora 36. I am checking this in.
|
|
The frame command on Power pc prints the address in hex between the
#0 and in calle.increment. For example
(gdb) frame
#0 0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...)
at /home/.../gdb/testsuite/gdb.ada/O2_float_param/callee.adb:19
19 procedure Increment (Val : in out Float; Msg: String) is
The printing of the address for the frame is done by function
print_frame in gdb/stack.c. If SAL.IS_stmt is false for the frame,
function frame_show_address returns true and print_frame prints the
address. Currently, SAL.IS is false on PowerPC and true on X86-64.
Update the set re string to accept the hex address if it exits.
Fixes two failures on PowerPC.
Patch tested on Power10 with no new regressions.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Tom de Vries pointed out that my recent change to fixed_points.exp
failed with older versions of GCC. This patch fixes the problem by
skipping the new test in this situation.
|
|
Alexandre Oliva found a bug in gdb's handling of fixed-point -- a
certain Ada fixed-point type would be misintepreted. The bug was that
the DW_AT_small looked like:
<1><13cd>: Abbrev Number: 16 (DW_TAG_constant)
<13ce> DW_AT_GNU_numerator: 1
<13cf> DW_AT_GNU_denominator: 0x8000000000000000
... but gdb interpreted the denominator as a negative value.
|
|
Ada 2022 adds the "target name symbol", which can be used on the right
hand side of an assignment to refer to the left hand side. This
allows for convenient updates. This patch implements this for gdb's
Ada expression parser.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This patch implements the Ada 2022 attributes 'Enum_Val and 'Enum_Rep.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Commit 80eaec735e ("[gdb/symtab] Handle named DW_TAG_unspecified_type
DIE") changed the handling of DW_TAG_unspecified_type. Before this
change, such types were not entered into the symbol table.
It turns out that, when such a type is in the symtab, it can cause
failures in Ada. In particular, a private type in another package may
be seen locally as "void".
Now, it would probably be better to fix this via check_typedef.
However, that is somewhat difficult given the state of the DWARF
reader -- in particular with gdb_index, this would require expanding
potentially many CUs to find the correct type.
Instead, this patch changes gdb to not enter a symbol for an
unspecified type -- but only for Ada.
|
|
In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in
gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some
files at the start of the test-case:
...
remote_file host delete [standard_output_file prog.o]
remote_file host delete [standard_output_file prog.ali]
...
Then in commit b7b77500dc5 ("[gdb/testsuite] Clean standard_output_file dir in
gdb_init") I tried to do this more structurally, by cleaning up the entire
standard_output_file directory, for all test-cases.
This caused a regression when using "make check -j 2", due to the cleanup
removing the active gdb.log, so I reverted the commit.
Try again, this time handling the two cases separately.
If the standard_output_file directory contains an active gdb.log, check that
the directory contains no files other than gdb.log and gdb.sum. This puts
the reponsibility for the cleanup at the callers in gdb/testsuite/Makefile.in
which use --outdir.
If the standard_output_file directory doesn't contain an active gdb.log, clean
it by removing the entire directory.
An exception is made for performance tests, where cleaning up the
standard_output_file dir is the wrong thing to do, because an invocation with
GDB_PERFTEST_MODE == run is intended to reuse binaries left there by an
earlier invocation with GDB_PERFTEST_MODE == compile.
Tested on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Tom Tromey <tom@tromey.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
With test-case gdb.tui/pr30056.exp, I run into:
...
sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8)^M
...
and then subsequently into:
...
WARNING: timeout in accept_gdb_output
FAIL: gdb.tui/pr30056.exp: Control-C
...
This is on a CentOS 7 distro for powerpc64le.
Either it has no C.UTF-8 support, or it's not installed:
...
$ locale -a | grep ^C
C
$
...
Fix this by:
- adding a new proc have_host_locale, and
- using it in all test-cases using setenv LC_ALL.
Tested on powerpc64le-linux and x86_64-linux.
|
|
This reverts commit b7b77500dc56e5bc21473dd4f3dde2543d894557.
|
|
Test-case gdb.ada/catch_ex_std.exp passes for me with package
libada7-debuginfo installed, but after removing it I get:
...
(gdb) catch exception some_kind_of_error^M
Your Ada runtime appears to be missing some debugging information.^M
Cannot insert Ada exception catchpoint in this configuration.^M
(gdb) FAIL: gdb.ada/catch_ex_std.exp: catch exception some_kind_of_error
...
The test-case contains a require gnat_runtime_has_debug_info to deal with
this, but the problem is that this checks the static gnat runtime, while this
test-case uses the shared one.
Fix this by introducing shared_gnat_runtime_has_debug_info, and requiring that
one instead.
Tested on x86_64-linux.
PR testsuite/30094
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30094
|
|
In commit e2adba909e7 ("[gdb/testsuite] Clean up before compilation in
gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some
files at the start of the test-case:
...
remote_file host delete [standard_output_file prog.o]
remote_file host delete [standard_output_file prog.ali]
...
Replace this with cleaning up the entire directory instead, for all
test-cases.
Tested on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
Running test-case gdb.ada/call-no-debug.exp with target board unix/-m64 works
fine, but if we run it again with target board unix-m32, we run into:
...
gnatlink prog.ali -m32 -g -o prog^M
ld: i386:x86-64 architecture of input file `b~prog.o' is incompatible with \
i386 output^M
...
This is due to compiling with no-force.
The test-case:
- first compiles pck.adb into pck.o (without debug info), and
- then compiles prog.adb and pck.o into prog (with debug info).
Using no-force in the second compilation make sure that pck.adb is not
compiled again, with debug info.
But it also means it will pick up intermediate files related to prog.adb from
a previous compilation.
Fix this by removing prog.o and prog.ali before compilation.
Tested on x86_64-linux.
|
|
This changes the Ada catchpoint tests to use
gnat_runtime_has_debug_info. This simplifies the code.
|
|
With a gdb 13.2 based package on openSUSE Tumbleweed i586, I ran into:
...
(gdb) run ^M
Starting program: out_of_line_in_inlined/foo_o224_021-all ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib/libthread_db.so.1".^M
^M
Breakpoint 1.1, foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:26^M
26 for C of S loop^M
(gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \
run to foo_o224_021.child1.child2
...
I can reproduce the same issue with gdb trunk on x86_64, by using optimize=-O3
instead of optimize=-O2.
Fix this by using $bkptno_num_re.
Tested on x86_64-linux.
PR testsuite/30539
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30539
|
|
This adds two new attributes and three new methods to gdb.Inferior.
The attributes let Python code see the command-line arguments and the
name of "main". Argument setting is also supported.
The methods let Python code manipulate the inferior's environment
variables.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
A co-worker here at AdaCore discovered that the Pragma Import series
caused a rgression. When debugging gnat1, gdb started asking for
overload resolution like:
(gdb) call pp(n)
Multiple matches for pp
[0] cancel
[1] pp (types.union_id) at ../../gcc/gcc/ada/treepr.adb:511
[2] treepr.pp (types.union_id) at ../../gcc/gcc/ada/treepr.adb:511
This worked before the series, and is strange anyway, because the
matches refer to the same function.
This patch adds a test case for this situation and fixes the bug by
pruning identical functions in remove_extra_symbols.
|
|
Ada can import C APIs and also export Ada constructs to C via Pragma
Import and Pragma Export. This patch adds support for these to gdb,
by arranging to either defer some aspects of a symbol to the
underlying C symbol (for Import) or by introducing a second symbol
(for Export). A somewhat tricky approach is needed, both because gdb
doesn't generally handle symbol aliasing, and because Ada treats
symbol names in an unusual way (as compared to the rest of gdb).
|
|
A co-worker at AdaCore noticed that calling a function without
debuginfo yields:
(gdb) print plus_one(23)
'pck.plus_one' has unknown return type; cast the call to its declared return type
However, this also happens if you follow the directions and add the
cast.
This patch fixes the problem and adds a regression test.
|
|
Test-case gdb.ada/excep_handle.exp fails since commit e2f620135d9
("gdb/testsuite: change newline patterns used in gdb_test"):
...
(gdb) continue^M
Continuing.^M
^M
Catchpoint 2, exception at 0x00000000004020b6 in foo () at foo.adb:26^M
26 when Constraint_Error =>^M
(gdb) FAIL: gdb.ada/excep_handle.exp: continuing to first Constraint_Error \
exception handlers
...
The output is supposed to be matched by:
...
gdb_test "continue" \
"Continuing\.$eol$catchpoint_constraint_error_msg$eol.*" \
"continuing to first Constraint_Error exception handlers"
...
but the $eol bit no longer matches due to the stricter matching introduced
in aforementioned commit.
Fix this by dropping the "$eol.*" bit.
Tested on x86_64-linux.
PR testsuite/30399
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30399
|
|
Running gdb.ada/verylong.exp shows a warning from the Ada compiler:
prog.adb:16:11: warning: file name does not match unit name, should be "main.adb" [enabled by default]
This patch fixes the problem, and another similar one in
unchecked_union.exp.
|
|
This commit makes two changes to how we match newline characters in
the gdb_test proc.
First, for the newline pattern between the command output and the
prompt, I propose changing from '[\r\n]+' to an explicit '\r\n'.
The old pattern would spot multiple newlines, and so there are a few
places where, as part of this commit, I've needed to add an extra
trailing '\r\n' to the pattern in the main test file, where GDB's
output actually includes a blank line.
But I think this is a good thing. If a command produces a blank line
then we should be checking for it, the current gdb_test doesn't do
that. But also, with the current gdb_test, if a blank line suddenly
appears in the output, this is going to be silently ignored, and I
think this is wrong, the test should fail in that case.
Additionally, the existing pattern will happily match a partial
newline. There are a strangely large number of tests that end with a
random '.' character. Not matching a literal period, but matching any
single character, this is then matching half of the trailing newline
sequence, while the \[\r\n\]+ in gdb_test is matching the other half
of the sequence. I can think of no reason why this would be
intentional, I suspect that the expected output at one time included a
period, which has since been remove, but I haven't bothered to check
on this. In this commit I've removed all these unneeded trailing '.'
characters.
The basic rule of gdb_test after this is that the expected pattern
needs to match everything up to, but not including the newline
sequence immediately before the GDB prompt. This is generally how the
proc is used anyway, so in almost all cases, this commit represents no
significant change.
Second, while I was cleaning up newline matching in gdb_test, I've
also removed the '[\r\n]*' that was added to the start of the pattern
passed to gdb_test_multiple.
The addition of this pattern adds no value. If the user pattern
matches at the start of a line then this would match against the
newline sequence. But, due to the '*', if the user pattern doesn't
match at the start of a line then this group doesn't care, it'll
happily match nothing.
As such, there's no value to it, it just adds more complexity for no
gain, so I'm removing it. No tests will need updating as a
consequence of this part of the patch.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
call_site_target::iterate_over_addresses may look up a minimal symbol.
On platforms like PPC64 that use function descriptors, this may find
an unexpected address. The fix is to use gdbarch_convert_from_func_ptr_addr
to convert from a function descriptor to the address recorded at the
call site.
I've added a new test case that is based on the internal AdaCore test
that provoked this bug. However, I'm unable to test it as-is on
PPC64.
|
|
This adds support for 128-bit integers to the Ada parser.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30188
|
|
I found a couple of tests that check gnatmake_version_at_least using
"if" where "require" would be a little cleaner. This patch converts
these.
|
|
I noticed there aren't any Ada test cases for setting a breakpoint
using a label. This patch adds one, adapted from the AdaCore test
suite.
|
|
The test case in this patch shows an unusual situation: an Ada array
has a dynamic bound, but the bound comes from a frame that's referred
to by the static link. This frame is correctly found when evaluating
the array variable itself, but is lost when evaluating the array's
bounds.
This patch fixes the problem by passing this frame through to
value_at_lazy in the DWARF expression evaluator.
|
|
With test-case gdb.ada/verylong.exp and gnatmake 7.5.0 I run into:
...
compilation failed: gcc ... $src/gdb/testsuite/gdb.ada/verylong/prog.adb
prog.adb:16:11: warning: file name does not match unit name, should be "main.adb"
prog.adb:17:08: "Long_Long_Long_Integer" is undefined (more references follow)
gnatmake: "prog.adb" compilation error
FAIL: gdb.ada/verylong.exp: compilation prog.adb
...
AFAICT, support for Long_Long_Long_Integer was added in gcc 11.
Fix this by requiring gnatmake version 11 or higher in the test-case.
Tested on x86_64-linux.
|
|
While working on 128-bit integer support, I found one spot in Ada that
needed a fix as well.
|
|
The type-allocation patches introduced a small regression that was
picked up by the AdaCore internal test suite. Previously, the name of
a range type was preserved by resolve_dynamic_range, but now it is
not. This patch changes this code to preserve the name.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
In proc mi_expect_stop there's a proc argument reason that's handled like so:
...
set r "reason=\"$reason\","
...
That's fine for say:
...
set reason "foo"
...
for which this evaluates to:
...
set r "reason=\"foo\","
...
But there are more complex uses, for instance:
...
set reason "breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal"
...
which evaluates to:
...
set r "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\""
...
Note how in this reason argument, the first two '\"' seems to form a pair
surrounding ',disp=', which is not the case, which is confusing.
Fix this by only adding the quotes in mi_expect_stop if the string doesn't
already contain quotes, such that we have the more readable:
...
set reason "\"breakpoint-hit\",disp=\"keep\",bkptno=\"$decimal\""
...
Tested on x86_64-linux.
|
|
The copyright years in the ROCm files (e.g. solib-rocm.c) are wrong,
they end in 2022 instead of 2023. I suppose because I posted (or at
least prepared) the patches in 2022 but merged them in 2023, and forgot
to update the year. I found a bunch of other files that are in the same
situation. Fix them all up.
Change-Id: Ia55f5b563606c2ba6a89046f22bc0bf1c0ff2e10
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
A range type can usually be treated the same as its underlying integer
type, at least for the purposes of agent expressions. This patch
arranges for range types to be handled this way in ax-gdb.c, letting a
somewhat larger subset of Ada expressions be compiled.
|
|
Ada historically has not implemented agent expressions, and some Ada
constructs probably cannot reasonably be converted to agent
expressions. However, a subset of simple operations can be, and this
patch represents a first step in that direction.
On one internal AdaCore test case, this improves the performance of a
conditional breakpoint from 5 minutes to 5 seconds.
The main tricky part in this patch is ensuring the converted
expressions detect the cases that will not work. This is done by
examining the code in the corresponding evaluation methods.
|
|
A new guile test added in commit:
commit 0a9ccb9dd79384f3ba3f8cd75940e8868f3b526f
Date: Mon Feb 6 13:04:16 2023 +0000
gdb: only allow one of thread or task on breakpoints or watchpoints
fails for some versions of guile. It turns out that some versions of
guile emit an error like this:
(gdb) guile (set-breakpoint-thread! bp 1)
ERROR: In procedure set-breakpoint-thread!:
In procedure gdbscm_set_breakpoint_thread_x: cannot set both task and thread attributes
Error while executing Scheme code.
while other versions of guile emit the error like this:
(gdb) guile (set-breakpoint-thread! bp 1)
ERROR: In procedure set-breakpoint-thread!:
ERROR: In procedure gdbscm_set_breakpoint_thread_x: cannot set both task and thread attributes
Error while executing Scheme code.
notice the extra 'ERROR: ' on the second line of output. This commit
updates the test regexp to handle this optional 'ERROR: ' string.
|
