| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ Partial resubmission of an earlier submission by Andrew (
https://sourceware.org/pipermail/gdb-patches/2012-September/096347.html ), so
listing him as co-author. ]
With x86_64-linux and target board unix/-m32, we have:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
^M
Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
23 throw new int (e);^M
(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
The following scenario happens:
- set breakpoint in throw_exception_1, a function that throws an exception
- continue
- hit breakpoint, with call stack main.c:38 -> throw_exception_1
- set a finish breakpoint
- continue
- hit the breakpoint again, with call stack main.c:48 -> throw_exception
-> throw_exception_1
Due to the exception, the function call did not properly terminate, and the
finish breakpoint didn't trigger. This is expected behaviour.
However, the intention is that gdb detects this situation at the next stop
and calls the out_of_scope callback, which would result here in this test-case
in a rather confusing "exception did not finish" message. So the problem is
that this message doesn't show up, in other words, the out_of_scope callback
is not called.
[ Note that the fact that the situation is detected only at the next stop
(wherever that happens to be) could be improved upon, and the earlier
submission did that by setting a longjmp breakpoint. But I'm considering this
problem out-of-scope for this patch. ]
Note that the message does show up later, at thread exit:
...
[Inferior 1 (process 20046) exited with code 0236]^M
exception did not finish ...^M
...
The decision on whether to call the out_of_scope call back is taken in
bpfinishpy_detect_out_scope_cb, and the interesting bit is here:
...
if (b->pspace == current_inferior ()->pspace
&& (!target_has_registers ()
|| frame_find_by_id (b->frame_id) == NULL))
bpfinishpy_out_of_scope (finish_bp);
...
In the case of the thread exit, the callback triggers because
target_has_registers () == 0.
So why doesn't the callback trigger in the case of the breakpoint?
Well, the b->frame_id is the frame_id of the frame of main (the frame
in which the finish breakpoint is supposed to trigger), so AFAIU
frame_find_by_id (b->frame_id) == NULL will only be true once we've
left main, at which point I guess we don't stop till thread exit.
Fix this by saving the frame in which the finish breakpoint was created, and
using frame_find_by_id () == NULL on that frame instead, such that we have:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
^M
Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
23 throw new int (e);^M
exception did not finish ...^M
(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
Still, the test-case is failing because it's setup to match the behaviour that
we get on x86_64-linux with target board unix/-m64:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
stopped at ExceptionFinishBreakpoint^M
(gdb) PASS: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
So what happens here? Again, due to the exception, the function call did not
properly terminate, but the finish breakpoint still triggers. This is somewhat
unexpected. This happens because it just so happens to be that the frame
return address at which the breakpoint is set, is also the first instruction
after the exception has been handled. This is a know problem, filed as
PR29909, so KFAIL it, and modify the test-case to expect the out_of_scope
callback.
Also add a breakpoint after setting the finish breakpoint but before throwing
the exception, to check that we don't call the out_of_scope callback too early.
Tested on x86_64-linux, with target boards unix/-m32.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
PR python/27247
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27247
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On ubuntu 22.04.1 x86_64, I run into:
...
(gdb) PASS: gdb.base/print-symbol-loading.exp: shlib off: \
set print symbol-loading off
sharedlibrary .*^M
Symbols already loaded for /lib/x86_64-linux-gnu/libc.so.6^M
Symbols already loaded for /lib/x86_64-linux-gnu/libpthread.so.0^M
(gdb) FAIL: gdb.base/print-symbol-loading.exp: shlib off: load shared-lib
...
The test-case expects the libc.so line, but not the libpthread.so line.
However, we have:
...
$ ldd /lib/x86_64-linux-gnu/libc.so.6
linux-vdso.so.1 (0x00007ffd7f7e7000)
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x00007f4468c00000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4469193000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4468f3e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4468f39000)
...
so it's not unexpected that libpthread.so is loaded if libc.so is loaded.
Fix this by accepting the libpthread.so line.
Tested on x86_64-linux.
PR testsuite/29919
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29919
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gdb.threads/watchpoint-fork.exp
On Ubuntu 22.04.1 x86_64, with glibc 2.35 I run into:
...
watchpoint-fork-mt.c: In function 'start':^M
watchpoint-fork-mt.c:67:7: warning: 'pthread_yield' is deprecated: \
pthread_yield is deprecated, use sched_yield instead \
[-Wdeprecated-declarations]^M
67 | i = pthread_yield ();^M
| ^^M
...
Fix this as suggested, by using sched_yield instead.
Tested on x86_64-linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Ubuntu 22.04.1 x86_64 (with glibc 2.35), I run into:
...
(gdb) PASS: gdb.base/corefile.exp: $_exitcode is void
bt^M
#0 __pthread_kill_implementation (...) at ./nptl/pthread_kill.c:44^M
#1 __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
#2 __GI___pthread_kill (...) at ./nptl/pthread_kill.c:89^M
#3 0x00007f4985e1a476 in __GI_raise (...) at ../sysdeps/posix/raise.c:26^M
#4 0x00007f4985e007f3 in __GI_abort () at ./stdlib/abort.c:79^M
#5 0x0000556b4ea4b504 in func2 () at gdb.base/coremaker.c:153^M
#6 0x0000556b4ea4b516 in func1 () at gdb.base/coremaker.c:159^M
#7 0x0000556b4ea4b578 in main (...) at gdb.base/coremaker.c:171^M
(gdb) PASS: gdb.base/corefile.exp: backtrace
up^M
#1 __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
78 in ./nptl/pthread_kill.c^M
(gdb) FAIL: gdb.base/corefile.exp: up
...
The problem is that the regexp used here:
...
gdb_test "up" "#\[0-9\]* *\[0-9xa-fH'\]* in .* \\(.*\\).*" "up"
...
does not fit the __pthread_kill_internal line which lacks the instruction
address due to inlining.
Fix this by making the regexp less strict.
Tested on x86_64-linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On ubuntu 22.04.1 x86_64, I run into:
...
(gdb) info probes all rtld rtld_map_complete^M
No probes matched.^M
(gdb) XFAIL: gdb.threads/dlopen-libpthread.exp: info probes all rtld rtld_map_complete
UNTESTED: gdb.threads/dlopen-libpthread.exp: no matching probes
...
This has been filed as PR testsuite/17016.
The problem is that the name rtld_map_complete is used, which was only
available in Fedora 17, and upstream the name map_complete was used.
In the email thread discussing a proposed patch (
https://sourceware.org/legacy-ml/gdb-patches/2014-09/msg00712.html ) it was
suggested to make the test-case handle both names.
So, handle both names: map_complete and rtld_map_complete.
This exposes the following FAIL:
...
(gdb) info sharedlibrary^M
From To Syms Read Shared Object Library^M
$hex $hex Yes /lib64/ld-linux-x86-64.so.2^M
$hex $hex Yes (*) /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0^M
$hex $hex Yes /lib/x86_64-linux-gnu/libc.so.6^M
$hex $hex Yes /lib/x86_64-linux-gnu/libdl.so.2^M
$hex $hex Yes /lib/x86_64-linux-gnu/libpthread.so.0^M
(*): Shared library is missing debugging information.^M
(gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so not found
...
due to using a glibc (v2.35) that has libpthread integrated into libc.
Fix this by changing the FAIL into UNSUPPORTED.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17016
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fcf-protection
On Ubuntu 22.04.1 x86_64, I run into:
...
gdb.reverse/step-indirect-call-thunk.c: In function 'inc':^M
gdb.reverse/step-indirect-call-thunk.c:22:1: error: '-mindirect-branch' and \
'-fcf-protection' are not compatible^M
22 | { /* inc.1 */^M
| ^^M
...
Fix this by forcing -fcf-protection=none, if supported.
Tested on x86_64-linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Ubuntu 22.04.1 x86_64, I run into:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: not in inline 1
next^M
51 if (t != NULL^M
(gdb) FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 1
...
This is due to -fcf-protection, which adds the endbr64 at the start of get_alias_set:
...
0000000000001180 <_Z13get_alias_setP4tree>:
1180: f3 0f 1e fa endbr64
1184: 48 85 ff test %rdi,%rdi
...
so the extra insn gets an is-stmt line number entry:
...
INDEX LINE ADDRESS IS-STMT PROLOGUE-END
...
11 50 0x0000000000001180 Y
12 50 0x0000000000001180
13 51 0x0000000000001184 Y
14 54 0x0000000000001184
...
and when stepping into get_alias_set we step to line 50:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
step^M
get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:50^M
50 {^M
...
In contrast, with -fcf-protection=none, we get:
...
0000000000001170 <_Z13get_alias_setP4tree>:
1170: 48 85 ff test %rdi,%rdi
...
and:
...
INDEX LINE ADDRESS IS-STMT PROLOGUE-END
...
11 50 0x0000000000001170 Y
12 51 0x0000000000001170 Y
13 54 0x0000000000001170
...
so when stepping into get_alias_set we step to line 51:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
step^M
get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:51^M
51 if (t != NULL^M
...
Fix this by rewriting the gdb_test issuing the step command to check which
line the step lands on, and issuing an extra next if needed.
Tested on x86_64-linux, both with and without -fcf-protection=none.
PR testsuite/29920
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29920
|
|
|
|
|
| |
This patch fixes a review comment by Tom de Vries. He pointed out
that the new timestamp.exp should use the $decimal convenience regexp.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR cli/29945 points out that "set debug timestamp 1" stopped working
-- this is a regression due to commit b8043d27 ("Remove a ui-related
memory leak").
This patch fixes the bug and adds a regression test.
I think this should probably be backported to the gdb 13 branch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29945
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The gdb.gdb self-tests were timing out for me, which turned out to be
PR testsuite/29325. Looking into it, the problem is that the version
of the Boehm GC that is used by Guile on my machine causes a SEGV
during stack probing. This unexpected stop confuses the tests and
causes repeated timeouts.
This patch adapts the two failing tests. This makes them work for me,
and reduces the running time of gdb.gdb from 20 minutes to about 11
seconds.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29325
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In commit:
commit 9f50fe0835850645bd8ea9bb1efe1fe6c48dfb12
Date: Wed Dec 7 15:55:25 2022 +0000
gdb/testsuite: new test for recent dwarf reader issue
A new test (gdb.base/signed-builtin-types.exp) was added that made use
of 'info sources' to figure out if the debug information for a
particular object file had been fully expanded or not. Unfortunately
some lines of the 'info sources' output can be very long, this was
observed on some systems where the debug information for the
dynamic-linker was installed, in this case, the list of source files
associated with the dynamic linker was so long it would cause expect's
internal buffer to overflow.
This commit switches from using 'info sources' to 'maint print
objfile', the output from the latter command is more compact, but
also, can be restricted to a single named object file.
With this change in place I am no longer seeing buffer overflow errors
from expect when running gdb.base/signed-builtin-types.exp.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I see this fail since commit 991180627851 ("Use toplevel configure for
GMP and MPFR for gdb"):
FAIL: gdb.base/float128.exp: show configuration
The test fails to find --with-mpfr or --without-mpfr in the "show
configuration" output. Since MPFR has become mandatory, we can just
remove that check and simplify the test to assume MPFR support is there.
Change-Id: I4f3458470db0029705b390dfefed3a66dfc0633a
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When asking GDB to print a variable from an imported namespace, we only
want to see variables imported in lines that the inferior has already
gone through, as is being tested last in gdb.cp/nsusing.exp. However
with the proposed change to gdb.cp/nsusing.exp, we get the following
failures:
(gdb) PASS: gdb.cp/nsusing.exp: continue to breakpoint: marker10 stop
print x
$9 = 911
(gdb) FAIL: gdb.cp/nsusing.exp: print x, before using statement
next
15 y += x;
(gdb) PASS: gdb.cp/nsusing.exp: using namespace M
print x
$10 = 911
(gdb) PASS: gdb.cp/nsusing.exp: print x, only using M
Showing that the feature wasn't functioning properly, it just so
happened that gcc ordered the namespaces in a convenient way.
This happens because GDB doesn't take into account the line where the
"using namespace" directive is written. So long as it shows up in the
current scope, we assume it is valid.
To fix this, add a new member to struct using_direct, that stores the
line where the directive was written, and a new function that informs if
the using directive is valid already.
Unfortunately, due to a GCC bug, the failure still shows up. Compilers
that set the declaration line of the using directive correctly (such as
Clang) do not show such a bug, so the test includes an XFAIL for gcc
code.
Finally, because the final test of gdb.cp/nsusing.exp has turned into
multiple that all would need XFAILs for older GCCs (<= 4.3), and that
GCC is very old, if it is detected, the test just exits early.
Approved-by: Tom Tromey <tom@tromey.com>
|
|
|
|
|
|
|
|
| |
MI version 1 is long since obsolete. Several years ago, I filed
PR mi/23170 for this. I think it's finally time to remove this.
Any users of MI 1 can and should upgrade to a newer version.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23170
|
|
|
|
|
|
|
| |
I found a few vestiges of MI version 0 in the test suite. This patch
removes them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the GDB 13 branch has been created,
this commit bumps the version number in gdb/version.in to
14.0.50.DATE-git
For the record, the GDB 13 branch was created
from commit 71c90666e601c511a5f495827ca9ba545e4cb463.
Also, as a result of the version bump, the following changes
have been made in gdb/testsuite:
* gdb.base/default.exp: Change $_gdb_major to 14.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Once in a while I run into:
...
FAIL: gdb.threads/detach-step-over.exp: \
breakpoint-condition-evaluation=host: target-non-stop=off: non-stop=off: \
displaced=off: iter 1: all threads running
...
In can easily reproduce this by doing:
...
# Wait a bit, to give time for the threads to hit the
# breakpoint.
- sleep 1
return true
...
Fix this by counting the running threads in a loop, effectively allowing 10
seconds (instead of 1) for the threads to start running, but only sleeping if
needed.
Reduces total execution time from 1m27s to 56s.
Tested on x86_64-linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the source program contains a goto label, it turns out it's
actually pretty hard for a user to find out more about that label.
For example:
(gdb) p some_label
No symbol "some_label" in current context.
(gdb) disassemble some_label
No symbol "some_label" in current context.
(gdb) x/10i some_label
No symbol "some_label" in current context.
(gdb) break some_label
Breakpoint 2 at 0x401135: file /tmp/py-label-symbol-value.c, line 35.
In all cases, some_label is a goto label within the current frame.
Only placing a breakpoint on the label worked.
This all seems a little strange to me, it feels like asking about a
goto label would not be an unreasonable thing for a user to do.
This commit doesn't fix any of the above issues, I mention them just
to provide a little context for why the following issue has probably
not been seen before.
It turns out there is one way a user can access the symbol for a goto
label, through the Python API:
python frame = gdb.selected_frame()
python frame_pc = frame.pc()
python block = gdb.current_progspace().block_for_pc(frame_pc)
python symbol,_ = gdb.lookup_symbol('some_label', block, gdb.SYMBOL_LABEL_DOMAIN)
python print(str(symbol.value()))
../../src/gdb/findvar.c:204: internal-error: store_typed_address: Assertion `type->is_pointer_or_reference ()' failed.
The problem is that label symbols are created using the
builtin_core_addr type, which is a pure integer type.
When GDB tries to fetch the value of a label symbol then we end up in
findvar.c, in the function language_defn::read_var_value, in the
LOC_LABEL case. From here store_typed_address is called to store the
address of the label into a value object with builtin_core_addr type.
The problem is that store_typed_address requires that the destination
type be a pointer or reference, which the builtin_core_addr type is
not.
Now it's not clear what type a goto label address should have, but
GCC has an extension that allows users to take the address of a goto
label (using &&), in that case the result is of type 'void *'.
I propose that when we convert the CORE_ADDR value to a GDB value
object, we use builtin_func_ptr type instead of builtin_core_addr,
this means the result will be of type 'void (*) ()'. The benefit of
this approach is that when gdbarch_address_to_pointer is called the
target type will be correctly identified as a pointer to code, which
should mean any architecture specific adjustments are done correctly.
We can then cast the new value to 'void *' type with a call to
value_cast_pointer, this should not change the values bit
representation, but will just update the type.
After this asking for the value of a label symbol works just fine:
(gdb) python print(str(symbol.value()))
0x401135 <main+35>
And the type is maybe what we'd expect:
(gdb) python print(str(symbol.value().type))
void *
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a test that creates a Python command that redefines
itself during its execution. This is to test use-after-free in
execute_command ().
This test needs run with ASan enabled in order to fail when it
should.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR gdb/28947
The address_significant gdbarch setting was introduced as a way to remove
non-address bits from pointers, and it is specified by a constant. This
constant represents the number of address bits in a pointer.
Right now AArch64 is the only architecture that uses it, and 56 was a
correct option so far.
But if we are using Pointer Authentication (PAuth), we might use up to 2 bytes
from the address space to store the required information. We could also have
cases where we're using both PAuth and MTE.
We could adjust the constant to 48 to cover those cases, but this doesn't
cover the case where GDB needs to sign-extend kernel addresses after removal
of the non-address bits.
This has worked so far because bit 55 is used to select between kernel-space
and user-space addresses. But trying to clear a range of bits crossing the
bit 55 boundary requires the hook to be smarter.
The following patch renames the gdbarch hook from significant_addr_bit to
remove_non_address_bits and passes a pointer as opposed to the number of
bits. The hook is now responsible for removing the required non-address bits
and sign-extending the address if needed.
While at it, make GDB and GDBServer share some more code for aarch64 and add a
new arch-specific testcase gdb.arch/aarch64-non-address-bits.exp.
Bug-url: https://sourceware.org/bugzilla/show_bug.cgi?id=28947
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
|
|
|
|
|
|
| |
Don't delete the runtime-generated command files. This makes it easier
to reproduce tests by hand.
Change-Id: I4e53484eea216512f1c5d7dfcb5c464b36950946
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With gcc 4.8.5, I run into:
...
Running gdb.base/condbreak-multi-context.exp ...
gdb compile failed, condbreak-multi-context.cc:21:11: warning: non-static \
data member initializers only available with -std=c++11 or -std=gnu++11 \
[enabled by default]
int b = 20;
^
...
Fix this by making it a static const.
Tested on x86_64-linux, with gcc 4.8.5, 7.5.0 and clang 13.0.1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit changes the target_stack class from using a C style array
of 'target_ops *' to using a C++ std::array<target_ops_ref, ...>. The
benefit of this change is that some of the reference counting of
target_ops objects is now done automatically.
This commit fixes a crash in gdb.python/py-inferior.exp where GDB
crashes at exit, leaving a core file behind.
The crash occurs in connpy_connection_dealloc, and is actually
triggered by this assert:
gdb_assert (conn_obj->target == nullptr);
Now a little aside...
... the assert is never actually printed, instead GDB crashes due
to calling a pure virtual function. The backtrace at the point of
crash looks like this:
#7 0x00007fef7e2cf747 in std::terminate() () from /lib64/libstdc++.so.6
#8 0x00007fef7e2d0515 in __cxa_pure_virtual () from /lib64/libstdc++.so.6
#9 0x0000000000de334d in target_stack::find_beneath (this=0x4934d78, t=0x2bda270 <the_dummy_target>) at ../../s>
#10 0x0000000000df4380 in inferior::find_target_beneath (this=0x4934b50, t=0x2bda270 <the_dummy_target>) at ../.>
#11 0x0000000000de2381 in target_ops::beneath (this=0x2bda270 <the_dummy_target>) at ../../src/gdb/target.c:3047
#12 0x0000000000de68aa in target_ops::supports_terminal_ours (this=0x2bda270 <the_dummy_target>) at ../../src/gd>
#13 0x0000000000dde6b9 in target_supports_terminal_ours () at ../../src/gdb/target.c:1112
#14 0x0000000000ee55f1 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_li>
Notice in frame #12 we called target_ops::supports_terminal_ours,
however, this is the_dummy_target, which is of type dummy_target,
and so we should have called dummy_target::supports_terminal_ours.
I believe the reason we ended up in the wrong implementation of
supports_terminal_ours (which is a virtual function) is because we
made the call during GDB's shut-down, and, I suspect, the vtables
were in a weird state.
Anyway, the point of this patch is not to fix GDB's ability to
print an assert during exit, but to address the root cause of the
assert. With that aside out of the way, we can return to the main
story...
Connections are represented in Python with gdb.TargetConnection
objects (or its sub-classes). The assert in question confirms that
when a gdb.TargetConnection is deallocated, the underlying GDB
connection has itself been removed from GDB. If this is not true then
we risk creating multiple different gdb.TargetConnection objects for
the same connection, which would be bad.
To ensure that we have one gdb.TargetConnection object for each
connection, the all_connection_objects map exists, this maps the
process_stratum_target object (the connection) to the
gdb.TargetConnection object that represents the connection.
When a connection is removed in GDB the connection_removed observer
fires, which we catch with connpy_connection_removed, this function
then sets conn_obj->target to nullptr, and removes the corresponding
entry from the all_connection_objects map.
The first issue here is that connpy_connection_dealloc is being called
as part of GDB's exit code, which is run after the Python interpreter
has been shut down. The connpy_connection_dealloc function is used to
deallocate the gdb.TargetConnection Python object. Surely it is
wrong for us to be deallocating Python objects after the interpreter
has been shut down.
The reason why connpy_connection_dealloc is called during GDB's exit
is that the global all_connection_objects map is still holding a
reference to the gdb.TargetConnection object. When the map is
destroyed during GDB's exit, the gdb.TargetConnection objects within
the map can finally be deallocated.
The reason why all_connection_objects has contents when GDB exits, and
the reason the assert fires, is that, when GDB exits, there are still
some connections that have not yet been removed from GDB, that is,
they have a non-zero reference count.
If we take a look at quit_force (top.c) you can see that, for each
inferior, we call pop_all_targets before we (later in the function)
call do_final_cleanups. It is the do_final_cleanups call that is
responsible for shutting down the Python interpreter. The
pop_all_targets calls should, in theory, cause all the connections to
be removed from GDB.
That this isn't working indicates that some targets have a non-zero
reference count even after this final pop_all_targets call, and
indeed, when I debug GDB, that is what I see.
I tracked the problem down to delete_inferior where we do some house
keeping, and then delete the inferior object, which calls
inferior::~inferior.
In neither delete_inferior or inferior::~inferior do we call
pop_all_targets, and it is this missing call that means we leak some
references to the target_ops objects on the inferior's target_stack.
In this commit I will provide a partial fix for the problem. I say
partial fix, but this will actually be enough to resolve the crash.
In a later commit I will provide the final part of the fix.
As mentioned at the start of the commit message, this commit changes
the m_stack in target_stack to hold target_ops_ref objects. This
means that when inferior::~inferior is called, and m_stack is
released, we automatically decrement the target_ops reference count.
With this change in place we no longer leak any references, and now,
in quit_force the final pop_all_targets calls will release the final
references. This means that the targets will be correctly closed at
this point, which means the connections will be removed from GDB and
the Python objects deallocated before the Python interpreter shuts
down.
There's a slight oddity in target_stack::unpush, where we std::move
the reference out of m_stack like this:
auto ref = std::move (m_stack[stratum]);
the `ref' isn't used explicitly, but it serves to hold the
target_ops_ref until the end of the scope while allowing the m_stack
entry to be reset back to nullptr. The alternative would be to
directly set the m_stack entry to nullptr, like this:
m_stack[stratum] = nullptr;
The problem here is that when we set the m_stack entry to nullptr we
first decrement the target_ops reference count, and then set the array
entry to nullptr.
If the decrement means that the target_ops object reaches a zero
reference count then the target_ops object will be closed by calling
target_close. In target_close we ensure that the target being closed
is not in any inferiors target_stack.
As we decrement before clearing, then this check in target_close will
fail, and an assert will trigger.
By using std::move to move the reference out of m_stack, this clears
the m_stack entry, meaning the inferior no longer contains the
target_ops in its target_stack. Now when the REF object goes out of
scope and the reference count is decremented, target_close can run
successfully.
I've made use of the Python connection_removed listener API to add a
test for this issue. The test installs a listener and then causes
delete_inferior to be called, we can then see that the connection is
then correctly removed (because the listener triggers).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit provides a test for this commit:
commit 55fc1623f942fba10362cb199f9356d75ca5835b
Date: Thu Nov 3 13:49:17 2022 -0600
Add name canonicalization for C
Which resolves PR gdb/29105. My reason for writing this test was a
desire to better understand the above commit, my process was to study
the commit until I thought I understood it, then write a test to
expose the issue. As the original commit didn't have a test, I
thought it wouldn't hurt to commit this upstream.
The problem tested for here is already described in the above commit,
but I'll give a brief description here. This description describes
GDB prior to the above commit:
- Builtin types are added to GDB using their canonical name,
e.g. "short", not "signed short",
- When the user does something like 'p sizeof(short)', then this is
handled in c-exp.y, and results in a call to lookup_signed_type
for the name "int". The "int" here is actually being looked up as
the type for the result of the 'sizeof' expression,
- In lookup_signed_type GDB first adds a 'signed' and looks for that
type, so in this case 'signed int', and, if that lookup fails, GDB
then looks up 'int',
- The problem is that 'signed int' is not the canonical name for a
signed int, so no builtin type with that name will be found, GDB
will then go to each object file in turn looking for a matching
type,
- When checking each object file, GDB will first check the partial
symtab to see if the full symtab should be expanded or not.
Remember, at this point GDB is looking for 'signed int', there
will be no partial symbols with that name, so GDB will not expand
anything,
- However, GDB checks each partial symbol using multiple languages,
not just the current language (C in this case), so, when GDB
checks using the C++ language, the symbol name is first
canonicalized (the code that does this can be found
lookup_name_info::language_lookup_name). As the canonical form of
'signed int' is just 'int', GDB then looks for any symbols with
the name 'int', most partial symtabs will contain such a symbol,
so GDB ends up expanding pretty much every symtab.
The above commit fixes this by avoiding the use of non-canonical names
with C, now the initial builtin type lookup will succeed, and GDB
never even considers whether to expand any additional symtabs.
The test case creates a library that includes char, short, int, and
long types, and a test program that links against the library.
In the test script we start the inferior, but don't allow it to
progress far enough that the debug information for the library has
been fully expanded yet.
Then we evaluate some 'sizeof(TYPE)' expressions.
In the buggy version of GDB this would cause the debug information
for the library to be fully expanded, while in the fixed version of
GDB this will not be the case.
We use 'info sources' to determine if the debug information has been
fully expanded or not.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following commit broke the readnow detection in the testsuite:
commit dfaa040b440084dd73ebd359326752d5f44fc02c
Date: Mon Mar 29 18:31:31 2021 -0600
Remove some "OBJF_READNOW" code from dwarf2_debug_names_index
The testsuite checks if GDB was started with the -readnow flag by
using the 'maintenance print objfiles' command, and looking for the
string 'faked for "readnow"' in the output. This is implemented in
two helper procs `readnow` (gdb.exp) and `mi_readnow` (mi-support.exp).
The following tests all currently depend on this detection:
gdb.base/maint.exp
gdb.cp/nsalias.exp
gdb.dwarf2/debug-aranges-duplicate-offset-warning.exp
gdb.dwarf2/dw2-stack-boundary.exp
gdb.dwarf2/dw2-zero-range.exp
gdb.dwarf2/gdb-index-nodebug.exp
gdb.mi/mi-info-sources.exp
gdb.python/py-symbol.exp
gdb.rust/traits.exp
The following test also includes detection of 'readnow', but does the
detection itself by checking $::GDBFLAGS for the readnow flag:
gdb.opt/break-on-_exit.exp
The above commit removed from GDB the code that produced the 'faked
for "readnow"' string, as a consequence the testsuite can no longer
correctly spot when readnow is in use, and many of the above tests
will fail (at least partially).
When looking at the above tests, I noticed that gdb.rust/traits.exp
does call `readnow`, but doesn't actually use the result, so I've
removed the readnow call, this simplifies the next part of this patch
as gdb.rust/traits.exp was the only place an extra regexp was passed
to the readnow call.
Next I have rewritten `readnow` to check the $GDBFLAGS for the
-readnow flag, and removed the `maintenance print objfiles` check. At
least for all the tests above, when using the readnow board, this is
good enough to get everything passing again.
For the `mi_readnow` proc, I changed this to just call `readnow` from
gdb.exp, I left the mi_readnow name in place - in the future it might
be the case that we want to do some different checks here.
Finally, I updated gdb.opt/break-on-_exit.exp to call the `readnow`
proc.
With these changes, all of the tests listed above now pass correctly
when using the readnow board.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After this commit:
commit 33c1395cf5e9deec7733691ba32c450e5c27f757
Date: Fri Nov 11 15:26:46 2022 +0000
gdb/testsuite: fix gdb.trace/unavailable-dwarf-piece.exp with Clang
The gdb.trace/unavailable-dwarf-piece.exp test script was creating a
temporary file in the build/gdb/testsuite/ directory, instead of in
the expected place in the outputs directory.
Fix this by adding a call to standard_output_file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On s390x-linux, I run into:
...
(gdb) disassemble test^M
Dump of assembler code for function test:^M
0x0000000001000638 <+0>: stg %r11,88(%r15)^M
0x000000000100063e <+6>: lgr %r11,%r15^M
0x0000000001000642 <+10>: nop 0^M
=> 0x0000000001000646 <+14>: nop 0^M
0x000000000100064a <+18>: nop 0^M
0x000000000100064e <+22>: lhi %r1,0^M
0x0000000001000652 <+26>: lgfr %r1,%r1^M
0x0000000001000656 <+30>: lgr %r2,%r1^M
0x000000000100065a <+34>: lg %r11,88(%r11)^M
0x0000000001000660 <+40>: br %r14^M
End of assembler dump.^M
(gdb) FAIL: gdb.python/py-disasm.exp: global_disassembler=: disassemble test
...
The problem is that the test-case expects "nop" but on s390x we have instead
"nop\t0".
Fix this by allowing the insn.
Tested on s390x-linux and x86_64-linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is_nocall_function anticipates only being called for a function or a
method. However, PR gdb/29871 points out a situation where an unusual
expression -- but one that parses to a valid, if extremely weird,
function call -- breaks this assumption.
This patch changes is_nocall_function to remove this assert and
instead simply return 'false' in this case.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29871
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On s390x-linux, I run into:
...
(gdb) print {unsigned char}{65}^M
$749 = 0 '\000'^M
(gdb) FAIL: gdb.base/printcmds.exp: print {unsigned char}{65}
...
In contrast, on x86_64-linux, we have:
...
(gdb) print {unsigned char}{65}^M
$749 = 65 'A'^M
(gdb) PASS: gdb.base/printcmds.exp: print {unsigned char}{65}
...
The first problem here is that the test is supposed to be a regression test
for PR20630, which can be reproduced (for an unfixed gdb) like this:
...
(gdb) p {unsigned char[]}{0x17}
gdbtypes.c:4641: internal-error: copy_type: \
Assertion `TYPE_OBJFILE_OWNED (type)' failed.
...
but it's not due to insufficient quoting (note the dropped '[]').
That's easy to fix, but after that we have on s390 (big endian):
...
(gdb) print {unsigned char[]}{65}^M
$749 = ""^M
...
and on x86_64 (little endian):
...
(gdb) print {unsigned char[]}{65}^M
$749 = "A"^M
...
Fix this by using 0xffffffff, such that in both cases we have:
...
(gdb) print {unsigned char[]}{0xffffffff}^M
$749 = "\377\377\377\377"^M
...
Tested on x86_64-linux and s390x-linux.
|
|
|
|
|
|
|
|
|
|
|
|
| |
My earlier patch to fix PR rust/29859 introduced a new operator
precedence bug in the Rust parser. Assignment operators are
right-associative in Rust. And, while this doesn't often matter, as
Rust assignments always have the value (), still as a matter of
principle we should get this correct.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On s390x-linux (big endian), I run into:
...
(gdb) x /xh main^M
0x1000638 <main>: 0x0000^M
(gdb) FAIL: gdb.base/write_mem.exp: x /xh main
...
In contrast, on x86_64-linux (little endian), we have the expected:
...
(gdb) x /xh main^M
0x4004a7 <main>: 0x4242^M
(gdb) PASS: gdb.base/write_mem.exp: x /xh main
...
The problem is that the test-case hard-codes expectations about endiannes by
writing an int-sized value (4 bytes in this case) and then printing only a
halfword by using "/h" (so, two bytes).
If we print 4 bytes, we have for s390x:
...
0x1000638 <main>: 0x00004242^M
...
and for x86_64:
...
0x4004a7 <main>: 0x00004242^M
...
Fix this by removing the "/h".
Tested on x86_64-linux and s390x-linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.guile/scm-symtab.exp: step out of func2
guile (print (> (sal-line (find-pc-line (frame-pc (selected-frame)))) line))^M
= #f^M
(gdb) FAIL: gdb.guile/scm-symtab.exp: test find-pc-line with resume address
...
The problem is as follows: the instructions for the call to func2 are:
...
1000070c: 39 00 00 48 bl 10000744 <func1>
10000710: 00 00 00 60 nop
10000714: 59 00 00 48 bl 1000076c <func2>
10000718: 00 00 00 60 nop
1000071c: 00 00 20 39 li r9,0
...
and the corresponding line number info is:
...
scm-symtab.c:
File name Line number Starting address View Stmt
scm-symtab.c 42 0x1000070c x
scm-symtab.c 43 0x10000714 x
scm-symtab.c 44 0x1000071c x
...
The test-case looks at the line numbers for two insns:
- the insn of the call to func2 (0x10000714), and
- the insn after that (0x10000718),
and expects the line number of the latter to be greater than the line number
of the former.
However, both insns have the same line number: 43.
Fix this by replacing ">" with ">=".
Tested on x86_64-linux and powerpc64le-linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running test-case gdb.tui/tui-layout-asm-short-prog.exp on SLE-12-SP3
aarch64, I run into:
...
FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents
FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents again
...
due to:
...
(gdb) file tui-layout-asm-short-prog^M
Reading symbols from tui-layout-asm-short-prog...^M
(No debugging symbols found in tui-layout-asm-short-prog)^M
...
I managed to reproduce the same behaviour on openSUSE Leap 15.4 x86_64, by
removing the debug option.
Fix this by making the test-case unsupported if no debug info is found.
Tested on x86_64-linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building GDB with the following CFLAGS and CXXFLAGS as part of
configure line:
CFLAGS=-std=gnu11 CXXFLAGS=-std=gnu++11
Then run the selftest.exp, I see:
======
Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp
...
FAIL: gdb.gdb/selftest.exp: run until breakpoint at captured_main
WARNING: Couldn't test self
=== gdb Summary ===
# of unexpected failures 1
/home/lee/dev/binutils-gdb/gdb/gdb version 13.0.50.20221206-git -nw -nx
-iex "set height 0" -iex "set width 0" -data-directory
/home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory
======
It is the fact that when I use the previously mentioned CFLAGS and
CXXFLAGS as part of the configuration line, the default value (-O2 -g)
is overridden, then GDB has no debug information. When there's no debug
information, GDB should not run the testcase in selftest.exp.
The root cause of this FAIL is that the $gdb_file_cmd_debug_info didn't
get the right value ("nodebug") during the gdb_file_cmd procedure.
That's because in this commit,
commit 3453e7e409f44a79ac6695589836edb8a49bfb08
Date: Sat May 19 11:25:20 2018 -0600
Clean up "Reading symbols" output
It changed "no debugging..." to "No debugging..." which causes the above
problem. This patch only updates the corresponding pattern to fix this
issue.
With this patch applied, I see:
======
Running /home/lee/dev/binutils-gdb/gdb/testsuite/gdb.gdb/selftest.exp
...
=== gdb Summary ===
# of untested testcases 1
/home/lee/dev/binutils-gdb/gdb/gdb version 13.0.50.20221206-git -nw -nx
-iex "set height 0" -iex "set width 0" -data-directory
/home/lee/dev/binutils-gdb/gdb/testsuite/../data-directory
======
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While playing with JIT reader I experienced GDB to crash on null-pointer
dereference when stepping through non-jitted code.
The problem was that dwarf2_frame_find_fde () assumed that all objfiles
have BFD but that's not always true. To address this problem, this
commit skips such objfiles.
To test the fix we put breakpoint in jit_function_add (). The JIT reader
does not know how unwind this function so unwinding eventually falls
back to DWARF unwinder which in turn iterates over objfiles. Since the
the code is jitted, it is guaranteed it would eventually process JIT
objfile.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
|
|
|
|
|
|
|
|
| |
Add KFAILs in test-case gdb.base/longjmp.exp for PR gdb/26967, covering
various ways that gdb is unable to recover the longjmp target if the libc
probe is not supported.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
|
|
|
| |
PR rust/29859 points out an operator precedence bug in the Rust
parser. This patch fixes it and adds a regression test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running test-case gdb.base/longjmp.exp, we have:
...
PASS: gdb.base/longjmp.exp: next over setjmp (1)
...
PASS: gdb.base/longjmp.exp: next over setjmp (2)
...
The trailing " (1)" and " (2)" are interpreted as comments rather than parts
of the test name, and therefore this is a duplicate, which is currently not
detected by our duplicate detection mechanism (PR testsuite/29772).
Fix the duplicate by using with_test_prefix.
Tested on x86_64-linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running test-case gdb.base/longjmp.exp on x86_64-linux, the master
longjmp breakpoint is set using probes and the test-case passes:
...
(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next^M
0x00000000004005cc 49 if (setjmp (env) == 0) /* patt1 */^M
(gdb) PASS: gdb.base/longjmp.exp: next over longjmp(1)
next^M
56 resumes++;^M
(gdb) PASS: gdb.base/longjmp.exp: next into else block (1)
...
However, if I disable
create_longjmp_master_breakpoint_probe, we have instead:
...
(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next^M
56 resumes++;^M
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)
...
At first glance, the failure mode doesn't look too bad: we stop
a few insns later than the passing scenario.
For contrast, if we do the same on powerpc64le, the failure mode is:
...
(gdb) PASS: gdb.base/longjmp.exp: next to longjmp (1)
next^M
^M
Breakpoint 3, main () at longjmp.c:59^M
59 i = 1; /* miss_step_1 */^M
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)
...
Here we only stop because of running into the safety net breakpoint at
miss_step_1.
So, how does this happen on x86_64? Let's look at the code:
...
4005c7: e8 94 fe ff ff call 400460 <_setjmp@plt>
4005cc: 85 c0 test %eax,%eax
4005ce: 75 1e jne 4005ee <main+0x3b>
4005d0: 8b 05 8e 0a 20 00 mov 0x200a8e(%rip),%eax # 601064 <longjmps>
4005d6: 83 c0 01 add $0x1,%eax
4005d9: 89 05 85 0a 20 00 mov %eax,0x200a85(%rip) # 601064 <longjmps>
4005df: be 01 00 00 00 mov $0x1,%esi
4005e4: bf 80 10 60 00 mov $0x601080,%edi
4005e9: e8 82 fe ff ff call 400470 <longjmp@plt>
4005ee: 8b 05 74 0a 20 00 mov 0x200a74(%rip),%eax # 601068 <resumes>
...
The next over the longjmp call at 4005e9 is supposed to stop at the longjmp
target at 4005cc, but instead we stop at 4005ee, where we have the step-resume
breakpoint inserted by the next. In other words, we accidentally "return"
from the longjmp call to the insn immediately after it (even though
a longjmp is a noreturn function).
Try to avoid this accident and make the failure mode on x86_64 the same as on
powerpc64le, by switching the then and else branch.
Tested on x86_64-linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed that when running these two tests in sequence:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ...
ERROR: GDB process no longer exists
ERROR: Couldn't run foo-all
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ...
The results in gdb.sum are:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/arrayptr.exp ...
PASS: gdb.ada/arrayptr.exp: scenario=all: compilation foo.adb
ERROR: GDB process no longer exists
UNRESOLVED: gdb.ada/arrayptr.exp: scenario=all: gdb_breakpoint: set breakpoint at foo.adb:40 (eof)
ERROR: Couldn't run foo-all
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.ada/assign_1.exp ...
UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada
PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1
The UNRESOLVED for arrayptr.exp is fine, as GDB crashes in that test,
while trying to run to main. However, the UNRESOLVED in assign_1.exp
doesn't make sense, GDB behaves as expected in that test:
(gdb) set lang ada^M
(gdb) UNRESOLVED: gdb.ada/assign_1.exp: changing the language to ada
print $xxx := 1^M
$1 = 1^M
(gdb) PASS: gdb.ada/assign_1.exp: set convenience variable $xxx to 1
The problem is that arrayptr.exp calls perror when failing to run to
main, then returns. perror makes it so that the next test (as in
pass/fail) will be recorded as UNRESOLVED. However, here, the next test
(as in pass/fail) is in the next test (as in .exp). Hence the spurious
UNRESOLVED in assign_1.exp.
These perror when failing to run to X are not really useful, especially
since runto records a FAIL on error, by default. Remove all the
perrors on runto failure I could find.
When there wasn't one already, add a return statement when failing to
run, to avoid running the test of the test unnecessarily.
I thought of adding a check ran between test (in gdb_finish
probably) where we would emit a warning if errcnt > 0, meaning a test
quit and left a perror "active". However, reading that variable would
poke into the DejaGNU internals, not sure it's a good idea.
Change-Id: I2203df6d06e199540b36f56470d1c5f1dc988f7b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent commit 32a5aa26256 ("[gdb/testsuite] Fix gdb.ada/float-bits.exp
for powerpc64le") started using command "maint print architecture", which
produces ~275 lines.
Rewrite the corresponding gdb_test_multiple to read line-by-line, to prevent
timeouts on slower test setups.
Note that this doesn't fix a timeout in the test-case on aarch64 due to:
...
gdbarch_dump: read_core_file_mappings = <0x817438>
(gdb) aarch64_dump_tdep: Lowest pc = 0x0x8000
...
Tested on x86_64-linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gdb.reverse/next-reverse-bkpt-over-sr.exp
The tests set a break point with the command break *func. This sets a
breakpoint on the first instruction of the function. PowerPC uses
Global Entry Points (GEP) and Local Entry Points (LEP). The first
instruction in the function is the GEP. The GEP sets up register
r2 before reaching the LEP. When the function is called with func() the
function is entered via the LEP and the test fails because GDB does not
see the breakpoint on the GEP. However, if the function is called via a
function pointer, execution begins at the GEP as the test expects.
Currently finish-reverse-bkpt.exp uses source file finish-reverse.c and
next-reverse-bpkt-over-sr.exp uses source file step-reverse.c A new
source file was created for tests finish-reverse-bkpt.exp and
next-reverse-bkpt-over-sr.exp. The new files use the new function
pointer method to call the functions so the tests will work correctly on
both PowerPC with a GEP and LEP as well as on other systems. The GEP is
the same as the LEP on non PowerPC systems.
The expect files were changed to use the new source files and to set the
initial break point for the rest of the test on the function pointer call
for the function.
This patch fixes two PowerPC test failures in each of the tests
gdb.reverse/finish-reverse-bkpt.exp and
gdb.reverse/next-reverse-bkpt-over-sr.exp.
Patch tested on PowerPC and Intel X86-64 with no regressions.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR symtab/29105 shows a number of situations where symbol lookup can
result in the expansion of too many CUs.
What happens is that lookup_signed_typename will try to look up a type
like "signed int". In cooked_index_functions::expand_symtabs_matching,
when looping over languages, the C++ case will canonicalize this type
name to be "int" instead. Then this method will proceed to expand
every CU that has an entry for "int" -- i.e., nearly all of them. A
crucial component of this is that the caller, objfile::lookup_symbol,
does not do this canonicalization, so when it tries to find the symbol
for "signed int", it fails -- causing the loop to continue.
This patch fixes the problem by introducing name canonicalization for
C. The idea here is that, by making C and C++ agree on the canonical
name when a symbol name can have multiple spellings, we avoid the bad
behavior in objfile::lookup_symbol (and any other such code -- I don't
know if there is any).
Unlike C++, C only has a few situations where canonicalization is
needed. And, in particular, due to the lack of overloading (thus
avoiding any issues in linespec) and due to the way c-exp.y works, I
think that no canonicalization is needed during symbol lookup -- only
during symtab construction. This explains why lookup_name_info is not
touched.
The stabs reader is modified on a "best effort" basis.
The DWARF reader needed one small tweak in dwarf2_name to avoid a
regression in dw2-unusual-field-names.exp. I think this is adequately
explained by the comment, but basically this is a scenario that should
not occur in real code, only the gdb test suite.
lookup_signed_typename is simplified. It used to search for two
different type names, but now gdb can search just for the canonical
form.
gdb.dwarf2/enum-type.exp needed a small tweak, because the
canonicalizer turns "unsigned integer" into "unsigned int integer".
It seems better here to use the correct C type name.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
Tested-by: Simon Marchi <simark@simark.ca>
Reviewed-by: Andrew Burgess <aburgess@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR compile/29541 points out that some of the C++ tests in gdb.compile
will time out when the glibc debuginfo is installed. This was
interfering with my hacking on gdb by making test runs extremely long,
so I looked into it.
Internally the bug seems to be that gdb tries to convert multiple
symbols named "var" via the compiler interface; one such symbol (I
didn't track it down too far) causes the C++ compiler plugin to crash.
Unfortunately, the crash is reported as a timeout, as the gdb side of
the plugin simply hangs. This seems like a bug in the plugin RPC
mechanism and, worse, apparently when I wrote this stuff I didn't
really consider error reporting very much at all, so gdb can't really
detect failures in the first place.
Anyway... this patch works around the timeout by compiling a simple
test that should provoke this bug, and then using "untested" if it
notices a GCC crash.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29541
|
|
|
|
|
|
|
|
|
| |
skip_compile_feature_tests checks for "Command not supported on this
host", but this error was removed by commit e8d8cce6 ("Import mkdtemp
gnulib module, fix mingw build"). This patch removes the obsolete
test.
|
|
|
|
|
|
|
|
| |
I noticed that there are two identical copies of
skip_compile_feature_tests in the test suite. This removes one from
gdb.exp, in favor of the one in compile-support.exp.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When I run the gdb testsuite on a powerpc64le-linux system with (slow) nfs
file system, I run into timeouts due to core generation, like for instance:
...
(gdb) gcore $outputs/gdb.ada/task_switch_in_core/crash.gcore^M
FAIL: gdb.ada/task_switch_in_core.exp: save a corefile (timeout)
...
Fix this by using with_timeout_factor 3 in gdb_gcore_cmd.
Tested on powerpc64le-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On powerpc64le-linux, I run into:
...
(gdb) print 16llf#4000921fb54442d18469898cc51701b8#^M
$9 = <invalid float value>^M
(gdb) FAIL: gdb.ada/float-bits.exp: print \
16llf#4000921fb54442d18469898cc51701b8#
...
The problem is that we're using a hex string for the 128-bit IEEE quad long
double format, but the actual long double float format is:
...
gdbarch_dump: long_double_format = floatformat_ibm_long_double_little^M
...
Fix this by using the hex string obtained by compiling test.c:
...
long double a = 5.0e+25L;
...
like so:
...
$ gcc -mlittle test.c -c -g
...
and running gdb:
...
$ gdb -q -batch test.o -ex "p /x a"
$1 = 0xc1e1c000000000004544adf4b7320335
...
and likewise for -mbig:
...
$ gdb -q -batch test.o -ex "p /x a"
$1 = 0x4544adf4b7320335c1e1c00000000000
...
Tested on powerpc64le-linux.
I excercised the case of floatformat_ibm_long_double_big by
using "set endian big" in the test-case.
Note that for this patch to work correctly, recent commit aaa79cd62b8 ("[gdb]
Improve printing of float formats") is required.
PR testsuite/29816
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29816
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On s390x-linux, I run into:
...
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
...
Fix this by using with_test_prefix.
Tested on s390x-linux.
|