aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite
AgeCommit message (Collapse)AuthorFilesLines
2015-04-03Do not consider reference types as dynamicPierre-Marie de Rodat3-0/+83
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.
2015-04-02kfail two tests in no-unwaited-for-left.exp for remote targetYao Qi2-0/+11
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.
2015-04-02Make the default sysroot be "target:"Gary Benson2-0/+8
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.
2015-04-01Add support for writing unwinders in Python.Sasha Smundak7-0/+390
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.
2015-04-01gdb.threads/manythreads.exp: can't read "test": no such variablePedro Alves2-1/+6
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.
2015-04-01Fix gdb_spawn_with_cmdline_opts with non-empty GDBFLAGSPedro Alves2-0/+8
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.
2015-04-01Share the "multi_line" helper among all testcasesPierre-Marie de Rodat20-161/+130
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.
2015-04-01Crash on thread id wrap aroundPedro Alves3-0/+236
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.
2015-03-31Implement support for checking /proc/PID/coredump_filterSergio Durigan Junior3-0/+265
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.
2015-03-31dwarf.exp: Allow generating a stub .debug_line sectionPetr Machata2-1/+150
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>
2015-03-26testsuite: Don't set SYMBOL_PREFIX for x86_64_*_cygwinJon Turney2-1/+6
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.
2015-03-26Properly intern constants into psymtabAndy Wingo3-0/+92
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.
2015-03-26Handle the effect of skipping prologueYao Qi3-0/+36
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.
2015-03-26Remove some hard-coded stuff in testsYao Qi3-10/+23
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.
2015-03-26Compile break-asm-file{0,1}.s without debug infoYao Qi2-5/+24
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.
2015-03-26Relax pattern to match the output of "info frame" in gdb.base/savedregs.expYao Qi2-1/+6
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.
2015-03-25btrace: fix tests for 32-bitMarkus Metzger17-428/+1057
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.
2015-03-25btrace: increase buffer size for exception testMarkus Metzger2-0/+6
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.
2015-03-24Fix "thread apply all" with exited threadsPedro Alves2-0/+8
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".
2015-03-24Make "set scheduler-locking step" depend on user intention, onlyPedro Alves2-6/+11
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.
2015-03-24Fix mi-pending.exp test output to allow stable test diffingAntoine Tremblay2-1/+5
gdb/testsuite/ChangeLog: * gdb.mi/mi-pending.exp: Fix output of breakpoint test.
2015-03-24Fix breakpoint thread condition missing with mi and a pending breakpoint.Antoine Tremblay6-25/+138
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.
2015-03-23Add missing changelog entries of last commitKeith Seitz1-0/+5
2015-03-23Expand keyword lexing intelligence in the linespec parser.Keith Seitz2-0/+113
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.
2015-03-23PR gdb/18021 - defend against "static virtual" methodsKeith Seitz2-0/+59
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.
2015-03-20Remove gdb.hpJan Kratochvil69-5008/+79
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.
2015-03-19gdbserver/Linux: unbreak thread event randomizationPedro Alves2-0/+22
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.
2015-03-19native/Linux: internal error if resume is short-circuitedPedro Alves3-0/+173
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.
2015-03-18Tighten gdb.base/disp-step-syscall.expPedro Alves2-27/+35
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.
2015-03-18Support catch syscall on aarch64 linuxYao Qi3-4/+52
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.
2015-03-16watchpoint-reuse-slot.exp: skip setting HW breakpoints on some addressYao Qi2-0/+37
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.
2015-03-11Add objfile-progspace to Guile interfaceAndy Wingo2-0/+7
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.
2015-03-11Typo fixYao Qi2-1/+5
Fix typo "inferiorr". gdb/testsuite: 2015-03-11 Yao Qi <yao.qi@linaro.org> * gdb.base/catch-syscall.exp: Fix typo in comments.
2015-03-11Skip catch-syscall.exp on HP-UX targetYao Qi2-1/+5
"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.
2015-03-09Delete gdb/testsuite/dg-extract-results.pyPedro Alves2-585/+4
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.
2015-03-09Make dg-extract-results.sh explicitly treat .{sum,log} files as textPedro Alves2-5/+28
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.
2015-03-05gdb.base/bp-permanent.exp: Tighten regexPedro Alves2-1/+5
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.
2015-03-04Accept all-stop alternative in mi_expect_interruptSimon Marchi2-2/+8
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.
2015-03-04Fix gdb.threads/thread-specific-bp.exp racePedro Alves2-13/+4
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.
2015-03-04Stupid git!Mark Kettenis1-1/+1
Apparently fixing a typo while you're editing the commit message doesn't work.
2015-03-04Enable gdb.base/foll-fork.exp on OpenBSDMark Kettenis2-1/+6
gdb/testsuite/ 2015-03-04 Mark Kettenis <kettenis@gnu.org> * gdb.base/foll-fork.exp: Enable on *-*-openbsd*.
2015-03-04breakpoint-in-ro-region.exp: Support targets stopping in mid-line after "si"Andreas Arnez2-2/+9
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.
2015-03-04catch-syscall.exp: Fix missing architecture name for s390:31-bitAndreas Arnez2-1/+6
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.
2015-03-04gdb.threads/clone-thread_db.c: Add missing includes and fix pthread_join callPedro Alves2-1/+8
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.
2015-03-03follow-exec: delete all non-execing threadsPedro Alves2-3/+26
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.
2015-03-02gdb_test_multiple: return -1 on internal errorPedro Alves2-0/+6
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.
2015-03-02S390: Vector register test caseAndreas Arnez3-0/+303
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.
2015-02-27catch_command_errors: Remove 'mask' parameterPedro Alves3-2/+9
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.
2015-02-27Adjust self tests to cope with GDB built as a C++ programPedro Alves3-3/+16
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.
2015-02-27Add "../lib/unbuffer_output.c" and use it in gdb.base/interrupt.cPedro Alves3-0/+50
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.