| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch is a comprehensive fix for PR 17820 which reports that
using "set history size unlimited" inside one's gdbinit file doesn't
really work.
There are three small changes in this patch. The most important change
this patch makes is to decode the argument of the "size" subcommand
using add_setshow_zuinteger_unlimited_cmd() instead of using
add_setshow_uinteger_cmd(). The new decoder takes an int * and maps
unlimited to -1 whereas the old decoder takes an unsigned int * and maps
unlimited to UINT_MAX. Using the new decoder simplifies our handling of
unlimited and makes it easier to interface with readline which itself
expects a signed-int history size.
The second change is the factoring of the [stifle|unstifle]_history logic
into a common function which is now used by both init_history() and
set_history_size_command(). This is technically the change that fixes
the PR itself.
Thirdly, this patch initializes history_size_setshow_var to -2 to mean
that the variable has not been set yet. Now init_history() tests for -2
instead of 0 to determine whether to give the variable a default value.
This means that having "set history size 0" in one's gdbinit file will
actually keep the history size at 0 and not reset it to 256.
gdb/ChangeLog:
PR gdb/17820
* top.c (history_size_setshow_var): Change type to signed.
Initialize to -2. Update documentation.
(set_readline_history_size): Define.
(set_history_size_command): Use it. Remove logic for handling
out-of-range sizes.
(init_history): Use set_readline_history_size(). Test for a
value of -2 instead of 0 when determining whether to set a
default history size.
(init_main): Decode the argument of the "size" command as a
zuinteger_unlimited.
gdb/testsuite/ChangeLog:
PR gdb/17820
* gdb.base/gdbinit-history.exp: New test.
* gdb.base/gdbinit-history/unlimited/.gdbinit: New file.
* gdb.base/gdbinit-history/zero/.gdbinit: New file.
|
|
gdb/ChangeLog:
* NEWS (Python Scripting): Mention the new gdb.Value methods.
* python/py-value.c (valpy_reference_value): New function.
(valpy_const_value): Likewise.
(value_object_methods): Add new methods.
* value.c (make_cv_value): New function.
* value.h (make_cv_value): Declare.
gdb/doc/ChangeLog:
* python.texi (Values From Inferior): Add descriptions of new
methods gdb.Value.reference_value and gdb.Value.const_value.
gdb/testsuite/ChangeLog:
* gdb.python/py-xmethods.cc: Enhance test case.
* gdb.python/py-xmethods.exp: New tests.
* gdb.python/py-xmethods.py (A_indexoper): New xmethod worker
function.
(B_indexoper): Likewise.
(global_dm_list) : Add new xmethod worker functions.
|
|
In my last commit to make gdb.base/coredump-filter.exp be more robust
regarding using arrays in the global namespace, I cleared the
"coredump_var_addr" array like this:
set coredump_var_addr ""
# use coredump_var_addr as an array...
This causes DejaGNU to complain because the variable is first set as
non-array, and the used as an array. The correct way to do this is to
unset the variable using:
unset -nocomplain coredump_var_addr
# use coredump_var_addr as an array...
The "-nocomplain" part is necessary because if the variable doesn't
exist "unset" will not error.
Tested on Fedora 20 x86_64.
gdb/testsuite/ChangeLog:
2015-05-08 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/coredump-filter.exp: Correctly unset
"coredump_var_addr" array.
|
|
Sequential test runs are stopping prematurely like this:
$ make check RUNTESTFLAGS="non-existing-program.exp server-exec-info.exp"
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.server/non-existing-program.exp ...
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.server/server-exec-info.exp ...
can not find channel named "exp6"
while executing
"match_max [match_max -d]"
(procedure "default_gdb_init" line 26)
invoked from within
"default_gdb_init $test_file_name"
(procedure "gdb_init" line 83)
invoked from within
"${tool}_init $test_file_name"
(procedure "runtest" line 18)
invoked from within
"runtest $test_name"
("foreach" body line 42)
invoked from within
...
make[2]: *** [check-single] Error 1
make[2]: Leaving directory `/home/pedro/gdb/mygit/build/gdb/testsuite'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/home/pedro/gdb/mygit/build/gdb/testsuite'
make: *** [check] Error 2
default_gdb_init has this:
# Unlike most tests, we have a small number of tests that generate
# a very large amount of output. We therefore increase the expect
# buffer size to be able to contain the entire test output. This
# is especially needed by gdb.base/info-macros.exp.
match_max -d 65536
# Also set this value for the currently running GDB.
match_max [match_max -d]
It's the second match_max that is erroring. As that call does not
specify an explicit channel name with -i, expect defaults to
$spawn_id, which is pointing at a channel that is already gone. (If
the spawn_id variable is not set, match_max defaults to
$user_spawn_id / stdin/out).
gdb/testsuite/ChangeLog:
2015-05-08 Pedro Alves <palves@redhat.com>
* gdb.server/non-existing-program.exp: Unset spawn_id.
|
|
gdb/ChangeLog:
PR python/18291
* python/lib/gdb/command/xmethods.py (print_xm_info): Fix typo.
Print xmethod matcher status.
gdb/testsuite/ChangeLog:
PR python/18291
* gdb.python/py-xmethods.exp: Add tests.
|
|
Hi,
We see some fails in gdb.base/coredump-filter.exp when we do remote
gdbserver testing, like what I did for arm/aarch64 linux testing or
run it with board file remote-gdbserver-on-localhost
$ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost coredump-filter.exp'
we find that this line in the test doesn't work as expected,
remote_exec target "sh -c \"echo $filter_flag > /proc/$ipid/coredump_filter\""
although such pattern has been used in gdb testsuite somewhere else,
but the special thing here is that we redirect the output to
/proc/$ipid/coredump_filter on the remote target. DejaGNU will
redirect the output from the remote target to local, and looks tcl
gets confused by these two redirection.
After trying pass different parameters to remote_exec and hacking
remote_exec/rsh_exec/local_exec, I got no success, I decide
to give up, and try to update /proc/$ipid/coredump_filter by the c
code directly.
This patch adds a c function set_coredump_filter to update
coredump_filter, and GDB calls it.
gdb/testsuite:
2015-05-08 Yao Qi <yao.qi@linaro.org>
PR gdb/18208
* gdb.base/coredump-filter.c (set_coredump_filter): New function.
* gdb.base/coredump-filter.exp (do_save_core): Call inferior
function set_coredump_filter, and remove remote_exec call.
Remove argument ipid. Callers update.
(top level): Don't get inferior's PID.
|
|
Since watch_thread_num.exp was changed to use access watchpoints, the
test case fails on s390 and s390x, since those targets do not support
access watchpoints. This patch skips the test case on such targets.
gdb/testsuite/ChangeLog:
* gdb.base/watch_thread_num.exp: Skip test on targets without
access watchpoints.
|
|
$ ./gdbserver :1234 blah
Process blah created; pid = 16471
Cannot exec blah: No such file or directory.
Child exited with status 127
Killing process(es): 16471
../../../../src/binutils-gdb/gdb/gdbserver/linux-low.c:920: A problem internal to GDBserver has been detected.
kill_wait_lwp: Assertion `res > 0' failed.
GDBserver shouldn't even be trying to kill that process. GDBserver
kills or detaches from all processes on exit, and due to a missing
mourn_inferior call, GDBserver tries to kill the process that it had
already seen exit.
Tested on x86_64 Fedora 20. New test included. I emulated what
Windows outputs by hacking an error call in linux_create_inferior.
gdb/gdbserver/ChangeLog:
2015-05-06 Pedro Alves <palves@redhat.com>
PR server/18081
* server.c (start_inferior): If the process exits, mourn it.
gdb/testsuite/ChangeLog:
2015-05-06 Pedro Alves <palves@redhat.com>
PR server/18081
* gdb.server/non-existing-program.exp: New file.
|
|
This patch improves the handling of out-of-line functions nested
inside functions that have been inlined.
Consider for instance a situation where function Foo_O224_021
has a function Child1 declared in it, which itself has a function
Child2 nested inside Child1. After compiling the program with
optimization on, Child1 gets inlined, but not Child2.
After inserting a breakpoint on Child2, and running the program
until reaching that breakpoint, we get the following backtrace:
% gdb foo_o224_021
(gdb) break foo_o224_021.child1.child2
(gdb) run
[...]
Breakpoint 1, foo_o224_021 () at foo_o224_021.adb:28
28 Child1;
(gdb) bt
#0 0x0000000000402400 in foo_o224_021 () at foo_o224_021.adb:28
#1 0x00000000004027a4 in foo_o224_021.child1 () at foo_o224_021.adb:23
#2 0x00000000004027a4 in foo_o224_021 () at foo_o224_021.adb:28
GDB reports the wrong function name for frame #0. We also get the same
kind of error in the "Breakpoint 1, foo_o224_021 () [...]" message.
In both cases, the function name should be foo_o224_021.child1.child2,
and the parameters should be "s=...".
What happens is that the inlined frame handling does not handle well
the case where an inlined function is calling an out-of-line function
which was declared inside the inlined function's scope.
In particular, looking first at the inlined-frame sniffer when applying
to frame #0:
/* Calculate DEPTH, the number of inlined functions at this
location. */
depth = 0;
cur_block = frame_block;
while (BLOCK_SUPERBLOCK (cur_block))
{
if (block_inlined_p (cur_block))
depth++;
cur_block = BLOCK_SUPERBLOCK (cur_block);
}
What happens is that cur_block starts as the block associated
to child2, which is not inlined. We shoud be stopping here, but
instead, we keep walking the superblock chain, which takes us
all the way to Foo_O224_021's block, via Child2's block. And
since Child1 was inlined, we end up with a depth count of 1,
wrongly making GDB think that frame #0 is an inlined frame.
Same kind of issue inside skip_inline_frames.
The fix is to stop checking for inlined frames as soon as we see
a block corresponding to a function which is not inlined. This is
the behavior we now obtain:
(gdb) run
[...]
Breakpoint 1, foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:9
9 function Child2 (S : String) return Boolean is
(gdb) bt
#0 0x0000000000402400 in foo_o224_021.child1.child2 (s=...)
at foo_o224_021.adb:9
#1 0x00000000004027a4 in foo_o224_021.child1 () at foo_o224_021.adb:23
#2 0x00000000004027a4 in foo_o224_021 () at foo_o224_021.adb:28
gdb/ChangeLog:
* inline-frame.c (inline_frame_sniffer, skip_inline_frames):
Stop counting inlined frames as soon as an out-of-line function
is found.
gdb/testsuite/ChangeLog:
* gdb.ada/out_of_line_in_inlined.exp: Add run and "bt" tests.
|
|
Consider the following code, which defines a function, Child2,
which is itself nested inside Child1:
procedure Foo_O224_021 is
O1 : constant Object_Type := Get_Str ("Foo");
procedure Child1 is
O2 : constant Object_Type := Get_Str ("Foo");
function Child2 (S : String) return Boolean is -- STOP
begin
for C of S loop
Do_Nothing (C);
if C = 'o' then
return True;
end if;
end loop;
return False;
end Child2;
R : Boolean;
begin
R := Child2 ("Foo");
R := Child2 ("Bar");
R := Child2 ("Foobar");
end Child1;
begin
Child1;
end Foo_O224_021;
On x86_64-linux, when compiled at -O2, GDB is unable to insert
a breakpoint on Child2:
% gnatmake -g -O2 foo_o224_021
% gdb foo_o224_021
(gdb) b child2
Function "child2" not defined.
(gdb) b foo_o224_021.child1.child2
Function "foo_o224_021.child1.child2" not defined.
The problem is caused by the fact that GDB did not create a symbol
for Child2, and this, in turn, is caused by the fact that the compiler
decided to inline Child1, but not Child2. The DWARF debugging info
first provides an abstract instance tree for Child1...
<3><1b7b>: Abbrev Number: 29 (DW_TAG_subprogram)
<1b7c> DW_AT_name : (indirect string, offset: 0x23f8): foo_o224_021__child1
<1b82> DW_AT_inline : 1 (inlined)
<1b83> DW_AT_sibling : <0x1c01>
... where that subprogram is given the DW_AT_inline attribute.
Inside that function there is a lexical block which has no PC
range (corresponding to the fact that this is the abstract tree):
<4><1b87>: Abbrev Number: 30 (DW_TAG_lexical_block)
... inside which our subprogram Child2 is described:
<5><1b92>: Abbrev Number: 32 (DW_TAG_subprogram)
<1b93> DW_AT_name : (indirect string, offset: 0x2452): foo_o224_021__child1__child2
<1b99> DW_AT_type : <0x1ab1>
<1b9d> DW_AT_low_pc : 0x402300
<1ba5> DW_AT_high_pc : 0x57
[...]
Then, later on, we get the concrete instance tree, starting at:
<3><1c5e>: Abbrev Number: 41 (DW_TAG_inlined_subroutine)
<1c5f> DW_AT_abstract_origin: <0x1b7b>
<1c63> DW_AT_entry_pc : 0x4025fd
<1c6b> DW_AT_ranges : 0x150
... which refers to Child1. One of that inlined subroutine children
is the concrete instance of the empty lexical block we saw above
(in the abstract instance tree), which gives the actual address
range for this inlined instance:
<5><1c7a>: Abbrev Number: 43 (DW_TAG_lexical_block)
<1c7b> DW_AT_abstract_origin: <0x1b87>
<1c7f> DW_AT_ranges : 0x180
This is the DIE which provides the context inside which we can
record Child2. But unfortunately, GDB does not take the abstract
origin into account when handling lexical blocks, causing it
to miss the fact that this block contains some symbols described
in the abstract instance tree. This is the first half of this patch:
modifying GDB to follow DW_AT_abstract_origin attributes for
lexical blocks.
But this not enough to fix the issue, as we're still unable to
break on Child2 with just that change. The second issue can be
traced to the way inherit_abstract_dies determines the list of
DIEs to inherit from. For that, it iterates over all the DIEs in
the concrete instance tree, and finds the list of DIEs from the
abstract instance tree that are not referenced from the concrete
instance tree. As it happens, there is one type of DIE in the
concrete instance tree which does reference Child2's DIE, but
in fact does otherwise define a concrete instance of the reference
DIE; that's (where <0x1b92> is Child2's DIE):
<6><1d3c>: Abbrev Number: 35 (DW_TAG_GNU_call_site)
<1d3d> DW_AT_low_pc : 0x4026a4
<1d45> DW_AT_abstract_origin: <0x1b92>
So, the second part of the patch is to modify inherit_abstract_dies
to ignore DW_TAG_GNU_call_site DIEs when iterating over the concrete
instance tree.
This patch also includes a testcase which can be used to reproduce
the issue. Unfortunately, for it to actually pass, a smal patch in
GCC is also necessary to make sure that GCC provides lexical blocks'
DW_AT_abstract_origin attributes from the concrete tree back to
the abstract tree. We hope to be able to submit and integrate that
patch in the GCC tree soon. Meanwhile, a setup_xfail has been added.
gdb/ChangeLog:
2014-05-05 Pierre-Marie de Rodat <derodat@adacore.com>
* dwarf2read.c (inherit_abstract_dies): Skip
DW_TAG_GNU_call_site dies while inheriting children of an
abstract DIE into a scope.
(read_lexical_block_scope): Inherit abstract DIE's for
lexical scopes.
gdb/testsuite/ChangeLog:
* gdb.ada/out_of_line_in_inlined: New testcase.
|
|
gdb/testsuite/ChangeLog:
* gdb.ada/var_rec_arr: New testcase.
|
|
gdb.base/break-idempotent.exp
Hi,
I see this fails below on arm linux native testing and remote testing
with "set remote hardware-watchpoint-limit 1",
rwatch global^M
There are not enough available hardware resources for this watchpoint.^M
(gdb) FAIL: gdb.base/break-idempotent.exp: always-inserted off: rwatch: twice: rwatch global
gdb.base/break-idempotent.exp sets two breakpoints/watchpoints on the
same address. GDB isn't smart enough calculate these two HW
watchpoints can fit in one HW debug register, so the error message
above isn't necessary (there is one HW watchpoint register on arm).
Because target_ops interface can_use_hardware_watchpoint doesn't
pass enough information to the target backend.
Note that if I don't "set remote hardware-watchpoint-limit 1" in
remote testing, this test passes without fails. However without
"set remote hardware-watchpoint-limit 1", many other watchpoint
tests fail.
This patch is to add a check to skip_hw_watchpoint_multi_tests
for rwatch and awatch. We can add such check for watch as well,
but GDB is able to switch to software watchpoint if HW resource
isn't available, it doesn't cause any fail, I decide not to skip.
gdb/testsuite:
2015-04-30 Yao Qi <yao.qi@linaro.org>
* gdb.base/break-idempotent.exp: If
skip_hw_watchpoint_multi_tests returns true, skip the tests
on "rwatch" and "awatch".
|
|
Hi,
I see the fail in gdb.base/relativedebug.exp on aarch64 box on which
glibc doesn't have debug info,
bt^M
#0 0x0000002000061a88 in raise () from /lib/aarch64-linux-gnu/libc.so.6^M
#1 0x0000002000064efc in abort () from /lib/aarch64-linux-gnu/libc.so.6^M
#2 0x0000000000400640 in handler (signo=14) at ../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:25^M
#3 <signal handler called>^M
#4 0x00000020000cc478 in ?? () from /lib/aarch64-linux-gnu/libc.so.6^M
#5 0x0000000000400664 in main () at ../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:32^M
(gdb) FAIL: gdb.base/relativedebug.exp: pause found in backtrace
if glibc has debug info, this test doesn't fail.
In sysdeps/unix/sysv/linux/generic/pause.c, __libc_pause calls
__syscall_pause,
static int
__syscall_pause (void)
{
sigset_t set;
int rc =
INLINE_SYSCALL (rt_sigprocmask, 4, SIG_BLOCK, NULL, &set, _NSIG / 8);
if (rc == 0)
rc = INLINE_SYSCALL (rt_sigsuspend, 2, &set, _NSIG / 8);
return rc;
}
int
__libc_pause (void)
{
if (SINGLE_THREAD_P)
return __syscall_pause (); <--- tail call
int oldtype = LIBC_CANCEL_ASYNC ();
int result = __syscall_pause ();
LIBC_CANCEL_RESET (oldtype);
return result;
}
and GDB unwinder is confused by the GCC optimized code,
(gdb) disassemble pause
Dump of assembler code for function pause:
0x0000007fb7f274c4 <+0>: stp x29, x30, [sp,#-32]!
0x0000007fb7f274c8 <+4>: mov x29, sp
0x0000007fb7f274cc <+8>: adrp x0, 0x7fb7fd2000
0x0000007fb7f274d0 <+12>: ldr w0, [x0,#364]
0x0000007fb7f274d4 <+16>: stp x19, x20, [sp,#16]
0x0000007fb7f274d8 <+20>: cbnz w0, 0x7fb7f274e8 <pause+36>
0x0000007fb7f274dc <+24>: ldp x19, x20, [sp,#16]
0x0000007fb7f274e0 <+28>: ldp x29, x30, [sp],#32
0x0000007fb7f274e4 <+32>: b 0x7fb7f27434 <---- __syscall_pause
0x0000007fb7f274e8 <+36>: bl 0x7fb7f5e080
Note that the program stops in __syscall_pause, but its symbol is
stripped in glibc, so GDB doesn't know where the program stops.
__syscall_pause is a tail call in __libc_pause, so it returns to main
instead of __libc_pause. As a result, the backtrace is like,
#0 0x0000007fb7ebca88 in raise () from /lib/aarch64-linux-gnu/libc.so.6
#1 0x0000007fb7ebfefc in abort () from /lib/aarch64-linux-gnu/libc.so.6
#2 0x0000000000400640 in handler (signo=14) at ../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:25
#3 <signal handler called>
#4 0x0000007fb7f27478 in ?? () from /lib/aarch64-linux-gnu/libc.so.6 <-- [in __syscall_pause]
#5 0x0000000000400664 in main () at ../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:32
looks GDB does nothing wrong here. I looked back at the test case
gdb.base/relativedebug.exp, which was added
https://sourceware.org/ml/gdb-patches/2006-10/msg00305.html
This test was indented to test the problem that "backtraces no longer
display some libc functions" after separate debug info is installed.
IOW, it makes few sense to test against libc which doesn't have debug
info at all, such as my case.
This patch is to tweak the test case to catch the output of
"info shared", if "(*)" is found for libc.so, which means libc doesn't
have debug info, then skip the test.
gdb/testsuite:
2015-04-30 Yao Qi <yao.qi@linaro.org>
* gdb.base/relativedebug.exp: Invoke gdb command
"info sharedlibrary", and if libc.so doesn't have debug info,
skip the test.
|
|
gdb/ChangeLog:
PR python/18285
* NEWS: Document new gdb.XMethodWorker.get_result_type method.
* eval.c (evaluate_subexp_standard) <OP_FUNCALL>: Handle
EVAL_AVOID_SIDE_EFFECTS for xmethods.
* extension-priv.h (struct extension_language_ops)
<get_xmethod_result_type>: New member.
* extension.c (get_xmethod_result_type): New function.
* extension.h (get_xmethod_result_type): Declare.
* python/py-xmethods.c (get_result_type_method_name): New static
global.
(py_get_result_type_method_name): Ditto.
(gdbpy_get_xmethod_result_type): New function.
(gdbpy_initialize_xmethods): Initialize py_get_result_type_method_name.
* python/python-internal.h (gdbpy_get_xmethod_result_type): Declare.
* python/python.c (python_extension_ops): Add
gdbpy_get_xmethod_result_type.
* python/lib/gdb/xmethod.py (XMethodWorker): Add get_result_type.
* valarith.c (value_x_binop): Handle EVAL_AVOID_SIDE_EFFECTS for
xmethods.
(value_x_unop): Ditto.
* value.c (result_type_of_xmethod): New function.
* value.h (result_type_of_xmethod): Declare.
gdb/testsuite/ChangeLog:
* gdb.python/py-xmethods.exp: Add ptype tests.
* gdb.python/py-xmethods.py (E_method_char_worker): Add
get_result_type method.
gdb/doc/ChangeLog:
* python.texi (Xmethod API) <gdb.XMethodWorker.get_result_type>:
Document.
(Writing an Xmethod): Add get_result_type to example.
|
|
testing gdb.base/watch-bitfields.exp
There are targets GDB thinks support hardware watchpoints, but in reality they
don't. Though it may seem that hardware watchpoint creation was successful,
the actual insertion of such watchpoint will fail when GDB moves the inferior.
(gdb) watch -location q.a^M
Hardware watchpoint 2: -location q.a^M
(gdb) PASS: gdb.base/watch-bitfields.exp: -location watch against bitfields: watch -location q.a
watch -location q.e^M
Hardware watchpoint 3: -location q.e^M
(gdb) PASS: gdb.base/watch-bitfields.exp: -location watch against bitfields: watch -location q.e
print q.a^M
$1 = 0^M
(gdb) PASS: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 0->1: print expression before
continue^M
Continuing.^M
Warning:^M
Could not insert hardware watchpoint 2.^M
Could not insert hardware watchpoint 3.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 0->1: continue
This leads to a number of FAILs:
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 0->1: continue
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 0->1: print expression after
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 0->5: continue
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 0->5: print expression after
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 1->0: print expression before
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.a: 1->0: continue
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 5->4: print expression before
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 5->4: continue
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: q.e: 5->4: print expression after
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: continue until exit
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 0->4: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 0->4: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 4->10: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 4->10: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 4->10: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 10->3: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 10->3: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 10->3: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 3->2: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 3->2: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 3->2: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 2->1: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 2->1: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 2->1: print expression after
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 1->0: print expression before
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: q.d + q.f + q.g: 1->0: continue
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: continue until exit
We can avoid these errors/FAILs by checking the board data and switching to
software watchpoints if the board does not support hardware watchpoints.
gdb/testsuite/ChangeLog:
2015-04-29 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/watch-bitfields.exp: Switch to software watchpoints if
the target does not support hardware watchpoints.
|
|
This is another case of the testcase not handling memory write errors that
happen on some targets (QEMU) when GDB attempts to modify an address that
should contain a breakpoint, for example.
The following patch handles this and prevents spurious failures from
happening. It also adds a foreach loop to avoid duplication of code
and hardcoded patterns.
gdb/testsuite/ChangeLog:
2015-04-29 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/break-always.exp: Abort testing if writing to memory
causes an error.
|
|
gdb/ChangeLog:
PR python/18299
* python/lib/gdb/printing.py (register_pretty_printer): Handle
name or __name__ attributes. Handle gdb module as first argument.
gdb/testsuite/ChangeLog:
* gdb.python/py-pp-maint.py: Move "replace" testing to ...
* gdb.python/py-pp-registration.exp: ... here. New file.
* gdb.python/py-pp-registration.c: New file.
* gdb.python/py-pp-registration.py: New file.
|
|
gdb/ChangeLog:
PR python/18089
* python/py-prettyprint.c (print_children): Verify result of children
iterator. Provide better error message.
* python/python-internal..h (gdbpy_print_python_errors_p): Declare.
* python/python.c (gdbpy_print_python_errors_p): New function.
gdb/testsuite/ChangeLog:
* gdb.python/py-bad-printers.c: New file.
* gdb.python/py-bad-printers.py: New file.
* gdb.python/py-bad-printers.exp: New file.
|
|
gdb/ChangeLog:
* NEWS: Mention gdb.Type.optimized_out method.
* python/py-type.c (typy_optimized_out): New function.
gdb/doc/ChangeLog:
* python.texi: New method documented.
gdb/testsuite/ChangeLog:
* gdb.python/py-type.exp: New test.
|
|
gdb/testsuite/ChangeLog:
* gdb.python/py-parameter.exp:
* gdb.guile/scm-parameter.exp: Escape the path that we are
matching against, as it might contain characters that are special
to regular expressions.
|
|
Consider the following declarations:
type Int_Access is access Integer;
type Record_Type is record
IA : Int_Access;
end record;
R : Record_Type;
Printing the type name of "R.IA" yields:
(gdb) whatis r.ia
type = access integer
It should be:
(gdb) whatis r.ia
type = bar.int_access
Looking at the debugging info, field "r.ia" is defined as
a typedef which has the name of the field type:
.uleb128 0x3 # (DIE (0x4e) DW_TAG_typedef)
.long .LASF4 # DW_AT_name: "bar__int_access"
.long 0x8b # DW_AT_type
... with the typedef's target type being an anonymous pointer
type:
.uleb128 0x7 # (DIE (0x8b) DW_TAG_pointer_type)
.byte 0x8 # DW_AT_byte_size
.long 0x91 # DW_AT_type
What happens here is that a couple of function in ada-lang.c
always start by stripping all typedef layers when handling
struct fields, with the effect of making us lose the type name
in this case.
We did not understand this at the time the code was written,
but typedefs should be stripped only when we know we do not
need them. So this patch, adjust the code to avoid the stripping
while handling the fields, and adds it back in the lone place
which handles the result of processing and didn't know how to
handle typedefs struct fields yet.
gdb/ChangeLog:
* ada-lang.c (ada_is_tagged_type): Add call to ada_check_typedef.
(ada_lookup_struct_elt_type): Remove calls to ada_check_typedef.
(template_to_static_fixed_type): Call ada_check_typedef only
when necessary.
gdb/testsuite/ChangeLog:
* gdb.ada/rec_comp: New testcase.
|
|
gdb.base/coredump-filter.exp
This commit is a continuation of the fix committed on:
commit 8cd8f2f8ac49276437b7da37f275706ea1c1c925
Author: Sergio Durigan Junior <sergiodj@redhat.com>
Date: Mon Apr 13 02:40:08 2015 -0400
Rename variable "addr" to "coredump_var_addr" in gdb.base/coredump-filter.exp
Pedro pointed out that this fix was not complete, because the
testsuite could be run several times in a row (for example), which
means that it is not enough to just make the variable name unique: it
also needs to be cleared out if it is global.
This commit does that. It is actually just a commit made to make
things totally correct; this specific test does not fail if you run it
several times in a row.
gdb/testsuite/ChangeLog:
2015-04-26 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/coredump-filter.exp: Clear variable "coredump_var_addr"
before using it.
|
|
Extend the gdb 'dump' command to allow creating output in verilog hex
format. Add some tests to cover new functionality. As bfd does not
currently support reading in verilog hex formats the tests only cover
the 'dump' command, not the 'restore' command.
gdb/ChangeLog:
* cli/cli-dump.c (verilog_cmdlist): New variable.
(dump_verilog_memory): New function.
(dump_verilog_value): New function.
(verilog_dump_command): New function.
(_initialize_cli_dump): Add new commands to support verilog dump
format.
* NEWS: Add entry for "dump verilog".
gdb/doc/ChangeLog:
* gdb.texinfo (Dump/Restore Files): Add detail about verilog dump
format.
gdb/testsuite/ChangeLog:
* gdb.base/dump.exp: Add *.verilog files to all_files list. Add
new tests for verilog output.
|
|
This patch is to add a new board file that does real remote gdbserver
testing on localhost. This board file can be used to reproduce PR 18208.
gdb/testsuite
2015-04-24 Yao Qi <yao.qi@linaro.org>
* boards/remote-gdbserver-on-localhost.exp: New file.
|
|
Currently, against gdbserver, interrupt.exp occasionaly fails like
this:
ERROR: Process no longer exists
UNRESOLVED: gdb.base/interrupt.exp: send end of file
The problem is that we see gdbserver exiting before we match gdb's
output:
expect: does "\r\n\r\nChild exited with status 0\r\nGDBserver exiting\r\n" (spawn_id exp8) match regular expression "end of file"? Gate "end of file"? gate=no
expect: read eof
expect: set expect_out(spawn_id) "exp8"
expect: set expect_out(buffer) "\r\n\r\nChild exited with status 0\r\nGDBserver exiting\r\n"
Fix this by removing $inferior_spawn_id from the set of spawn ids
expect is watching as soon as we see the "end of file" string out of
the inferior spawn id, using an indirect spawn id list.
Tested on x86-64 Fedora 20, native and gdbserver (both target remote
and extended-remote).
gdb/testsuite/ChangeLog:
2015-04-23 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Use an indirect spawn id list holding
$inferior_spawn_id instead of $inferior_spawn_id directly. On
"end of file", remove $inferior_spawn_id from the indirect list.
|
|
To avoid confusion between "end of file" string matching and eof
matching, as in process exit.
gdb/testsuite/ChangeLog:
2015-04-23 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Rename saw_eof to saw_end_of_file.
|
|
Since silent handling of eof is usually the wrong thing to do, this
patch makes gdb_test_multiple handle it for all $any_spawn_id.
Currently, against gdbserver, interrupt.exp occasionaly fails like
this:
FAIL: gdb.base/interrupt.exp: send end of file
gdb.log with expect debug output enabled shows:
expect: does "\r\n\r\nChild exited with status 0\r\nGDBserver exiting\r\n" (spawn_id exp8) match regular expression "end of file"? Gate "end of file"? gate=no
expect: read eof
expect: set expect_out(spawn_id) "exp8"
expect: set expect_out(buffer) "\r\n\r\nChild exited with status 0\r\nGDBserver exiting\r\n"
FAIL: gdb.base/interrupt.exp: send end of file
Note "expect: read eof" for spawn_id=exp8. exp8 is
inferior_spawn_id/gdbserver_spawn_id. That means
expect/gdb_test_multiple saw gdbserver exit before we got the expected
gdb output. Since there's no explicit pattern for "eof", expect (and
thus gdb_test_multiple) just returns.
After this commit, we get instead:
ERROR: Process no longer exists
UNRESOLVED: gdb.base/interrupt.exp: send end of file
Note that before we still got an FAIL because $saw_inferior_exit is 0
when we get to:
gdb_assert { $saw_eof && $saw_inferior_exit } $msg
Fixing the fail (now unresolved) will be the subject of a separate
patch.
gdb/testsuite/ChangeLog:
2015-04-23 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_multiple): Match eof/full_buffer/timeout
on $any_spawn_id instead of only on $gdb_spawn_id.
|
|
Problem reported as PR pascal/17815
Part 1/3: Remember the case pattern that allowed finding a field of this.
File gdb/p-exp.y modified
This is the fix in the pascal parser (p-exp.y),
to avoid the error that GDB does find normal variables
case insensitively, but not fields of this,
inside a class or object method.
Part 2/3: Add "class" option for pascal compiler
File gdb/testsuite/lib/pascal.exp
This part of the patch series is unchanged.
It adds class option to pascal compiler
which adds the required command line option to
accept pascal class types.
Part 3/3:
New file: gdb/testsuite/gdb.pascal/case-insensitive-symbols.exp
New file: gdb/testsuite/gdb.pascal/case-insensitive-symbols.pas
Here is an updated version of this test, using Pedro's suggestions.
Test to check that PR 17815 is fixed.
|
|
This commit fixes three gdb.base/attach.exp failures when using
extended remote targets. The failures occurred because GDB now
locates and loads files when attaching on remote targets if the
remote target supports qXfer:exec-file:read; the filenames were
shown but with "target:" prefixes which the test has been updated
to handle.
gdb/testsuite/ChangeLog:
* gdb.base/attach.exp: Fix three extended remote failures.
|
|
This commit modifies remote_add_inferior to take an extra argument
try_open_exec. If this is nonzero, remote_add_inferior will attempt
to open this inferior's executable as the main executable if no main
executable is open already. Callers are updated appropriately.
With this commit, remote debugging can now be initiated using only a
"target remote" or "target extended-remote" command; no "set sysroot"
or "file" commands are required, e.g.
bash$ gdb -q
(gdb) target remote | gdbserver - /bin/sh
Remote debugging using | gdbserver - /bin/sh
Process /bin/sh created; pid = 32166
stdin/stdout redirected
Remote debugging using stdio
Reading symbols from target:/bin/bash...
One testcase required updating as a result of this commit. The test
checked that GDB's "info files" command does not crash if no main
executable is open, and relied on GDB's inability to access the main
executable over the remote protocol. The test was updated to inhibit
this new behavior.
gdb/ChangeLog:
* remote.c (remote_add_inferior): New argument try_open_exec.
If nonzero, attempt to open the inferior's executable file as
the main executable if no main executable is open already.
All callers updated.
* NEWS: Mention that GDB now supports automatic location and
retrieval of executable + files from remote targets.
gdb/doc/ChangeLog:
* gdb.texinfo (Connecting to a Remote Target): Mention that
GDB can access program files from remote targets that support
qXfer:exec-file:read and Host I/O packets.
gdb/testsuite/ChangeLog:
* gdb.server/server-exec-info.exp: Inhibit GDB from accessing
the main executable over the remote protocol.
|
|
Fixes:
-FAIL: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint created
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint on marker is installed
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1
-FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created
-FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created
+PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created
+PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created
These tests do something like this:
#0 - start gdb/gdbserver normally
#1 - setup some things in the debug session
#2 - disconnect from gdbserver
#3 - restart gdb
#4 - reconnect to gdbserver
The problem is that the native-extended-gdbserver board always spawns
a new gdbserver instance in #3 (and has gdb connect to that). So when
the test gets to #4, it connects to that new instance instead of the
old one:
(gdb) spawn ../gdbserver/gdbserver --multi :2354
Listening on port 2354
target extended-remote localhost:2354
Remote debugging using localhost:2354
...
spawn ../gdbserver/gdbserver --multi :2355
Listening on port 2355
47-target-select extended-remote localhost:2355
=tsv-created,name="trace_timestamp",initial="0"\n
47^connected
(gdb)
...
47-target-select extended-remote localhost:2355
47^connected
(gdb)
FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created
FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created
testsuite/ChangeLog:
2015-04-16 Pedro Alves <palves@redhat.com>
* boards/native-extended-gdbserver.exp (mi_gdb_start): Don't start
a new gdbserver if gdbserver_reconnect_p is set.
|
|
Commit 6423214f (testsuite: Don't use expect_background to reap
gdbserver) broke a couple tests that set gdbserver_reconnect_p and
restart gdb before reconnecting, because a gdb_exit (e.g., through
clean_restart) exits gdbserver unconditionally.
Fixes, with --target_board=native-gdbserver:
-FAIL: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint created
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint on marker is installed
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1
-FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created
-FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created
+PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created
+PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created
gdb/testsuite/
2015-04-16 Pedro Alves <palves@redhat.com>
* lib/gdbserver-support.exp (gdb_exit): If gdbserver_reconnect_p
is set, don't exit gdbserver.
|
|
The test case s390-vregs.exp yields compile errors on 31-bit targets
as well as when using a GCC that defaults to an older "-march=". This
patch fixes these issues.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-vregs.S (change_vrs): Replace exrl by an
appropriate .insn, such that an older assembler can be used.
* gdb.arch/s390-vregs.exp: Add the compile flag -mzarch, to enable
the z/Architecture instruction set on 31-bit targets as well.
|
|
On s390x targets some of the Go test cases fail because the first
breakpoint happens to be at the same spot as the breakpoint at
main.main. When such a test case tries to continue to the first
breakpoint, the program runs until the end instead, and the test fails
like this:
FAIL: gdb.go/handcall.exp: Going to first breakpoint (the program exited)
This patch removes all the handling related to the first breakpoint in
those cases. After applying the patch, the tests run successfully on
s390x.
gdb/testsuite/ChangeLog:
* gdb.go/handcall.exp: Remove all logic related to the first
breakpoint and rely on go_runto_main instead.
* gdb.go/strings.exp: Likewise.
* gdb.go/unsafe.exp: Likewise.
* gdb.go/hello.exp: Likewise. Also rename the remaining
breakpoint marker to "breakpoint 1".
* gdb.go/handcall.go: Remove comment "set breakpoint 1 here".
* gdb.go/strings.go: Likewise.
* gdb.go/unsafe.go: Likewise.
* gdb.go/hello.go: Likewise. Also remove the second occurrence of
"set breakpoint 2 here" and rename the remaining breakpoint marker
to "breakpoint 1".
|
|
Some missing parentheses and one itertools.imap (Py2) vs map (Py3) issue.
gdb/ChangeLog:
* python/lib/gdb/command/unwinders.py: Add parentheses.
gdb/testsuite/ChangeLog:
* gdb.python/py-framefilter.py (ErrorFilter.filter): Use map function
if itertools.imap is not present.
* gdb.python/py-objfile.exp: Add parentheses.
* gdb.python/py-type.exp: Same.
* gdb.python/py-unwind-maint.py: Same.
|
|
I see many fails in gdb.dwarf2/dynarr-ptr.exp on arm-linux target,
started from this
print foo.three_ptr.all^M
Cannot access memory at address 0x107c8^M
(gdb) FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr.all
print foo.three_ptr.all(1)^M
Cannot access memory at address 0x107c8
It turns out that ":$ptr_size" is used incorrectly.
array_ptr_label: DW_TAG_pointer_type {
{DW_AT_byte_size :$ptr_size }
^^^^^^^^^^
{DW_AT_type :$array_label}
}
Since the FORM isn't given, and it starts with the ":", it is regarded
as a label reference by dwarf assembler. The generated asm file on
x86_64 is
.uleb128 6 /* Abbrev (DW_TAG_pointer_type) */
.4byte 8 - .Lcu1_begin <----- WRONG
.4byte .Llabel2 - .Lcu1_begin
Looks .Lcu1_begin is 0 on x86_64 and that is why this test passes on
x86_64. On arm, .Lcu1_begin is an address somewhere, and the value
of DW_AT_byte_size is a very large number, so memory read request
of such large length failed.
This patch is to remove ":" and set the form explicitly. The generated
asm file on x86_64 becomes
.uleb128 6 /* Abbrev (DW_TAG_pointer_type) */
.byte 8
.4byte .Llabel2 - .Lcu1_begin
gdb/testsuite:
2015-04-15 Yao Qi <yao.qi@linaro.org>
* gdb.dwarf2/dynarr-ptr.exp (assemble): Use $ptr_size instead
of ":$ptr_size" and set its form explicitly.
|
|
I see the following two timeout fails on pandaboard (arm-linux target),
FAIL: gdb.base/watch-bitfields.exp: -location watch against bitfields: continue until exit (timeout)
FAIL: gdb.base/watch-bitfields.exp: regular watch against bitfields: continue until exit (timeout)
In this test, more than one watchpoint is used, so the following
watchpoint requests fall back to software watchpoint, so that GDB
will single step all the way and it is very slow.
This patch is to copy the fix from
[PATCH] GDB/testsuite: Correct gdb.base/watchpoint-solib.exp timeout tweak
https://sourceware.org/ml/gdb-patches/2014-07/msg00716.html
I find the left-over of this patch review is to factor out code into
a procedure, so I do that in this patch.
Re-run tests watch-bitfields.exp, watchpoint-solib.exp, sigall-reverse.exp,
and until-precsave.exp on pandaboard, no regression.
gdb/testsuite:
2015-04-15 Pedro Alves <palves@redhat.com>
Yao Qi <yao.qi@linaro.org>
* gdb.base/watch-bitfields.exp (test_watch_location): Increase
timeout by factor of 4.
(test_regular_watch): Likewise.
* gdb.base/watchpoint-solib.exp: Use with_timeout_factor.
* gdb.reverse/sigall-reverse.exp: Likewise.
* gdb.reverse/until-precsave.exp: Likewise.
* lib/gdb.exp (with_timeout_factor): New proc.
(gdb_expect): Move some code to ...
(get_largest_timeout): ... here. New procedure.
|
|
Reinstate test message and replace hardcoded test command with a variable.
gdb/testsuite/ChangeLog:
2015-04-14 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/bp-permanent.exp (test): Reinstate correct test message.
|
|
This testcase does not work as expected in QEMU (aarch64 QEMU in my case). It
fails when trying to manually write the breakpoint instruction to a certain
PC address.
(gdb) p /x addr_bp[0] = buffer[0]^M
Cannot access memory at address 0x400834^M
(gdb) PASS: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0: setup: p /x addr_bp[0] = buffer[0]
p /x addr_bp[1] = buffer[1]^M
Cannot access memory at address 0x400835^M
(gdb) PASS: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0: setup: p /x addr_bp[1] = buffer[1]
p /x addr_bp[2] = buffer[2]^M
Cannot access memory at address 0x400836^M
(gdb) PASS: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0: setup: p /x addr_bp[2] = buffer[2]
p /x addr_bp[3] = buffer[3]^M
Cannot access memory at address 0x400837^M
(gdb) PASS: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0: setup: p /x addr_bp[3] = buffer[3]
The following patch prevents a number of failures by detecting this and bailing out in case the target has such a restriction. Writing to .text from within the program isn't any better. It just leads to a SIGSEGV.
Before the patch:
=== gdb Summary ===
After the patch:
=== gdb Summary ===
gdb/testsuite/ChangeLog:
2015-04-13 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/bp-permanent.exp (test): Handle the case of being unable
to write to the .text section.
|
|
This testcase seems to assume the target is running Linux, so bare metal,
simulators and other debugging stubs running different OS' will have a
hard time executing some of the commands the testcase issues.
Even restricting the testcase to Linux systems (which the patch below does),
there are still problems with, say, QEMU not providing PID information when
"info inferior" is issued. As a consequence, the subsequent tests will either
fail or will not make much sense.
The attached patch checks if PID information is available. If not, it just
bails out and avoids running into a number of failures.
gdb/testsuite/ChangeLog:
2015-04-13 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/coredump-filter.exp: Restrict test to Linux systems only.
Handle the case of targets that do not provide PID information.
|
|
I see the error when I run gdb-sigterm.exp with native-gdbserver
on x86_64-linux.
infrun: prepare_to_wait^M
Cannot execute this command while the target is running.^M
Use the "interrupt" command to stop the target^M
and then try again.^M
gdb.base/gdb-sigterm.exp: expect eof #0: got eof
gdb.base/gdb-sigterm.exp: expect eof #0: stepped 12 times
ERROR OCCURED: : spawn id exp8 not open
while executing
"expect {
-i exp8 -timeout 10
-re "$gdb_prompt $" {
exp_continue
}
-i "$server_spawn_id" eof {
wait -i $expect_out(spawn_id)
unse..."
("uplevel" body line 1)
invoked from within
In gdb-sigterm.exp, SIGTERM is sent to GDB and it exits. However,
Dejagnu or tcl doesn't know this.
This patch is to catch the exception, but error messages are still
shown in the console and gdb.log. In order to avoid this, we also
replace gdb_expect with expect.
gdb/testsuite:
2015-04-13 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp (gdb_exit): Catch exception
and use expect instead of gdb_expect.
|
|
This commit renames the global array variable "addr" to an unique name
"coredump_var_addr" in the test gdb.base/coredump-filter.exp. This is
needed because global arrays can have name conflicts between tests.
For example, this specific test was conflicting with dmsym.exp,
causing errors like:
ERROR: tcl error sourcing ../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp.
ERROR: can't set "addr": variable is array
while executing
"set addr "0x\[0-9a-zA-Z\]+""
(file "../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp" line 45)
invoked from within
"source ../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source ../../../../../binutils-gdb/gdb/testsuite/gdb.base/dmsym.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
This problem was reported by Yao Qi at:
<https://sourceware.org/ml/gdb-patches/2015-04/msg00373.html>
Message-Id: <1428666671-12926-1-git-send-email-qiyaoltc@gmail.com>
gdb/testsuite/ChangeLog:
2015-04-13 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/coredump-filter.exp: Rename variable "addr" to
"coredump_var_addr" to avoid naming conflict with other testcases.
|
|
gdb/testsuite/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp: Use
gdb_test_sequence and gdb_assert.
|
|
Diffing test results, I noticed:
-PASS: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: b *0x0000000000400811 thread 1
+PASS: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: b *0x00000000004007d1 thread 1
gdb/testsuite/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Use
test messages that don't include the breakpoint address.
|
|
Hi,
ARM linux kernel has some requirements on the address/length setting
for HW breakpoints/watchpoints, but watchpoint-reuse-slot.exp doesn't
consider them and sets HW points on various addresses. Many fails
are causes as a result:
stepi^M
Warning:^M
Could not insert hardware watchpoint 20.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) FAIL: gdb.base/watchpoint-reuse-slot.exp: always-inserted off: watch x watch: : width 2, iter 2: base + 1: stepi advanced
watch *(buf.byte + 2 + 1)@2^M
Hardware watchpoint 388: *(buf.byte + 2 + 1)@2^M
Warning:^M
Could not insert hardware watchpoint 388.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) FAIL: gdb.base/watchpoint-reuse-slot.exp: always-inserted on: watch x watch: : width 2, iter 2: base + 1: watch *(buf.byte + 2 + 1)@2
This patch is to reflect kernel requirements in watchpoint-reuse-slot.exp
in order to skip some tests.
gdb/testsuite:
2015-04-10 Yao Qi <yao.qi@linaro.org>
* gdb.base/watchpoint-reuse-slot.exp (valid_addr_p): Return
false for some offset and width combinations which aren't
supported by linux kernel.
|
|
stepping
These tests exercise the infrun.c:proceed code that needs to know to
start new step overs (along with switch_back_to_stepped_thread, etc.).
That code is tricky to get right in the multitude of possible
combinations (at least):
(native | remote)
X (all-stop | all-stop-but-target-always-in-non-stop)
X (displaced-stepping | in-line step-over).
The first two above are properties of the target, but the different
step-over-breakpoint methods should work with any target that supports
them. This patch makes sure we always test both methods on all
targets.
Tested on x86-64 Fedora 20.
gdb/testsuite/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-lands-on-breakpoint.exp (do_test): New
procedure, factored out from ...
(top level): ... here. Add "set displaced-stepping" testing axis.
* gdb.threads/step-over-trips-on-watchpoint.exp (do_test): New
parameter "displaced". Use it.
(top level): Use foreach and add "set displaced-stepping" testing
axis.
|
|
This test is currently failing like this on (at least) PPC64 and s390x:
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: next: next
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: with thread-specific bp: step: step
FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: with thread-specific bp: next: next
gdb.log:
(gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: set scheduler-locking off
step
wait_threads () at ../../../src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:49
49 return 1; /* in wait_threads */
(gdb) FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step
The problem is that the test assumes that both the "watch_me = 1;" and
the "other = 1;" lines compile to a single instruction each, which
happens to be true on x86, but no necessarily true everywhere else.
The result is that the test doesn't really test what it wants to test.
Fix it by looking for the instruction that triggers the watchpoint.
gdb/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-trips-on-watchpoint.c (child_function):
Remove comment.
* gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Find
both the address of the instruction that triggers the watchpoint
and the address of the instruction immediately after, and use
those addresses for the test. Fix comment.
|
|
TL;DR:
When stepping over a breakpoint with displaced stepping, the core must
be notified of all signals, otherwise the displaced step fixup code
confuses a breakpoint trap in the signal handler for the expected trap
indicating the displaced instruction was single-stepped
normally/successfully.
Detailed version:
Running sigstep.exp with displaced stepping on, against my x86
software single-step branch, I got:
FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step
FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next
FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue
Turning on debug logs, we see:
(gdb) step
infrun: clear_proceed_status_thread (process 32147)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842
displaced: stepping process 32147 now
displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0
displaced: %rip-relative addressing used.
displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c
displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00
displaced: displaced pc to 0x400622
displaced: run 0x400622: c7 81 1c 08
LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147
LLR: PTRACE_CONT process 32147, 0 (resume event thread)
linux_nat_wait: [process -1], [TARGET_WNOHANG]
LLW: enter
LNW: waitpid(-1, ...) returned 32147, No child processes
LLW: waitpid 32147 received Alarm clock (stopped)
LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle')
LNW: waitpid(-1, ...) returned 0, No child processes
LLW: exit (ignore)
sigchld
infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = ignore
infrun: TARGET_WAITKIND_IGNORE
infrun: prepare_to_wait
linux_nat_wait: [process -1], [TARGET_WNOHANG]
LLW: enter
LNW: waitpid(-1, ...) returned 32147, No child processes
LLW: waitpid 32147 received Trace/breakpoint trap (stopped)
CSBB: process 32147 stopped by software breakpoint
LNW: waitpid(-1, ...) returned 0, No child processes
LLW: trap ptid is process 32147.
LLW: exit
infrun: target_wait (-1.0.0, status) =
infrun: 32147.32147.0 [process 32147],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
displaced: restored process 32147 0x400622
displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ...
displaced: restoring reg 2 to 0x3615eafd37
displaced: relocated %rip from 0x400717 to 0x400937
infrun: stop_pc = 0x400937
infrun: delayed software breakpoint trap, ignoring
infrun: no line number info
infrun: stop_waiting
0x0000000000400937 in __dso_handle ()
1: x/i $pc
=> 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1
(gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step
What should have happened is that the breakpoint hit in the signal
handler should have been presented to the user. But note that
"preempt 'handle'" -- what happened instead is that
displaced_step_fixup confused the breakpoint in the signal handler for
the expected SIGTRAP indicating the displaced instruction was
single-stepped normally/successfully.
This should be affecting all software single-step targets in the same
way.
The fix is to make sure the core sees all signals when displaced
stepping, just like we already must see all signals when doing an
stepping over a breakpoint in-line. We now get:
infrun: target_wait (-1.0.0, status) =
infrun: 570.570.0 [process 570],
infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM
infrun: TARGET_WAITKIND_STOPPED
displaced: restored process 570 0x400622
infrun: stop_pc = 0x400842
infrun: random signal (GDB_SIGNAL_ALRM)
infrun: signal arrived while stepping over breakpoint
infrun: inserting step-resume breakpoint at 0x400842
infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842
LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570
LLR: PTRACE_CONT process 570, Alarm clock (resume event thread)
infrun: prepare_to_wait
linux_nat_wait: [process -1], [TARGET_WNOHANG]
LLW: enter
LNW: waitpid(-1, ...) returned 0, No child processes
LLW: exit (ignore)
infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = ignore
sigchld
infrun: TARGET_WAITKIND_IGNORE
infrun: prepare_to_wait
linux_nat_wait: [process -1], [TARGET_WNOHANG]
LLW: enter
LNW: waitpid(-1, ...) returned 570, No child processes
LLW: waitpid 570 received Trace/breakpoint trap (stopped)
CSBB: process 570 stopped by software breakpoint
LNW: waitpid(-1, ...) returned 0, No child processes
LLW: trap ptid is process 570.
LLW: exit
infrun: target_wait (-1.0.0, status) =
infrun: 570.570.0 [process 570],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400717
infrun: BPSTAT_WHAT_STOP_NOISY
infrun: stop_waiting
Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35
35 done = 1;
Hardware single-step targets already behave this way, because the
Linux backends (both native and gdbserver) always report signals to
the core if the thread was single-stepping.
As mentioned in the new comment in do_target_resume, we can't fix this
by instead making the displaced_step_fixup phase skip fixing up the PC
if the single step stopped somewhere we didn't expect. Here's what
the backtrace would look like if we did that:
Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35
35 done = 1;
1: x/i $pc
=> 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done>
(gdb) bt
#0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35
#1 <signal handler called>
#2 0x0000000000400622 in _start ()
(gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace
gdb/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
* infrun.c (displaced_step_in_progress): New function.
(do_target_resume): Advise target to report all signals if
displaced stepping.
gdb/testsuite/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
* gdb.base/sigstep.exp (breakpoint_to_handler)
(breakpoint_to_handler_entry): New parameter 'displaced'. Use it.
Test "backtrace" in handler.
(breakpoint_over_handler): New parameter 'displaced'. Use it.
(top level): Add new "displaced" test axis to
breakpoint_to_handler, breakpoint_to_handler_entry and
breakpoint_over_handler.
|
|
The problem is that with hardware step targets and displaced stepping,
"signal FOO" when stopped at a breakpoint steps the breakpoint
instruction at the same time it delivers a signal. This results in
tp->stepped_breakpoint set, but no step-resume breakpoint set. When
the next stop event arrives, GDB crashes. Irrespective of whether we
should do something more/different to step past the breakpoint in this
scenario (e.g., PR 18225), it's just wrong to assume there'll be a
step-resume breakpoint set (and was not the original intention).
gdb/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
PR gdb/18216
* infrun.c (process_event_stop_test): Don't assume a step-resume
is set if tp->stepped_breakpoint is true.
gdb/testsuite/ChangeLog:
2015-04-10 Pedro Alves <palves@redhat.com>
PR gdb/18216
* gdb.threads/multiple-step-overs.exp: Remove expected eof.
|
|
Recent patch series "V2 All-stop on top of non-stop" causes a SIGSEGV
in the test case,
> -PASS: gdb.base/info-shared.exp: continue to breakpoint: library function #4
> +FAIL: gdb.base/info-shared.exp: continue to breakpoint: library function #4
>
> continue^M
> Continuing.^M
> ^M
> Program received signal SIGSEGV, Segmentation fault.^M
> 0x40021564 in ?? () gdb/testsuite/gdb.base/info-shared-solib1.so^M
> (gdb) FAIL: gdb.base/info-shared.exp: continue to breakpoint: library function #4
and an ARM displaced stepping bug is exposed. It can be reproduced by
the modified gdb.arch/arm-disp-step.exp as below,
continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0xa713cfcc in ?? ()^M
(gdb) FAIL: gdb.arch/arm-disp-step.exp: continue to breakpoint: continue to test_add_rn_pc_end
This patch is to fix it.
gdb:
2015-04-10 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (install_alu_reg): Update comment.
(thumb_copy_alu_reg): Remove local variable rn. Update
debugging message. Use r2 instead of r1 in the modified
instruction.
gdb/testsuite:
2015-04-10 Yao Qi <yao.qi@linaro.org>
* gdb.arch/arm-disp-step.S (main): Call test_add_rn_pc.
(test_add_rn_pc): New function.
* gdb.arch/arm-disp-step.exp (test_add_rn_pc): New proc.
(top level): Invoke test_add_rn_pc.
|
