Age | Commit message (Collapse) | Author | Files | Lines |
|
Even when referenced types are dynamic, the corresponding referencing
type should not be considered as dynamic: it's only a pointer. This
prevents reference type for values not in memory to be resolved.
gdb/ChangeLog:
* gdbtypes.c (is_dynamic_type_internal): Remove special handling
of TYPE_CODE_REF types so that they are not considered as
dynamic depending on the referenced type.
(resolve_dynamic_type_internal): Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/funcall_ref.exp: New file.
* gdb.ada/funcall_ref/foo.adb: New file.
|
|
I see these two fails in no-unwaited-for-left.exp in remote testing
for aarch64-linux target.
...
continue
Continuing.
warning: Remote failure reply: E.No unwaited-for children left.
[Thread 1084] #2 stopped.
(gdb) FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when thread 2 exits
....
continue
Continuing.
warning: Remote failure reply: E.No unwaited-for children left.
[Thread 1081] #1 stopped.
(gdb) FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits
I checked the gdb.log on buildbot, and find that these two fails also
appear on Debian-i686-native-extended-gdbserver and Fedora-ppc64be-native-gdbserver-m64.
I recall that they are about local/remote parity, and related RSP is missing.
There has been already a PR 14618 about it. This patch is to kfail them
on remote target.
gdb/testsuite:
2015-04-02 Yao Qi <yao.qi@linaro.org>
* gdb.threads/no-unwaited-for-left.exp: Set up kfail if target
is remote.
|
|
This commit makes GDB default to a sysroot of "target:".
One testcase needed updating as a result of this change.
gdb/ChangeLog:
* main.c (captured_main): Set gdb_sysroot to "target:"
if not otherwise set.
gdb/testsuite/ChangeLog:
* gdb.base/break-probes.exp: Cope with "target:" sysroot.
|
|
gdb/ChangeLog:
* Makefile.in (SUBDIR_PYTHON_OBJS): Add py-unwind.o.
(SUBDIR_PYTHON_SRCS): Add py-unwind.c.
(py-unwind.o): New recipe.
* NEWS: mention Python frame unwinding.
* data-directory/Makefile.in (PYTHON_FILE_LIST): Add
gdb/unwinder.py and gdb/command/unwinder.py
* python/lib/gdb/__init__.py (packages): Add frame_unwinders
list.
(execute_unwinders): New function.
* python/lib/gdb/command/unwinders.py: New file.
* python/lib/gdb/unwinder.py: New file.
* python/py-objfile.c (objfile_object): Add frame_unwinders field.
(objfpy_dealloc): Decrement frame_unwinders reference count.
(objfpy_initialize): Create frame_unwinders list.
(objfpy_get_frame_unwinders): New function.
(objfpy_set_frame_unwinders): Ditto.
(objfile_getset): Add frame_unwinders attribute to Objfile.
* python/py-progspace.c (pspace_object): Add frame_unwinders field.
(pspy_dealloc): Decrement frame_unwinders reference count.
(pspy_initialize): Create frame_unwinders list.
(pspy_get_frame_unwinders): New function.
(pspy_set_frame_unwinders): Ditto.
(pspy_getset): Add frame_unwinders attribute to gdb.Progspace.
* python/py-unwind.c: New file.
* python/python-internal.h (pspy_get_name_unwinders): New prototype.
(objpy_get_frame_unwinders): New prototype.
(gdbpy_initialize_unwind): New prototype.
* python/python.c (gdbpy_apply_type_printers): Call
gdbpy_initialize_unwind.
gdb/doc/ChangeLog:
* doc/python.texi (Writing a Frame Unwinder in Python): Add
section.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind-maint.c: New file.
* gdb.python/py-unwind-maint.exp: New test.
* gdb.python/py-unwind-maint.py: New file.
* gdb.python/py-unwind.c: New file.
* gdb.python/py-unwind.exp: New test.
* gdb.python/py-unwind.py: New test.
|
|
If interrupt_and_wait manages to trigger the FAIL path, we get:
ERROR OCCURED: can't read "test": no such variable
gdb/testsuite/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
* gdb.threads/manythreads.exp (interrupt_and_wait): Pass $message
to fail instead of non-existent $test.
|
|
Running attach.exp with a DejaGnu board that sets GDBFLAGS, like
e.g.,:
set GDBFLAGS "-ex \"set displaced off\""
fails with (line breaks added for clarity):
(gdb) PASS: gdb.base/attach.exp: starting with --pid
Executing on build: kill -9 3537 (timeout = 300)
spawn -ignore SIGHUP kill -9 3537
spawn of build/gdb/gdb -nw -nx \
-data-directory build/gdb/testsuite/../data-directory \
-ex "set displaced off"-iex "set height 0" -iex "set width 0" \
^^^^^^^^
--pid=4468 -ex "start" failed
ERROR: Spawning build/gdb/gdb failed.
UNRESOLVED: gdb.base/attach.exp: cmdline attach run: run to prompt
gdb/testsuite/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_spawn_with_cmdline_opts): Append space to
GDBFLAGS if not empty.
|
|
gdb/testsuite/ChangeLog:
* gdb.ada/complete.exp: Remove "multi_line".
* gdb.ada/info_exc.exp: Remove "multi_line".
* gdb.ada/packed_tagged.exp: Remove "multi_line".
* gdb.ada/ptype_field.exp: Remove "multi_line".
* gdb.ada/sym_print_name.exp: Remove "multi_line".
* gdb.ada/tagged.exp: Remove "multi_line".
* gdb.btrace/buffer-size.exp: Replace [join [list ...]] with
[multi_line ...]
* gdb.btrace/delta.exp: Likewise.
* gdb.btrace/exception.exp: Likewise.
* gdb.btrace/function_call_history.exp: Likewise.
* gdb.btrace/instruction_history.exp: Likewise.
* gdb.btrace/nohist.exp: Likewise.
* gdb.btrace/record_goto.exp: Likewise.
* gdb.btrace/segv.exp: Likewise.
* gdb.btrace/stepi.exp: Likewise.
* gdb.btrace/tailcall.exp: Likewise.
* gdb.btrace/unknown_functions.exp: Likewise.
* gdb.dwarf2/dw2-undefined-ret-addr.exp: Likewise.
* lib/gdb.exp: Add the "multi_line" helper.
|
|
On GNU/Linux, if the target reuses the TID of a thread that GDB still
has in its list marked as THREAD_EXITED, GDB crashes, like:
(gdb) continue
Continuing.
src/gdb/thread.c:789: internal-error: set_running: Assertion `tp->state != THREAD_EXITED' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_reuse_time (GDB internal error)
Here:
(top-gdb) bt
#0 internal_error (file=0x953dd8 "src/gdb/thread.c", line=789, fmt=0x953da0 "%s: Assertion `%s' failed.")
at src/gdb/common/errors.c:54
#1 0x0000000000638514 in set_running (ptid=..., running=1) at src/gdb/thread.c:789
#2 0x00000000004bda42 in linux_handle_extended_wait (lp=0x16f5760, status=0, stopping=0) at src/gdb/linux-nat.c:2114
#3 0x00000000004bfa24 in linux_nat_filter_event (lwpid=20570, status=198015) at src/gdb/linux-nat.c:3127
#4 0x00000000004c070e in linux_nat_wait_1 (ops=0xe193d0, ptid=..., ourstatus=0x7fffffffd2c0, target_options=1) at src/gdb/linux-nat.c:3478
#5 0x00000000004c1015 in linux_nat_wait (ops=0xe193d0, ptid=..., ourstatus=0x7fffffffd2c0, target_options=1) at src/gdb/linux-nat.c:3722
#6 0x00000000004c92d2 in thread_db_wait (ops=0xd80b60 <thread_db_ops>, ptid=..., ourstatus=0x7fffffffd2c0, options=1)
at src/gdb/linux-thread-db.c:1525
#7 0x000000000066db43 in delegate_wait (self=0xd80b60 <thread_db_ops>, arg1=..., arg2=0x7fffffffd2c0, arg3=1) at src/gdb/target-delegates.c:116
#8 0x000000000067e54b in target_wait (ptid=..., status=0x7fffffffd2c0, options=1) at src/gdb/target.c:2206
#9 0x0000000000625111 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:3275
#10 0x0000000000648a3b in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56
#11 0x00000000004c2ecb in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4655
I managed to come up with a test that reliably reproduces this. It
spawns enough threads for the pid number space to wrap around, so
could potentially take a while. On my box that's 4 seconds; on
gcc110, a PPC box which has max_pid set to 65536, it's over 10
seconds. So I made the test compute how long that would take, and cap
the time waited if it would be unreasonably long.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
* linux-thread-db.c (record_thread): Readd the thread to gdb's
list if it was marked exited.
gdb/testsuite/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
* gdb.threads/tid-reuse.c: New file.
* gdb.threads/tid-reuse.exp: New file.
|
|
This patch, as the subject says, extends GDB so that it is able to use
the contents of the file /proc/PID/coredump_filter when generating a
corefile. This file contains a bit mask that is a representation of
the different types of memory mappings in the Linux kernel; the user
can choose to dump or not dump a certain type of memory mapping by
enabling/disabling the respective bit in the bit mask. Currently,
here is what is supported:
bit 0 Dump anonymous private mappings.
bit 1 Dump anonymous shared mappings.
bit 2 Dump file-backed private mappings.
bit 3 Dump file-backed shared mappings.
bit 4 (since Linux 2.6.24)
Dump ELF headers.
bit 5 (since Linux 2.6.28)
Dump private huge pages.
bit 6 (since Linux 2.6.28)
Dump shared huge pages.
(This table has been taken from core(5), but you can also read about it
on Documentation/filesystems/proc.txt inside the Linux kernel source
tree).
The default value for this file, used by the Linux kernel, is 0x33,
which means that bits 0, 1, 4 and 5 are enabled. This is also the
default for GDB implemented in this patch, FWIW.
Well, reading the file is obviously trivial. The hard part, mind you,
is how to determine the types of the memory mappings. For that, I
extended the code of gdb/linux-tdep.c:linux_find_memory_regions_full and
made it rely *much more* on the information gathered from
/proc/<PID>/smaps. This file contains a "verbose dump" of the
inferior's memory mappings, and we were not using as much information as
we could from it. If you want to read more about this file, take a look
at the proc(5) manpage (I will also write a blog post soon about
everything I had to learn to get this patch done, and when I it is ready
I will post it here).
With Oleg Nesterov's help, we could improve the current algorithm for
determining whether a memory mapping is anonymous/file-backed,
private/shared. GDB now also respects the MADV_DONTDUMP flag and does
not dump the memory mapping marked as so, and will always dump
"[vsyscall]" or "[vdso]" mappings (just like the Linux kernel).
In a nutshell, what the new code is doing is:
- If the mapping is associated to a file whose name ends with
" (deleted)", or if the file is "/dev/zero", or if it is "/SYSV%08x"
(shared memory), or if there is no file associated with it, or if
the AnonHugePages: or the Anonymous: fields in the /proc/PID/smaps
have contents, then GDB considers this mapping to be anonymous.
There is a special case in this, though: if the memory mapping is a
file-backed one, but *also* contains "Anonymous:" or
"AnonHugePages:" pages, then GDB considers this mapping to be *both*
anonymous and file-backed, just like the Linux kernel does. What
that means is simple: this mapping will be dumped if the user
requested anonymous mappings *or* if the user requested file-backed
mappings to be present in the corefile.
It is worth mentioning that, from all those checks described above,
the most fragile is the one to see if the file name ends with
" (deleted)". This does not necessarily mean that the mapping is
anonymous, because the deleted file associated with the mapping may
have been a hard link to another file, for example. The Linux
kernel checks to see if "i_nlink == 0", but GDB cannot easily do
this check (as it has been discussed, GDB would need to run as root,
and would need to check the contents of the /proc/PID/map_files/
directory in order to determine whether the deleted was a hardlink
or not). Therefore, we made a compromise here, and we assume that
if the file name ends with " (deleted)", then the mapping is indeed
anonymous. FWIW, this is something the Linux kernel could do
better: expose this information in a more direct way.
- If we see the flag "sh" in the VmFlags: field (in /proc/PID/smaps),
then certainly the memory mapping is shared (VM_SHARED). If we have
access to the VmFlags, and we don't see the "sh" there, then
certainly the mapping is private. However, older Linux kernels (see
the code for more details) do not have the VmFlags field; in that
case, we use another heuristic: if we see 'p' in the permission
flags, then we assume that the mapping is private, even though the
presence of the 's' flag there would mean VM_MAYSHARE, which means
the mapping could still be private. This should work OK enough,
however.
Finally, it is worth mentioning that I added a new command, 'set
use-coredump-filter on/off'. When it is 'on', it will read the
coredump_filter' file (if it exists) and use its value; otherwise, it
will use the default value mentioned above (0x33) to decide which memory
mappings to dump.
gdb/ChangeLog:
2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Oleg Nesterov <oleg@redhat.com>
PR corefiles/16092
* linux-tdep.c: Include 'gdbcmd.h' and 'gdb_regex.h'.
New enum identifying the various options of the coredump_filter
file.
(struct smaps_vmflags): New struct.
(use_coredump_filter): New variable.
(decode_vmflags): New function.
(mapping_is_anonymous_p): Likewise.
(dump_mapping_p): Likewise.
(linux_find_memory_regions_full): New variables
'coredumpfilter_name', 'coredumpfilterdata', 'pid', 'filterflags'.
Removed variable 'modified'. Read /proc/<PID>/smaps file; improve
parsing of its information. Implement memory mapping filtering
based on its contents.
(show_use_coredump_filter): New function.
(_initialize_linux_tdep): New command 'set use-coredump-filter'.
* NEWS: Mention the possibility of using the
'/proc/PID/coredump_filter' file when generating a corefile.
Mention new command 'set use-coredump-filter'.
gdb/doc/ChangeLog:
2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com>
PR corefiles/16092
* gdb.texinfo (gcore): Mention new command 'set
use-coredump-filter'.
(set use-coredump-filter): Document new command.
gdb/testsuite/ChangeLog:
2015-03-31 Sergio Durigan Junior <sergiodj@redhat.com>
PR corefiles/16092
* gdb.base/coredump-filter.c: New file.
* gdb.base/coredump-filter.exp: Likewise.
|
|
Example of use:
Dwarf::assemble "foo.s" {
build_id 0102030405060708
declare_labels L;
cu {is_64 0 version 4 addr_size 8} {
DW_TAG_compile_unit {
{DW_AT_stmt_list $L DW_FORM_sec_offset}
} {
DW_TAG_subprogram {
# We can now reference the source file.
{DW_AT_decl_file 1 DW_FORM_data1}
}
}
}
lines {is_64 0 version 2 addr_size 8} L {
include_dir "foo"
include_dir "bar"
file_name "foo.c" 1
file_name "bar.c" 1
file_name "baz.c" 2
}
}
Signed-off-by: Petr Machata <pmachata@redhat.com>
|
|
Exactly like x86_64-*-mingw, SYMBOL_PREFIX should not be set to "_" for
x86_64_*_cygwin
gdb/testuite/ChangeLog:
* lib/gdb.exp (gdb_target_symbol_prefix_flags): Don't set
SYMBOL_PREFIX for x86_64-*-cygwin.
|
|
Variables with a DW_AT_const_value but without a DW_AT_location were not
getting added to the partial symbol table. They are added to the full
symbol table, however, when the compilation unit's psymtabs are
expanded.
Before:
(gdb) p one
No symbol "one" in current context.
(gdb) mt flush-symbol-cache
(gdb) mt expand one.c
(gdb) p one
$1 = 1
After:
(gdb) p one
$1 = 1
To the user it's pretty strange, as depending on whether tab completion
has forced expansion of all CUs or not the lookup might succeed, or not
if the failure was already added to the symbol cache.
This commit simply makes sure to add constants to the partial symbol
tables.
gdb/testsuite/ChangeLog:
PR symtab/18148
* gdb.dwarf2/dw2-intercu.S (one, two): Add variables that have a
const_value but not a location.
* gdb.dwarf2/dw2-intercu.exp: Add tests that constants without
location defined in non-main CUs are visible.
gdb/ChangeLog:
PR symtab/18148
* dwarf2read.c (struct partial_die_info): Add has_const_value
member.
(add_partial_symbol): Don't punt on symbols that have const_value
attributes.
(read_partial_die): Detect DW_AT_const_value.
|
|
break-asm-file.exp has some manually written dwarf to create some line
number entries like this,
[0x0000013d] Extended opcode 2: set Address to 0x40053f
[0x00000144] Advance Line by 4 to 7
[0x00000146] Copy
[0x00000147] Extended opcode 2: set Address to 0x400541
[0x0000014e] Advance Line by 1 to 8
[0x00000150] Copy
[0x00000151] Extended opcode 2: set Address to 0x400547
[0x00000158] Extended opcode 1: End of Sequence
0x40053f is the start address of function func, and is mapped to line
7. 0x400541 is within function func, and is mapped to line 8.
(gdb) disassemble /r 0x40053f,+8
Dump of assembler code from 0x40053f to 0x400547:
0x000000000040053f <func+0>: 00 00 add %al,(%rax)
0x0000000000400541 <func+2>: 00 00 add %al,(%rax)
0x0000000000400543 <func+4>: 00 00 add %al,(%rax)
0x0000000000400545 <func+6>: 00 00 add %al,(%rax)
in the following test,
(gdb) break a/break-asm-file0.s:func
Breakpoint 1 at 0x40053f: file a/break-asm-file0.s, line 7.
As we can see, breakpoint is set at the start address of function func
on x86, which means no prologue is skipped. On other targets, such as
arm and aarch64, breakpoint is set at the address *after* the start
address, which is mapped to line 8. Then test fails.
In fact, it is lucky this test doesn't fail on x86 and x86_64, whose
gdbarch method skip_prologue doesn't reply on skip_prologue_using_sal
if producer isn't clang.
if (find_pc_partial_function (start_pc, NULL, &func_addr, NULL))
{
CORE_ADDR post_prologue_pc
= skip_prologue_using_sal (gdbarch, func_addr);
struct compunit_symtab *cust = find_pc_compunit_symtab (func_addr);
/* Clang always emits a line note before the prologue and another
one after. We trust clang to emit usable line notes. */
if (post_prologue_pc
&& (cust != NULL
&& COMPUNIT_PRODUCER (cust) != NULL
&& startswith (COMPUNIT_PRODUCER (cust), "clang ")))
return max (start_pc, post_prologue_pc);
}
so it doesn't return and go further to prologue analyser. Since ".int 0"
isn't an instruction of prologue, nothing is skipped, starting address
is used, and test passes.
however, on targets which don't have such producer checking, the first
line number entry is skipped, and skip_prologue_using_sal returns sal
represents the second line number entry.
The idea of this patch is to force GDB stop at somewhere which is stilled
mapped to line 7 after skipping prologue. I choose to add a new line
number entry for the following instruction but mapped to the same line (7),
because I see the comments in dwarf2read.c,
... fact that two consecutive
line number entries for the same line is a heuristic used by gcc
to denote the end of the prologue.
then the line table becomes:
[0x000000d4] Extended opcode 2: set Address to 0x400529
[0x000000db] Advance Line by 4 to 7
[0x000000dd] Copy
[0x000000de] Extended opcode 2: set Address to 0x40052a
[0x000000e5] Advance Line by 0 to 7
[0x000000e7] Copy
[0x000000e8] Extended opcode 2: set Address to 0x40052b
[0x000000ef] Advance Line by 1 to 8
[0x000000f1] Copy
[0x000000f2] Extended opcode 2: set Address to 0x40052c
[0x000000f9] Extended opcode 1: End of Sequence
gdb/testsuite:
2015-03-26 Yao Qi <yao.qi@linaro.org>
PR testsuite/18139
* gdb.linespec/break-asm-file0.s (func): New label .Lfunc_2.
Add a line number entry for the same line.
* gdb.linespec/break-asm-file1.s (func): New label .Lfunc_2.
Add a line number entry for the same line.
|
|
There are some hard-coded stuff in .s files, such as .int 0 and
address offset, which isn't portable. This patch is to replace
".int 0" with nop and address offset with labels.
gdb/testsuite:
2015-03-26 Yao Qi <yao.qi@linaro.org>
* gdb.linespec/break-asm-file0.s (func2): Use nop instead of
.int 0.
(func): Likewise. Add .Lfunc_1 label.
Use .Lfunc_1 label.
* gdb.linespec/break-asm-file1.s (func3): Use nop instead of
.int 0.
(func): Likewise.
Use .Lfunc_1 label.
|
|
If I add some nop into break-asm-file1.s like this,
--- INDEX:/gdb/testsuite/gdb.linespec/break-asm-file1.s
+++ WORKDIR:/gdb/testsuite/gdb.linespec/break-asm-file1.s
@@ -31,8 +31,8 @@ _func:
.type func, %function
func:
.Lbegin_func:
- .int 0
- .int 0
+ nop
+ nop
.Lend_func:
.size func, .-func
.Lend_text1:
I get the following error:
Running gdb/testsuite/gdb.linespec/break-asm-file.exp ...
gdb/testsuite/gdb.linespec/break-asm-file1.s: Assembler messages:^M
gdb/testsuite/gdb.linespec/break-asm-file1.s: Fatal error: duplicate .debug_line sections
break-asm-file0.s and break-asm-file1.s have already had debug information
(written manually), so don't need to generate debug infor for them.
gdb/testsuite:
2015-03-26 Yao Qi <yao.qi@linaro.org>
* gdb.linespec/break-asm-file.exp: Don't call prepare_for_testing.
Call gdb_compile instead to compile each .s files without debug
information.
|
|
Hi,
I see the following two fails in gdb.base/savedregs.exp on aarch64-linux,
info frame 2^M
Stack frame at 0x7ffffffa60:^M
pc = 0x40085c in thrower (/home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/savedregs.c:49); saved pc = 0x400898^M
called by frame at 0x7ffffffa70, caller of frame at 0x7fffffe800^M
source language c.^M
Arglist at 0x7ffffffa60, args: ^M
Locals at 0x7ffffffa60, Previous frame's sp is 0x7ffffffa60^M
(gdb) FAIL: gdb.base/savedregs.exp: Get thrower info frame
info frame 2^M
Stack frame at 0x7fffffe800:^M
pc = 0x400840 in catcher (/home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/savedregs.c:42); saved pc = 0x7fb7ffc350^M
called by frame at 0x7fffffe800, caller of frame at 0x7fffffe7e0^M
source language c.^M
Arglist at 0x7fffffe7f0, args: sig=11^M
Locals at 0x7fffffe7f0, Previous frame's sp is 0x7fffffe800
(gdb) FAIL: gdb.base/savedregs.exp: Get catcher info frame
looks the test expects to match "Saved registers:" from the output of
"info frame", but no registers are saved on these two frames, because
thrower and catcher are simple and leaf functions.
(gdb) disassemble thrower
Dump of assembler code for function thrower:
0x0000000000400858 <+0>: mov x0, #0x0 // #0
0x000000000040085c <+4>: strb wzr, [x0]
0x0000000000400860 <+8>: ret
End of assembler dump.
(gdb) disassemble catcher
Dump of assembler code for function catcher:
0x0000000000400838 <+0>: sub sp, sp, #0x10
0x000000000040083c <+4>: str w0, [sp,#12]
0x0000000000400840 <+8>: adrp x0, 0x410000
0x0000000000400844 <+12>: add x0, x0, #0xb9c
0x0000000000400848 <+16>: mov w1, #0x1 // #1
0x000000000040084c <+20>: str w1, [x0]
0x0000000000400850 <+24>: add sp, sp, #0x10
0x0000000000400854 <+28>: ret
There are two ways to fix these fails, one is to modify functions to
force some registers saved (for example, doing function call in them),
and the other one is to relax the pattern to optionally match
"Saved registers:". I did both, and feel that the latter is simple,
so here is it.
gdb/testsuite:
2015-03-26 Yao Qi <yao.qi@linaro.org>
* gdb.base/savedregs.exp (process_saved_regs): Make
"Saved registers:" optional in the pattern.
|
|
The x86-record_goto.S assembly source file does not build on 32-bit.
This breaks many tests that use this file.
Split it into x86_64-record_goto.S and i686-record_goto.S. Luckily, we
can use either one with the same test .exp file.
It further turned out that most tests do not really need a fixed binary;
they should work pretty well with a newly-compiled C program. The
one thing that breaks this is the heavy use of "record goto" to navigate
inside the recorded execution.
Combine step.exp, next,exp, and finish.exp into a single test step.exp
and use normal stepping and reverse-stepping commands for navigation.
testsuite/
* gdb.btrace/next.exp: Merged into step.exp.
* gdb.btrace/finish.exp: Merged into step.exp.
* gdb.btrace/nexti.exp: Merged into stepi.exp.
* gdb.btrace/step.exp: Use record_goto.c as test file. Avoid using
"record goto" and checking the exact replay position.
* gdb.btrace/stepi.exp: Choose test file based on target. Do not
check for "Recording format" in "info record" output.
* gdb.btrace/record_goto.exp: Choose test file based on target.
* gdb.btrace/x86-record_goto.S: Renamed into ...
* gdb.btrace/x86_64-record_goto.S: ... this.
* gdb.btrace/i686-record_goto.S: New.
* gdb.btrace/x86-tailcall.S: Renamed into ...
* gdb.btrace/x86_64-tailcall.S: ... this.
* gdb.btrace/i686-tailcall.S: New.
* gdb.btrace/x86-tailcall.c: Renamed into ...
* gdb.btrace/tailcall.c: ... this. Split "return ++answer" into two
separate statements. Update test.
* gdb.btrace/delta.exp: Use record_goto.c as test file.
* gdb.btrace/gcore.exp: Use record_goto.c as test file.
* gdb.btrace/nohist.exp: Use record_goto.c as test file.
* gdb.btrace/tailcall.exp: Choose test file based on target.
* gdb.btrace/Makefile.in: Remove next, finish, and nexti.
|
|
The trace for throwing and catching an exception can be quite big.
Increase the buffer size to avoid spurious fails.
testsuite/
* gdb.btrace/exception.exp: Increase BTS buffer size.
|
|
I noticed that "thread apply all" sometimes crashes.
The problem is that thread_apply_all_command doesn take exited threads
into account, and we qsort and then walk more elements than there
really ever were put in the array. Valgrind shows:
The current thread <Thread ID 3> has terminated. See `help thread'.
(gdb) thread apply all p 1
Thread 1 (Thread 0x7ffff7fc2740 (LWP 29579)):
$1 = 1
==29576== Use of uninitialised value of size 8
==29576== at 0x639CA8: set_thread_refcount (thread.c:1337)
==29576== by 0x5C2C7B: do_my_cleanups (cleanups.c:155)
==29576== by 0x5C2CE8: do_cleanups (cleanups.c:177)
==29576== by 0x63A191: thread_apply_all_command (thread.c:1477)
==29576== by 0x50374D: do_cfunc (cli-decode.c:105)
==29576== by 0x506865: cmd_func (cli-decode.c:1893)
==29576== by 0x7562CB: execute_command (top.c:476)
==29576== by 0x647DA4: command_handler (event-top.c:494)
==29576== by 0x648367: command_line_handler (event-top.c:692)
==29576== by 0x7BF7C9: rl_callback_read_char (callback.c:220)
==29576== by 0x64784C: rl_callback_read_char_wrapper (event-top.c:171)
==29576== by 0x647CB5: stdin_event_handler (event-top.c:432)
==29576==
...
This can happen easily today as linux-nat.c/linux-thread-db.c are
forgetting to purge non-current exited threads. But even with that
fixed, we can always do "thread apply all" with an exited thread
selected, which won't be deleted until the user switches to another
thread. That's what the test added by this commit exercises.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-03-24 Pedro Alves <palves@redhat.com>
* thread.c (thread_apply_all_command): Take exited threads into
account.
gdb/testsuite/ChangeLog:
2015-03-24 Pedro Alves <palves@redhat.com>
* gdb.threads/no-unwaited-for-left.exp: Test "thread apply all".
|
|
Currently, "set scheduler-locking step" is a bit odd. The manual
documents it as being optimized for stepping, so that focus of
debugging does not change unexpectedly, but then it says that
sometimes other threads may run, and thus focus may indeed change
unexpectedly... A user can then be excused to get confused and wonder
why does GDB behave like this.
I don't think a user should have to know about details of how "next"
or whatever other run control command is implemented internally to
understand when does the "scheduler-locking step" setting take effect.
This patch completes a transition that the code has been moving
towards for a while. It makes "set scheduler-locking step" hold
threads depending on whether the _command_ the user entered was a
stepping command [step/stepi/next/nexti], or not.
Before, GDB could end up locking threads even on "continue" if for
some reason run control decides a thread needs to be single stepped
(e.g., for a software watchpoint).
After, if a "continue" happens to need to single-step for some reason,
we won't lock threads (unless when stepping over a breakpoint,
naturally). And if a stepping command wants to continue a thread for
bit, like when skipping a function to a step-resume breakpoint, we'll
still lock threads, so focus of debugging doesn't change.
In order to make this work, we need to record in the thread structure
whether what set it running was a stepping command.
(A follow up patch will remove the "step" parameters of 'proceed' and 'resume')
FWIW, Fedora GDB, which defaults to "scheduler-locking step" (mainline
defaults to "off") carries a different patch that goes in this
direction as well.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog:
2015-03-24 Pedro Alves <palves@redhat.com>
* gdbthread.h (struct thread_control_state) <stepping_command>:
New field.
* infcmd.c (step_once): Pass step=1 to clear_proceed_status. Set
the thread's stepping_command field.
* infrun.c (resume): Check the thread's stepping_command flag to
determine which threads should be resumed. Rename 'entry_step'
local to user_step.
(clear_proceed_status_thread): Clear 'stepping_command'.
(schedlock_applies): Change parameter type to struct thread_info
pointer. Adjust.
(find_thread_needs_step_over): Remove 'step' parameter. Adjust.
(switch_back_to_stepped_thread): Adjust calls to
'schedlock_applies'.
(_initialize_infrun): Adjust "set scheduler-locking step" help.
gdb/testsuite/ChangeLog:
2015-03-24 Pedro Alves <palves@redhat.com>
* gdb.threads/schedlock.exp (test_step): No longer expect that
"set scheduler-locking step" with "next" over a function call runs
threads unlocked.
gdb/doc/ChangeLog:
2015-03-24 Pedro Alves <palves@redhat.com>
* gdb.texinfo (test_step) <set scheduler-locking step>: No longer
mention that threads may sometimes run unlocked.
|
|
gdb/testsuite/ChangeLog:
* gdb.mi/mi-pending.exp: Fix output of breakpoint test.
|
|
When setting a pending breakpoint with a thread condition while using
the mi interface, the thread condition would be lost by gdb when the breakpoint
was resolved.
This patch fixes this behavior by setting the thread condition properly in the
mi case.
Also, this patch modifies the mi-pending test case to test for this issue and
removes some unneeded code in the testcase and dependency on stdio.
gdb/Changelog:
PR breakpoints/16466
* breakpoint.c (create_breakpoint): Set thread on breakpoint struct.
gdb/testsuite/ChangeLog:
PR breakpoints/16466
* gdb.mi/Makefile.in: Add mi-pendshr2.sl to cleanup.
* gdb.mi/mi-pending.c (thread_func): New function.
(int main): Add threading support required.
* gdb.mi/mi-pending.exp: Add tests for this issue.
* gdb.mi/mi-pendshr.c (pendfunc1): Remove stdio dependency.
(pendfunc2): Remove stdio dependency.
* gdb.mi/mi-pendshr2.c: New file.
|
|
|
|
This patch changes the heuristic the linespec lexer uses to
detect a keyword in the input stream.
Currently, the heuristic is: a word is a keyword if it
1) points to a string that is a keyword
2) is followed by a non-identifier character
This is strictly more correct than using whitespace. For example,
it allows constructs such as "break foo if(i == 1)". However,
find_condition_and_thread in breakpoint.c does not support this expanded
usage. It requires whitespace to follow the keyword.
The proposed new heuristic is: a word is a keyword if it
1) points to a string that is a keyword
2) is followed by whitespace
3) is not followed by another keyword string followed by whitespace
This additional complexity allows constructs such as
"break thread thread 3" and "break thread 3". In the former case,
the actual location is a symbol named "thread" to be set on thread #3.
In the later case, the location is NULL, i.e., the default location,
to be set on thread #3.
In order to pass all the new tests added here, I've also had to add a
new feature to parse_breakpoint_sals, which expands recognition of the
default location to keywords other than "if", which is the only keyword
currently permitted with the default (NULL) location, but there is no
reason to exclude other keywords.
Consequently, it will be possible to use "break thread 1" or
"break task 1".
In addition to all of this, it is now possible to remove the keyword_ok
state from the linespec parser.
gdb/ChangeLog
* breakpoint.c (parse_breakpoint_sals): Use
linespec_lexer_lex_keyword to ascertain if the user specified
a NULL location.
* linespec.c [IF_KEYWORD_INDEX]: Define.
(linespec_lexer_lex_keyword): Export.
(struct ls_parser) <keyword_ok>: Remove.
A keyword is only a keyword if not followed by another keyword.
(linespec_lexer_lex_one): Remove keyword_ok handling.
Add comment explaining why the parsing stream is not advanced
when a keyword is seen.
(parse_linespec): Remove parser->keyword_ok.
* linespec.h (linespec_lexer_lex_keyword): Add declaration.
gdb/testsuite/ChangeLog
* gdb.linespec/keywords.c: New file.
* gdb.linespec/keywords.exp: New file.
|
|
This bug appears to be caused by bad debuginfo. The method
causing the sefault in the reporter's test case is marked both static
and virtual.
This patch simply safegaurds against this case in dwarf2_add_member_fn,
where the code assumes that there is a `this' pointer when a virtual method
is seen (more specifically, when DW_AT_vtable_elem is seen).
It previously dereferenced the first formal parameter
(`this' pointer), which in this case doesn't exist. GDB consequently
segfaulted dereferencing a NULL pointer.
gdb/ChangeLog
PR gdb/18021
* dwarf2read.c (dwarf2_add_member_fn): Issue a complaint
if we find a static method with DW_AT_vtable_elem_location.
gdb/testsuite/ChangeLog
PR gdb/18021
* gdb.dwarf2/staticvirtual.exp: New test.
|
|
gdb/ChangeLog
2015-03-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* config/djgpp/README: Remove gdb.hp.
gdb/testsuite/ChangeLog
2015-03-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* Makefile.in (ALL_SUBDIRS): Remove gdb.hp.
* README: Remove HP-UX and gdb.hp.
(configuration):
* configure: Regenerate.
* configure.ac (AC_OUTPUT): Remove gdb.hp/Makefile,
gdb.hp/gdb.objdbg/Makefile, gdb.hp/gdb.base-hp/Makefile,
gdb.hp/gdb.aCC/Makefile, gdb.hp/gdb.compat/Makefile,
gdb.hp/gdb.defects/Makefile.
* gdb.hp/Makefile.in: File deleted.
* gdb.hp/gdb.aCC/Makefile.in: File deleted.
* gdb.hp/gdb.aCC/optimize.c: File deleted.
* gdb.hp/gdb.aCC/optimize.exp: File deleted.
* gdb.hp/gdb.aCC/run.c: File deleted.
* gdb.hp/gdb.aCC/watch-cmd.exp: File deleted.
* gdb.hp/gdb.base-hp/Makefile.in: File deleted.
* gdb.hp/gdb.base-hp/callfwmall.c: File deleted.
* gdb.hp/gdb.base-hp/callfwmall.exp: File deleted.
* gdb.hp/gdb.base-hp/dollar.c: File deleted.
* gdb.hp/gdb.base-hp/dollar.exp: File deleted.
* gdb.hp/gdb.base-hp/genso-thresh.c: File deleted.
* gdb.hp/gdb.base-hp/hwwatchbus.c: File deleted.
* gdb.hp/gdb.base-hp/hwwatchbus.exp: File deleted.
* gdb.hp/gdb.base-hp/pxdb.c: File deleted.
* gdb.hp/gdb.base-hp/pxdb.exp: File deleted.
* gdb.hp/gdb.base-hp/reg-pa64.exp: File deleted.
* gdb.hp/gdb.base-hp/reg-pa64.s: File deleted.
* gdb.hp/gdb.base-hp/reg.exp: File deleted.
* gdb.hp/gdb.base-hp/reg.s: File deleted.
* gdb.hp/gdb.base-hp/sized-enum.c: File deleted.
* gdb.hp/gdb.base-hp/sized-enum.exp: File deleted.
* gdb.hp/gdb.base-hp/so-thresh.exp: File deleted.
* gdb.hp/gdb.base-hp/so-thresh.mk: File deleted.
* gdb.hp/gdb.base-hp/so-thresh.sh: File deleted.
* gdb.hp/gdb.compat/Makefile.in: File deleted.
* gdb.hp/gdb.compat/average.c: File deleted.
* gdb.hp/gdb.compat/sum.c: File deleted.
* gdb.hp/gdb.compat/xdb.c: File deleted.
* gdb.hp/gdb.compat/xdb0.c: File deleted.
* gdb.hp/gdb.compat/xdb0.h: File deleted.
* gdb.hp/gdb.compat/xdb1.c: File deleted.
* gdb.hp/gdb.compat/xdb1.exp: File deleted.
* gdb.hp/gdb.compat/xdb2.exp: File deleted.
* gdb.hp/gdb.compat/xdb3.exp: File deleted.
* gdb.hp/gdb.defects/Makefile.in: File deleted.
* gdb.hp/gdb.defects/bs14602.c: File deleted.
* gdb.hp/gdb.defects/bs14602.exp: File deleted.
* gdb.hp/gdb.defects/solib-d.c: File deleted.
* gdb.hp/gdb.defects/solib-d.exp: File deleted.
* gdb.hp/gdb.defects/solib-d1.c: File deleted.
* gdb.hp/gdb.defects/solib-d2.c: File deleted.
* gdb.hp/gdb.objdbg/Makefile.in: File deleted.
* gdb.hp/gdb.objdbg/objdbg01.exp: File deleted.
* gdb.hp/gdb.objdbg/objdbg01/x1.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg01/x2.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg01/x3.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg01/x3.h: File deleted.
* gdb.hp/gdb.objdbg/objdbg02.exp: File deleted.
* gdb.hp/gdb.objdbg/objdbg02/x1.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg02/x2.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg02/x3.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg03.exp: File deleted.
* gdb.hp/gdb.objdbg/objdbg03/x1.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg03/x2.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg03/x3.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg04.exp: File deleted.
* gdb.hp/gdb.objdbg/objdbg04/x.h: File deleted.
* gdb.hp/gdb.objdbg/objdbg04/x1.cc: File deleted.
* gdb.hp/gdb.objdbg/objdbg04/x2.cc: File deleted.
* gdb.hp/gdb.objdbg/tools/symaddr: File deleted.
* gdb.hp/gdb.objdbg/tools/symaddr.pa64: File deleted.
* gdb.hp/gdb.objdbg/tools/test-objdbg.cc: File deleted.
* gdb.hp/tools/odump: File deleted.
|
|
Wanting to make sure the new continue-pending-status.exp test tests
both cases of threads 2 and 3 reporting an event, I added counters to
the test, to make it FAIL if events for both threads aren't seen.
Assuming a well behaved backend, and given a reasonable number of
iterations, it should PASS.
However, running that against GNU/Linux gdbserver, I found that
surprisingly, that FAILed. GDBserver always reported the breakpoint
hit for the same thread.
Turns out that I broke gdbserver's thread event randomization
recently, with git commit 582511be ([gdbserver] linux-low.c: better
starvation avoidance, handle non-stop mode too). In that commit I
missed that the thread structure also has a status_pending_p field...
The end result was that count_events_callback always returns 0, and
then if no thread is stepping, select_event_lwp always returns the
event thread. IOW, no randomization is happening at all. Quite
curious how all the other changes in that patch were sufficient to fix
non-stop-fair-events.exp anyway even with that broken.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/gdbserver/ChangeLog:
2015-03-19 Pedro Alves <palves@redhat.com>
* linux-low.c (count_events_callback, select_event_lwp_callback):
Use the lwp's status_pending_p field, not the thread's.
gdb/testsuite/ChangeLog:
2015-03-19 Pedro Alves <palves@redhat.com>
* gdb.threads/continue-pending-status.exp (saw_thread_2)
(saw_thread_3): New globals.
(top level): Increment them when an event for the corresponding
thread is seen.
(no thread starvation): New test.
|
|
If the linux_nat_resume's short-circuits the resume because the
current thread has a pending status, and, a thread with a higher
number was previously stopped for a breakpoint, GDB internal errors,
like:
/home/pedro/gdb/mygit/src/gdb/linux-nat.c:2590: internal-error: status_callback: Assertion `lp->status != 0' failed.
Fix this by make status_callback bail out earlier. GDBserver is
already doing the same.
New test added that exercises this.
gdb/ChangeLog:
2015-03-19 Pedro Alves <palves@redhat.com>
* linux-nat.c (status_callback): Return early if the LWP has no
status pending.
gdb/testsuite/ChangeLog:
2015-03-19 Pedro Alves <palves@redhat.com>
* gdb.threads/continue-pending-status.c: New file.
* gdb.threads/continue-pending-status.exp: New file.
|
|
This fixes several problems with this test.
E.g,. with --target_board=native-extended-gdbserver on x86_64 Fedora
20, I get:
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/disp-step-syscall.exp ...
FAIL: gdb.base/disp-step-syscall.exp: vfork: get hexadecimal valueof "$pc" (timeout)
FAIL: gdb.base/disp-step-syscall.exp: vfork: single step over vfork final pc
FAIL: gdb.base/disp-step-syscall.exp: vfork: delete break vfork insn
FAIL: gdb.base/disp-step-syscall.exp: vfork: continue to marker (vfork) (the program is no longer running)
And with --target=native-gdbserver, I get:
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/disp-step-syscall.exp ...
KPASS: gdb.base/disp-step-syscall.exp: vfork: single step over vfork (PRMS server/13796)
FAIL: gdb.base/disp-step-syscall.exp: vfork: get hexadecimal valueof "$pc" (timeout)
FAIL: gdb.base/disp-step-syscall.exp: vfork: single step over vfork final pc
FAIL: gdb.base/disp-step-syscall.exp: vfork: delete break vfork insn
FAIL: gdb.base/disp-step-syscall.exp: vfork: continue to marker (vfork) (the program is no longer running)
First, the lack of fork support on remote targets is supposed to be
kfailed, so the KPASS is obviously bogus. The extended-remote board
should have KFAILed too.
The problem is that the test is using "is_remote" instead of
gdb_is_target_remote.
And then, I get:
(gdb) PASS: gdb.base/disp-step-syscall.exp: vfork: set displaced-stepping on
stepi
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) PASS: gdb.base/disp-step-syscall.exp: vfork: single step over vfork
Obviously, that should be a FAIL. The problem is that the test only
expects SIGILL, not SIGSEGV. It also doesn't bail correctly if an
internal error or some other pattern caught by gdb_test_multiple
matches. The test doesn't really need to match specific exits/crashes
patterns, if the PASS regex is improved, like in ...
... this and the other "stepi" tests are a bit too lax, passing on
".*". This tightens those up to expect "x/i" and the "=>" current PC
indicator, like in:
1: x/i $pc
=> 0x3b36abc9e2 <vfork+34>: syscall
On x86_64 Fedora 20, I now get a quick KFAIL instead of timeouts with
both the native-extended-gdbserver and native-gdbserver boards:
PASS: gdb.base/disp-step-syscall.exp: vfork: delete break vfork
PASS: gdb.base/disp-step-syscall.exp: vfork: continue to syscall insn vfork
PASS: gdb.base/disp-step-syscall.exp: vfork: set displaced-stepping on
KFAIL: gdb.base/disp-step-syscall.exp: vfork: single step over vfork (PRMS: server/13796)
and a full pass with native testing.
gdb/testsuite/
2015-03-18 Pedro Alves <palves@redhat.com>
* gdb.base/disp-step-syscall.exp (disp_step_cross_syscall):
Use gdb_is_target_remote instead of is_remote. Use
gdb_test_multiple instead of gdb_expect. Exit early if
gdb_test_multiple hits its internal matches. Tighten stepi tests
expected output. Fail on exit with any signal, instead of just
SIGILL.
|
|
Hi,
This patch is to support catch syscall on aarch64 linux. We
implement gdbarch method get_syscall_number for aarch64-linux,
and add aarch64-linux.xml file, which looks straightforward, however
the changes to test case doesn't.
First of all, we enable catch-syscall.exp on aarch64-linux target,
but skip the multi_arch testing on current stage. I plan to touch
multi arch debugging on aarch64-linux later.
Then, when I run catch-syscall.exp on aarch64-linux, gcc errors that
SYS_pipe isn't defined. We find that aarch64 kernel only has pipe2
syscall and libc already convert pipe to pipe2. As a result, I change
catch-syscall.c to use SYS_pipe if it is defined, otherwise use
SYS_pipe2 instead. The vector all_syscalls in catch-syscall.exp can't
be pre-determined, so I add a new proc setup_all_syscalls to fill it,
according to the availability of SYS_pipe.
Regression tested on {x86_64, aarch64}-linux x {native, gdbserver}.
gdb:
2015-03-18 Yao Qi <yao.qi@linaro.org>
PR tdep/18107
* aarch64-linux-tdep.c: Include xml-syscall.h
(aarch64_linux_get_syscall_number): New function.
(aarch64_linux_init_abi): Call
set_gdbarch_get_syscall_number.
* syscalls/aarch64-linux.xml: New file.
gdb/testsuite:
2015-03-18 Yao Qi <yao.qi@linaro.org>
PR tdep/18107
* gdb.base/catch-syscall.c [!SYS_pipe] (pipe2_syscall): New
variable.
* gdb.base/catch-syscall.exp: Don't skip it on
aarch64*-*-linux* target. Remove elements in all_syscalls.
(test_catch_syscall_multi_arch): Skip it on aarch64*-linux*
target.
(setup_all_syscalls): New proc.
|
|
We see some fails in watchpoint-reuse-slot.exp on aarch64-linux, because
it sets some HW breakpoint on some address doesn't meet the alignment
requirements by kernel, kernel will reject the
ptrace (PTRACE_SETHBPREGS) call, and some fails are caused, for example:
(gdb) PASS: gdb.base/watchpoint-reuse-slot.exp: always-inserted off: watch x hbreak: : width 1, iter 0: base + 0: delete $bpnum
hbreak *(buf.byte + 0 + 1)^M
Hardware assisted breakpoint 80 at 0x410a61^M
(gdb) PASS: gdb.base/watchpoint-reuse-slot.exp: always-inserted off: watch x hbreak: : width 1, iter 0: base + 1: hbreak *(buf.byte + 0 + 1)
stepi^M
Warning:^M
Cannot insert hardware breakpoint 80.^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 hbreak: : width 1, iter 0: base + 1: stepi advanced
hbreak *(buf.byte + 0 + 1)^M
Hardware assisted breakpoint 440 at 0x410a61^M
Warning:^M
Cannot insert hardware breakpoint 440.^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 hbreak: : width 1, iter 0: base + 1: hbreak *(buf.byte + 0 + 1)
This patch is to skip some tests by checking proc valid_addr_p.
We can handle other targets in valid_addr_p too.
gdb/testsuite:
2015-03-16 Yao Qi <yao.qi@linaro.org>
* gdb.base/watchpoint-reuse-slot.exp (valid_addr_p): New proc.
(top level): Skip tests if valid_addr_p returns false for
$cmd1 or $cmd2.
|
|
This commit adds an objfile-progspace accessor to the (gdb) Guile
module.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-objfile.exp: Add objfile-progspace test.
gdb/doc/ChangeLog:
* guile.texi (Objfiles In Guile): Document objfile-progspace.
gdb/ChangeLog:
* guile/scm-objfile.c (gdbscm_objfile_progspace): New function.
(objfile_functions): Bind gdbscm_objfile_progspace to
objfile-progspace.
* guile/lib/gdb.scm: Add objfile-progspace to exports.
|
|
Fix typo "inferiorr".
gdb/testsuite:
2015-03-11 Yao Qi <yao.qi@linaro.org>
* gdb.base/catch-syscall.exp: Fix typo in comments.
|
|
"catch syscall" doesn't work on HP-UX.
gdb/testsuite:
2015-03-11 Yao Qi <yao.qi@linaro.org>
* gdb.base/catch-syscall.exp: Skip it on HP-UX target.
|
|
Unfortunately, the Python version of the dg-extract-results.sh script
doesn't produce stable-enough results for GDB. The test messages
appear to end up alpha sorted (losing the original sequence) and also
sorting changes between runs for some reason. That may be tolerable
for GCC, but for GDB, it often renders test results diffing between
different revisions unworkable.
Until that is fixed upstream, delete the script from the GDB tree.
testsuite/ChangeLog:
2015-03-09 Pedro Alves <palves@redhat.com>
* dg-extract-results.py: Delete.
|
|
This merges Sergio's fix from GCC:
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01293.html
gdb/testsuite/ChangeLog:
2015-03-09 Pedro Alves <palves@redhat.com>
Merge dg-extract-results.sh from GCC upstream (r218843).
2014-12-17 Sergio Durigan Junior <sergiodj@redhat.com>
* dg-extract-results.sh: Use --text with grep to avoid issues with
binary files. Fall back to cat -v, if that doesn't work.
|
|
Trying to fix a permanent breakpoints bug, I broke "next" over a
regular breakpoint. "next" would immediately hit the breakpoint the
program was already stopped at. But, the "next over setup" test
failed to notice this and still issued a pass. That's because the
regex matches "testsuite" in:
Breakpoint 2 at 0x400687: file src/gdb/testsuite/gdb.base/bp-permanent.c, line 46.
gdb/testsuite/ChangeLog:
2015-03-05 Pedro Alves <palves@redhat.com>
* gdb.base/bp-permanent.exp: Tighten "next over setup" regex.
|
|
When interrupting a thread in non-stop vs all-stop, the signal given in
the MI *stopped event is not the same. Currently, mi_expect_interrupt only
accepts the case for non-stop, so this adds the alternative for all-stop.
gdb/testsuite/ChangeLog:
* lib/mi-support.exp (mi_expect_interrupt): Accept
alternative event for when in all-stop mode.
|
|
Gary stumbled on this:
(gdb) PASS: gdb.threads/thread-specific-bp.exp: all-stop: continue to end
info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fdb700 (LWP 13717) "thread-specific" end () at /home/gary/work/archer/startswith/src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29
(gdb) FAIL: gdb.threads/thread-specific-bp.exp: all-stop: thread start is gone
info breakpoint
The problem is that "...archer/startswith/src..." has a "start" in it,
which matches the too-lax regex in the test.
Rather than tweaking the regex, we can just remove the whole "info
threads", like we removed similar ones in other files -- GDB nowadays
does this implicitly already, so things should work without it. Thus
removing this even improves testing here a bit.
gdb/testsuite/ChangeLog:
2015-03-04 Pedro Alves <palves@redhat.com>
* gdb.threads/thread-specific-bp.exp: Delete "info threads" test.
|
|
Apparently fixing a typo while you're editing the commit message doesn't work.
|
|
gdb/testsuite/
2015-03-04 Mark Kettenis <kettenis@gnu.org>
* gdb.base/foll-fork.exp: Enable on *-*-openbsd*.
|
|
On some targets each of the assignments "i = 0" in the C source for
"breakpoint-in-ro-region.exp" are compiled to a single instruction.
Then each "si" stops at the beginning of the next source line. But on
some other targets (like s390) such an assignment compiles to multiple
instructions. Then "si" may stop in mid-line, and GDB displays the PC
address in addition to the source line number. This was not considered
by the regexp for this case.
gdb/testsuite/ChangeLog:
* gdb.base/breakpoint-in-ro-region.exp (test_single_step): In the
regexps for GDB's current line display, accept a hex address
preceding the line number.
|
|
For the "multiple targets" test in catch-syscall.exp, set the 'arch1'
variable to a valid string.
gdb/testsuite/ChangeLog:
* gdb.base/catch-syscall.exp (test_catch_syscall_multi_arch): Set
the 'arch1' variable for "s390*-linux*" targets.
|
|
This fixes:
> gdb compile failed, /gdb/testsuite/gdb.threads/clone-thread_db.c: In function 'main':
> /gdb/testsuite/gdb.threads/clone-thread_db.c:67:3: warning: implicit declaration of function 'alarm' [-Wimplicit-function-declaration]
> alarm (300);
> ^
> /gdb/testsuite/gdb.threads/clone-thread_db.c:69:3: warning: implicit declaration of function 'pthread_create' [-Wimplicit-function-declaration]
> pthread_create (&child, NULL, thread_fn, NULL);
> ^
> /gdb/testsuite/gdb.threads/clone-thread_db.c:70:3: warning: implicit declaration of function 'pthread_join' [-Wimplicit-function-declaration]
> pthread_join (child);
> ^
And then adding the missing headers revealed the pthread_join call was
incorrect. This probably fixes the crash we see on ppc64be, e.g., at
https://sourceware.org/ml/gdb-testers/2015-q1/msg04415.html
the logs there show:
...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x3fffb7ff54a0 (LWP 9275)]
0x00003fffb7f3ce74 in .pthread_join () from /lib64/libpthread.so.0
(gdb) FAIL: gdb.threads/clone-thread_db.exp: continue to end
...
Tested on x86_64 Fedora 20.
gdb/testsuite/
2015-03-04 Pedro Alves <palves@redhat.com>
* gdb.threads/clone-thread_db.c: Include unistd.h and pthread.h.
(main): Pass missing retval argument to pthread_join call.
|
|
This fixes invalid reads Valgrind first caught when debugging against
a GDBserver patched with a series that adds exec events to the remote
protocol. Like these, using the gdb.threads/thread-execl.exp test:
$ valgrind ./gdb -data-directory=data-directory ./testsuite/gdb.threads/thread-execl -ex "tar extended-remote :9999" -ex "b thread_execler" -ex "c" -ex "set scheduler-locking on"
...
Breakpoint 1, thread_execler (arg=0x0) at src/gdb/testsuite/gdb.threads/thread-execl.c:29
29 if (execl (image, image, NULL) == -1)
(gdb) n
Thread 32509.32509 is executing new program: build/gdb/testsuite/gdb.threads/thread-execl
[New Thread 32509.32532]
==32510== Invalid read of size 4
==32510== at 0x5AA7D8: delete_breakpoint (breakpoint.c:13989)
==32510== by 0x6285D3: delete_thread_breakpoint (thread.c:100)
==32510== by 0x628603: delete_step_resume_breakpoint (thread.c:109)
==32510== by 0x61622B: delete_thread_infrun_breakpoints (infrun.c:2928)
==32510== by 0x6162EF: for_each_just_stopped_thread (infrun.c:2958)
==32510== by 0x616311: delete_just_stopped_threads_infrun_breakpoints (infrun.c:2969)
==32510== by 0x616C96: fetch_inferior_event (infrun.c:3267)
==32510== by 0x63A2DE: inferior_event_handler (inf-loop.c:57)
==32510== by 0x4E0E56: remote_async_serial_handler (remote.c:11877)
==32510== by 0x4AF620: run_async_handler_and_reschedule (ser-base.c:137)
==32510== by 0x4AF6F0: fd_event (ser-base.c:182)
==32510== by 0x63806D: handle_file_event (event-loop.c:762)
==32510== Address 0xcf333e0 is 16 bytes inside a block of size 200 free'd
==32510== at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32510== by 0x77CB74: xfree (common-utils.c:98)
==32510== by 0x5AA954: delete_breakpoint (breakpoint.c:14056)
==32510== by 0x5988BD: update_breakpoints_after_exec (breakpoint.c:3765)
==32510== by 0x61360F: follow_exec (infrun.c:1091)
==32510== by 0x6186FA: handle_inferior_event (infrun.c:4061)
==32510== by 0x616C55: fetch_inferior_event (infrun.c:3261)
==32510== by 0x63A2DE: inferior_event_handler (inf-loop.c:57)
==32510== by 0x4E0E56: remote_async_serial_handler (remote.c:11877)
==32510== by 0x4AF620: run_async_handler_and_reschedule (ser-base.c:137)
==32510== by 0x4AF6F0: fd_event (ser-base.c:182)
==32510== by 0x63806D: handle_file_event (event-loop.c:762)
==32510==
[Switching to Thread 32509.32532]
Breakpoint 1, thread_execler (arg=0x0) at src/gdb/testsuite/gdb.threads/thread-execl.c:29
29 if (execl (image, image, NULL) == -1)
(gdb)
The breakpoint in question is the step-resume breakpoint of the
non-main thread, the one that was "next"ed.
The exact same issue can be seen on mainline with native debugging, by
running the thread-execl.exp test in non-stop mode, because the kernel
doesn't report a thread exit event for the execing thread.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-03-02 Pedro Alves <palves@redhat.com>
* infrun.c (follow_exec): Delete all threads of the process except
the event thread. Extended comments.
gdb/testsuite/ChangeLog:
2015-03-02 Pedro Alves <palves@redhat.com>
* gdb.threads/thread-execl.exp (do_test): Handle non-stop.
(top level): Call do_test with non-stop as well.
|
|
gdb_test_multiple is supposed to return -1 on internal error:
# Returns:
# 1 if the test failed, according to a built-in failure pattern
# 0 if only user-supplied patterns matched
# -1 if there was an internal error.
But alas, that's broken, it returns success... It looks like the code
is assuming an earlier 'set result -1' is still in effect, but
'result' is set to 0 at the end, just before we call gdb_expect:
set result 0
set code [catch {gdb_expect $code} string]
gdb/testsuite/
2015-03-02 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_multiple) <internal error>: Set result to
-1.
|
|
Add a test case for S/390 vector registers support.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-vregs.exp: New test.
* gdb.arch/s390-vregs.S: New file.
|
|
All callers of catch_command_errors pass RETURN_MASK_ALL as mask
argument. This patch eliminates the mask parameter as unnecessary.
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* main.c (catch_command_errors, catch_command_errors_const):
Remove 'mask' argument. Adjust.
(captured_main): Adjust callers.
gdb/testsuite/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* gdb.gdb/python-interrupts.exp (test_python_interrupts): Adjust
call to catch_command_errors.
* gdb.gdb/python-selftest.exp (selftest_python): Adjust call to
catch_command_errors.
|
|
gdb/testsuite/
2015-02-27 Pedro Alves <palves@redhat.com>
* gdb.gdb/complaints.exp (test_initial_complaints): Also accept
"true" for boolean result.
* gdb.gdb/selftest.exp (test_with_self): Also accept full
prototype of main.
|
|
In some scenarios, GDB or GDBserver can be spawned with input _not_
connected to a tty, and then tests that rely on stdio fail with
timeouts, because the inferior's stdout and stderr streams end up
fully buffered.
See discussion here:
https://sourceware.org/ml/gdb-patches/2015-02/msg00809.html
We have a hack in place that works around this for Windows testing,
that forces every test program to link with an .o file that does
(lib/set_unbuffered_mode.c):
static int __gdb_set_unbuffered_output (void) __attribute__ ((constructor));
static int
__gdb_set_unbuffered_output (void)
{
setvbuf (stdout, NULL, _IONBF, BUFSIZ);
setvbuf (stderr, NULL, _IONBF, BUFSIZ);
}
That's a bit hacky; it ends up done for _all_ tests.
This patch adds a way to do this unbuffering explicitly from the test
code itself, so it is done only when necessary, and for all
targets/hosts. For starters, it adjusts gdb.base/interrupt.c to use
it.
Tested on x86_64 Fedora 20, native, and against a remote gdbserver
board file that connects to the target with ssh, with and without -t
(create pty).
gdb/testsuite/
2015-02-27 Pedro Alves <palves@redhat.com>
* lib/unbuffer_output.c: New file.
* gdb.base/interrupt.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
|