| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In principle, `execute_command()` does following:
struct cmd_list_element *c;
c = lookup_cmd ( ... );
...
/* If this command has been pre-hooked, run the hook first. */
execute_cmd_pre_hook (c);
...
/* ...execute the command `c` ...*/
...
execute_cmd_post_hook (c);
This may lead into use-after-free error. Imagine the command
being executed is a user-defined Python command that redefines
itself. In that case, struct `cmd_list_element` pointed to by
`c` is deallocated during its execution so it is no longer valid
when post hook is executed.
To fix this case, this commit looks up the command once again
after it is executed to get pointer to (possibly newly allocated)
`cmd_list_element`.
|
|
On s390x-linux with target board unix/-m31, I run into:
...
(gdb) PASS: gdb.guile/scm-lazy-string.exp: bad length
print ptr^M
$1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0>^M
(gdb) FAIL: gdb.guile/scm-lazy-string.exp: ptr: print ptr
...
A minimal example is:
...
$ gdb -q -batch -ex "set trace-commands on" -x gdb.in
+file scm-lazy-string
+break main
Breakpoint 1 at 0x4005d2: file scm-lazy-string.c, line 23.
+run
Breakpoint 1, main () at scm-lazy-string.c:23
23 const char *ptr = "pointer";
+step
24 const char array[] = "array";
+print ptr
$1 = 0x804006b0 <error: Cannot access memory at address 0x804006b0>
...
If we delete the breakpoint after running to it, we have instead the expected:
...
+delete
+step
24 const char array[] = "array";
+print ptr
$1 = 0x4006b0 "pointer"
...
The problem is in displaced stepping, forced by the presence of the breakpoint,
when stepping over this insn:
...
0x4005d2 <main+10> larl %r1,0x4006b0
...
With normal stepping we have:
...
(gdb) p /x $r1
$2 = 0x3ff004006b0
...
but with displaced stepping we have instead (note the 0x80000000 difference):
...
(gdb) p /x $r1
$1 = 0x3ff804006b0
(gdb)
...
The difference comes from this code in s390_displaced_step_fixup:
...
/* Handle LOAD ADDRESS RELATIVE LONG. */
else if (is_ril (insn, op1_larl, op2_larl, &r1, &i2))
{
/* Update PC. */
regcache_write_pc (regs, from + insnlen);
/* Recompute output address in R1. */
regcache_cooked_write_unsigned (regs, S390_R0_REGNUM + r1,
amode | (from + i2 * 2));
}
...
where the "amode |" adds the 0x80000000.
Fix this by removing the "amode |".
Tested on s390-linux, with native and target board unix/-m31.
Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
|
|
With the AArch64 Scalable Matrix Extension we have a new TPIDR2 register, and
it will be added to the existing NT_ARM_TLS register set. Kernel patches are
being reviewed here:
https://lore.kernel.org/linux-arm-kernel/20220818170111.351889-1-broonie@kernel.org/
From GDB's perspective, we handle it in a similar way to the existing TPIDR
register. But we need to consider cases of systems that only have TPIDR and
systems that have both TPIDR and TPIDR2.
With that in mind, the following patch adds the required code to support
TPIDR2 and turns the org.gnu.gdb.aarch64.tls feature into a
dynamically-generated target description as opposed to a static target
description containing only TPIDR.
That means we can remove the gdb/features/aarch64-tls.xml file and replace the
existing gdb/features/aarch64-tls.c auto-generated file with a new file that
dynamically generates the target description containing either TPIDR alone or
TPIDR and TPIDR2.
In the future, when *BSD's start to support this register, they can just
enable it as is being done for the AArch64 Linux target.
The core file read/write code has been updated to support TPIDR2 as well.
On GDBserver's side, there is a small change to the find_regno function to
expose a non-throwing version of it.
It always seemed strange to me how find_regno causes the whole operation to
abort if it doesn't find a particular register name. The patch moves code
from find_regno into find_regno_no_throw and makes find_regno call
find_regno_no_throw instead.
This allows us to do register name lookups to find a particular register
number without risking erroring out if nothing is found.
The patch also adjusts the feature detection code for aarch64-fbsd, since
the infrastructure is shared amongst all aarch64 targets. I haven't added
code to support TPIDR2 in aarch64-fbsd though, as I'm not sure when/if
that will happen.
|
|
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>
|
|
Instead of using `select_frame (nullptr)` to invalidate the selected
frame, introduce a function to do that. There is no change in behavior,
but it makes the intent a bit clearer. It also allows adding an assert
in select_frame that fi is not nullptr, so it avoids passing nullptr by
mistake.
Change-Id: I61643f46bc8eca428334513ebdaadab63997bdd0
Reviewed-By: Bruno Larsen <blarsen@redhat.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>
|
|
I saw that bppy_init used a non-const "char *". Fixing this revealed
that the xstrdup here was also unnecessary, so this patch removes it.
|
|
This is just a couple of cosmetic fixes in ppc-sysv-tdep.c: fixing
some formatting and correcting a typo.
|
|
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.
|
|
According to the riscv psabi, the mapping relationship between the
DWARF registers and the machine registers is as follows:
DWARF Number | Register Name | Description
0 - 31 | x0 - x31 | Integer Registers
32 - 63 | f0 - f31 | Floating-point Registers
This is not modelled quite right in riscv_dwarf_reg_to_regnum, the
DWARF register numbers 31 and 63 are not handled correctly due to a
use of '<' instead of '<='. This commit fixes this issue.
|
|
Make the inferior_ptid bubble up to linux_nat_target::xfer_partial.
Change-Id: I62dbc5734c26648bb465f449c2003c73751cd812
|
|
I noticed we could reduce duplication a bit here.
Change-Id: If24e54d1dac71b46f7c1f68a18a073d4c084b644
|
|
Not a big deal, but it seems strange to check errno instead of the
ptrace return value to know whether it succeeded.
Change-Id: If0a6d0280ab0e5ecb077e546af0d6fe489c5b9fd
|
|
No caller cares about the value of *SIGINFO on failure. It's also
documented in the function doc that *SIGINFO is uninitialized (I
understand "untouched") on failure.
Change-Id: I5ef38a5f58e3635e109b919ddf6f827f38f1225a
|
|
Change return type to bool.
Change-Id: I1bf0360bfdd1b5994cd0f96c268d806f96fe51a4
|
|
No behavior change expected.
Change-Id: Ifaa64ecd619483646b024fd7c62e571e92a8eedb
|
|
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
|
|
The missing newline causes testsuite issues because the gdb prompt gets output
to an unexpected location.
|
|
Use as many tabs as possible for indentation and pad with spaces to keep
the argument aligned to the opening parenthesis in the line above.
Co-developed-by: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Use tab for the first eight spaces of indentation, and align the gdb_printf
arguments to the open parenthesis of the function call.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
|
|
Add a pid parameter to linux_proc_xfer_memory_partial, making the
inferior_ptid reference bubble up close to the target_ops::xfer_partial
boundary. No behavior change expected.
Change-Id: I58171b00ee1bba1ea22efdbb5dcab8b1ab3aac4c
|
|
Add a few debug statements that were useful to me when debugging why the
glibc probes interface wasn't getting used.
Change-Id: Ic20744f9fc80a90f196896b0829949411620c540
|
|
solib implementations are typically used one at a time. So it will be
rare that you will want to enable debug for one solib kind, and
absolutely want to keep the others disabled. To make things simpler,
instead of adding separate variables / macros / commands for each solib
implementation, merge the existing ones (frv and aix) into a unified
"set/show debug solib", with the solib_debug_printf macro.
Change-Id: I6e18bbc7401724f37ae66681badb079d75ecf7fa
|
|
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>
|
|
I noticed that windows_nat_target::interrupt calls registers_changed.
However, I don't think there's any reason to do this, because this
will happen automatically when the inferior stop is processed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I belatedly realized that the "the_windows_nat_target" global isn't
really necessary. It's only used in one place, where 'this' would be
simpler and clearer. This patch removes the global entirely.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
It is only used inside frame.c.
Change-Id: I44eb46a5992412f8f8b4954b2284b0ef3b549504
|
|
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>
|
|
This refactors cooked_index::do_finalize, reordering an 'if' to make
it a little less redundant. This change makes a subsequent patch
easier to read.
Reviewed-by: Andrew Burgess <aburgess@redhat.com>
|
|
dwarf2_compute_name has a redundant check of the CU's language -- this
is also checked in dwarf2_canonicalize_name. Removing this slightly
simplifies a future patch.
Reviewed-by: Andrew Burgess <aburgess@redhat.com>
|
|
While testing the fix for PR 29105, I noticed I couldn't ctrl-C my way
out of GDB expanding many symtabs. GDB was busy in a loop in
cooked_index_functions::expand_symtabs_matching. Add a QUIT there. I
also happened to see a spot in
cooked_index_functions::expand_matching_symbols where a QUIT would be
useful too, since we iterate over a potentially big number of index
entries and expand CUs in the loop. Add one there too.
Change-Id: Ie1d650381df7f944c16d841b3e592d2dce7306c3
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
Pedro mentioned that this prune_threads call in
thread_db_target::update_thread_list was not needed, and it was probably
an oversight to leave it there in the work following commit e8032dde10b
("Push pruning old threads down to the target"). That commit changed
the "find new threads" target operation to "update thread list", making
the target responsible of adding new threads and removing exited
threads, rather than just adding new threads. Commit e8032dde10b moved
the prune_threads calls previously done in common code into each
target's update_thread_list method, in order to keep the existing
behavior, which is why this prune_threads call ended up there.
In the mean time, the linux-nat target was taught to update_thread_list,
and thread_db_target::update_thread_list defers to that for any live
inferior, so the prune_threads call is not needed there. Otherwise, the
thread_db_target::update_thread_list implementation based on
td_ta_thr_iter_p only knows how to add new threads, not how to delete
exited threads, but that is only used for non-live inferiors, where
threads can't exit anyway. So the prune_threads call is not needed for
that case either.
Change-Id: I127fd4f84c25086f97853dadf34c5cec6816840d
Approved-By: Pedro Alves <pedro@palves.net>
|
|
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.
|
|
--enable-targets=all
On s390x-linux, I run into:
...
DUPLICATE: gdb.arch/s390-disassembler-options.exp: \
show disassembler-options esa
...
First, reproduce this on x86_64-linux with --enable-targets=all, by replacing
the test for 'istarget "s390*-*-*"' with a test for 'get_set_option_choices
"set architecture" "s390"'.
Fix the DUPLICATE by using with_test_prefix.
Also modernize the test-case by using clean_restart instead of gdb_exit/gdb_start.
Tested on x86_64-linux.
|
|
While looking into Ada tasking a little, I noticed that no bounds
checking is done on accesses to the Ada task state names arrays. This
isn't a problem currently, but if the runtime ever added numbers -- or
if there was some kind of runtime corruption -- it could cause a gdb
crash.
This patch adds range checking. It also adds a missing _() call when
printing from the 'task_states' array.
|
|
This changes mi_interp to use ui_file_up rather than explicit
management.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This renames the fields of cli_interp_base::saved_output_files, as
requested by Simon. I tried to choose names that more obviously
reflect what the field is used for. I also added a couple of
comments.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Currently, on x86_64, a little endian target, I get:
...
$ gdb -q -batch -ex "maint print architecture" | grep " = floatformat"
gdbarch_dump: bfloat16_format = floatformat_bfloat16_big
gdbarch_dump: double_format = floatformat_ieee_double_big
gdbarch_dump: float_format = floatformat_ieee_single_big
gdbarch_dump: half_format = floatformat_ieee_half_big
gdbarch_dump: long_double_format = floatformat_i387_ext
...
which suggests big endian.
This is due to this bit of code in pformat:
...
/* Just print out one of them - this is only for diagnostics. */
return format[0]->name;
...
Fix this by using gdbarch_byte_order to pick the appropriate index, such that
we have the more accurate:
...
gdbarch_dump: bfloat16_format = floatformat_bfloat16_little
gdbarch_dump: half_format = floatformat_ieee_half_little
gdbarch_dump: float_format = floatformat_ieee_single_little
gdbarch_dump: double_format = floatformat_ieee_double_little
gdbarch_dump: long_double_format = floatformat_i387_ext
...
Tested on x86_64-linux.
|
