aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2016-02-08Always organize test artifacts in a directory hierarchySimon Marchi37-866/+51
When running tests in parallel, each test puts its generated files in a different directory, under "outputs". I think it would be nice if it was always the case, as it would isolate the test cases a bit more. An artifact created by a test wouldn't get overwritten by another test. Also, it makes it easier to clean up. A lot of executables are left all over the place because their names do not appear in gdb.*/Makefile. If everything is in "outputs", then we just have to delete that directory (which we already do). At the same time it makes the gdb.foo directories and their Makefiles useless in the build directory, since they are pretty much only used for cleaning. What do you think? gdb/testsuite/ChangeLog: * Makefile.in (ALL_SUBDIRS): Remove. (clean mostlyclean): Do not recurse in ALL_SUBDIRS. (distclean maintainer-clean realclean): Likewise. * configure.ac (AC_OUTPUT): Remove gdb.*/Makefile. * configure: Regenerate. * gdb.ada/Makefile.in: Delete. * gdb.arch/Makefile.in: Likewise. * gdb.asm/Makefile.in: Likewise. * gdb.base/Makefile.in: Likewise. * gdb.btrace/Makefile.in: Likewise. * gdb.cell/Makefile.in: Likewise. * gdb.compile/Makefile.in: Likewise. * gdb.cp/Makefile.in: Likewise. * gdb.disasm/Makefile.in: Likewise. * gdb.dlang/Makefile.in: Likewise. * gdb.dwarf2/Makefile.in: Likewise. * gdb.fortran/Makefile.in: Likewise. * gdb.gdb/Makefile.in: Likewise. * gdb.go/Makefile.in: Likewise. * gdb.guile/Makefile.in: Likewise. * gdb.java/Makefile.in: Likewise. * gdb.linespec/Makefile.in: Likewise. * gdb.mi/Makefile.in: Likewise. * gdb.modula2/Makefile.in: Likewise. * gdb.multi/Makefile.in: Likewise. * gdb.objc/Makefile.in: Likewise. * gdb.opencl/Makefile.in: Likewise. * gdb.opt/Makefile.in: Likewise. * gdb.pascal/Makefile.in: Likewise. * gdb.perf/Makefile.in: Likewise. * gdb.python/Makefile.in: Likewise. * gdb.reverse/Makefile.in: Likewise. * gdb.server/Makefile.in: Likewise. * gdb.stabs/Makefile.in: Likewise. * gdb.threads/Makefile.in: Likewise. * gdb.trace/Makefile.in: Likewise. * gdb.xml/Makefile.in: Likewise. * lib/gdb.exp (make_gdb_parallel_path): Add check for GDB_PARALLEL. (standard_output_file): Remove check for GDB_PARALLEL, always return path in outputs/$subdir/$testname.
2016-02-08Fix in-tree, parallel running of Ada testsSimon Marchi2-1/+7
While testing the following patch, [PATCH] Always organize test artifacts in a directory hierarchy https://sourceware.org/ml/gdb-patches/2016-01/msg00133.html I noticed that it broke Ada testing. This lead me to think that parallel testing when building in-tree didn't work previously in Ada. It is confirmed by this test: $ make check TESTS="gdb.ada/fun_addr.exp" -j 2 ... Running ./gdb.ada/fun_addr.exp ... FAIL: gdb.ada/fun_addr.exp: compilation foo.adb ... This patch fixes in-tree parallel testing for Ada, and consequently serial and parallel testing when the aforementioned patch is applied. The problem originates from the fact that Ada support code cd's to the builddir before compiling. In itself it's not a problem, it allows to place intermediate auto-generated files in that directory. The Ada compilation refers to the source file, which is in another directory, only by its base name (e.g. foo.adb). In serial mode, that worked because builddir was the same as the source directory (e.g. gdb.ada/fun_addr/). In an out-of-tree build, it works because the source directory is added as an include directory (note: this is not the same $srcdir as autoconf's): set srcdir [file dirname $source] additional_flags=-I$srcdir which becomes: additional_flags=-I/home/emaisin/build/binutils-gdb/gdb/testsuite/gdb.ada/fun_addr However, when building in-tree, srcdir is relative: ./gdb.ada/fun_addr. When using parallel or always-in-outputs-directory mode, we are cd'ed in the outputs directory. So -I$srcdir is relative to the current directory, which is wrong. To fix it, I made the TCL variable srcdir (set in site.exp, from which everything else is derived) always absolute. It is done by assigning autoconf's abs_srcdir instead of autoconf's srcdir. This way -I$srcdir will always be good, regardless of where we cd'ed to. A small apparent change is that when running tests, DejaGnu will say: Running /tmp/binutils-gdb/gdb/testsuite/gdb.ada/fun_addr.exp ... instead of Running ./gdb.ada/fun_addr.exp ... I hope it's not too much of an annoyance. I think that it should make the testsuite a tiny bit more robust against other bugs of the same class. Regtested in & out of tree, only with native target. gdb/testsuite/ChangeLog: * Makefile.in (abs_srcdir): Assign @abs_srcdir@. (site.exp): Assign abs_srcdir to tcl's srcdir.
2016-02-08remote.c: Cleanup unused variablesSimon Marchi2-35/+25
I built remote.c with -Wunused, to check a function I was working on, turns out there is a bunch of unused variables. gdb/ChangeLog: * remote.c (remote_register_number_and_offset): Remove unused variable(s). (remote_thread_always_alive): Likewise. (remote_update_thread_list): Likewise. (process_initial_stop_replies): Likewise. (remote_start_remote): Likewise. (remote_check_symbols): Likewise. (discard_pending_stop_replies): Likewise. (process_stop_reply): Likewise. (putpkt_binary): Likewise. (getpkt): Likewise. (remote_add_target_side_condition): Likewise. (remote_insert_breakpoint): Likewise. (remote_supports_stopped_by_sw_breakpoint): Likewise. (remote_supports_stopped_by_hw_breakpoint): Likewise. (remote_xfer_partial): Likewise. (remote_read_btrace): Likewise. (remote_async_serial_handler): Likewise. (remote_thread_events): Likewise. (_initialize_remote): Likewise.
2016-02-07varobj: Cleanup dead codeSimon Marchi4-104/+39
This patch removes some dead code. I noticed that varobj_delete was always called with dellist == NULL, so I started removing that parameter. That allows removing a good chunk of the code in varobj_delete, making it almost trivial. We can also remove the resultp parameters in that whole trail. In turn, this shows that struct cpstack, cppush and cppop were only used fo that mechanism, so they can be removed as well. I also moved the function comment to the header file to comply with today's guideline, even though the rest of the file does not respect it (yet). gdb/ChangeLog: * varobj.h (varobj_delete): Remove dellist parameter, update and move documentation here. * varobj.c (struct cpstack, cppush, cppop): Remove. (delete_variable): Remove resultp (first) parameter. (delete_variable_1): Likewise. (varobj_delete): Remove dellist parameter and unused code. (update_dynamic_varobj_children): Adjust varobj_delete call. (update_type_if_necessary): Likewise. (varobj_set_visualizer): Likewise. (varobj_update): Likewise. (value_of_root): Likewise. (varobj_invalidate_iter): Likewise. * mi/mi-cmd-var.c (mi_cmd_var_delete): Likewise.
2016-02-04[testsuite] Remove BASEDIRYao Qi12-39/+130
BASEDIR was added by https://sourceware.org/ml/gdb-patches/2013-10/msg00587.html in order to handle the different directory layout in serial testing and parallel testing. BASEDIR is "gdb.base" in serial testing and is "outputs/gdb.base/TESTNAME" in parallel testing. However, it doesn't work if the GDBserver is in remote target, like this, $ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost foll-vfork.exp foll-exec.exp' FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork and exec child follow, to main bp: continue to bp (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork child follow, finish after tcatch vfork: finish (the program exited) FAIL: gdb.base/foll-vfork.exp: exec: vfork relations in info inferiors: continue to bp (the program exited) these tests fail because the executable can't be found. With target board native-gdbserver, the program is spawned this way, spawn ../gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork so BASEDIR is correct. However, with target board remote-gdbserver-on-localhost, the program is spawned spawn /usr/bin/ssh -l yao localhost /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../gdbserver/gdbserver --once :2346 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork so BASEDIR (either "gdb.base" or "outputs/gdb.base/TESTNAME") makes no sense. I had a fix that pass absolute directory to BASEDIR, but it assumes that directory structure is the same on build and target, and it doesn't work in remote host case. The current fix in this patch is to get the directory from argv[0]. In any case, the program to be exec'ed is at the same directory with the main program. Note that these tests do "next N" to let program stop at the desired line, but it is fragile, because GDB for different targets may skip function prologue slightly differently, so I replace some of them by "tbreak on LINE NUMBER and continue". gdb/testsuite: 2016-02-04 Yao Qi <yao.qi@linaro.org> * gdb.base/foll-exec-mode.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-exec-mode.exp: Don't pass -DBASEDIR in compilation. * gdb.base/foll-exec.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-exec.exp: Don't pass -DBASEDIR in compilation. Adjust tests on the number of lines as source code changed. * gdb.base/foll-vfork-exit.c: Include limits.h. (main): Add one line of statement before vfork. * gdb.base/foll-vfork.c: Include limits.h and string.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.base/foll-vfork.exp: Don't pass -DBASEDIR in compilation. (setup_gdb): Set tbreak to skip some source lines. * gdb.multi/bkpt-multi-exec.c: Include limits.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.multi/bkpt-multi-exec.exp: Don't pass -DBASEDIR in compilation. * gdb.multi/multi-arch-exec.c: Include limits.h and string.h. (main): Add parameters argc and argv. Get directory from argv[0]. * gdb.multi/multi-arch-exec.exp: Don't pass -DBASEDIR in compilation.
2016-02-04waiting_for_stop_reply around remote_fileio_requestYao Qi2-0/+13
Hi, I see this error when GDB connects with qemu, (gdb) n .... Sending packet: $vCont;c#a8...Ack Packet received: Ffstat,00000001,f6fff038 Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. looks we don't set rs->waiting_for_stop_reply to zero before handle fileio request, #10 0x00000000005edb64 in target_write (len=64, offset=4143968312, buf=0x7fffffffd570 "\375\377\377\377", annex=0x0, object=TARGET_OBJECT_MEMORY, ops=<optimised out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:1922 #11 target_write_memory (memaddr=memaddr@entry=4143968312, myaddr=myaddr@entry=0x7fffffffd6a0 "", len=len@entry=64) at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:1500 #12 0x00000000004b2b41 in remote_fileio_func_fstat (buf=0x127b258 "") at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1037 #13 0x00000000004b1878 in do_remote_fileio_request (uiout=<optimised out>, buf_arg=buf_arg@entry=0x127b240) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1204 #14 0x00000000005b8c7c in catch_exceptions_with_msg (func_uiout=<optimised out>, func=func@entry=0x4b1800 <do_remote_fileio_request>, func_args=func_args@entry=0x127b240, gdberrmsg=gdberrmsg@entry=0x0, mask=mask@entry=RETURN_MASK_ALL) at /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:187 #15 0x00000000005b8dea in catch_exceptions (uiout=<optimised out>, func=func@entry=0x4b1800 <do_remote_fileio_request>, func_args=func_args@entry=0x127b240, mask=mask@entry=RETURN_MASK_ALL) at /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:167 #16 0x00000000004b2fff in remote_fileio_request (buf=0x127b240 "Xf6fff038,0:", ctrlc_pending_p=0) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1255 #17 0x0000000000496f12 in remote_wait_as (ptid=..., status=0x7fffffffdb20, options=1) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:6997 however, we did set rs->waiting_for_stop_reply to zero before Luis's patch https://sourceware.org/ml/gdb-patches/2015-10/msg00336.html In fact, Luis's patch v1 https://sourceware.org/ml/gdb-patches/2015-08/msg00809.html is about setting rs->waiting_for_stop_reply back to one after remote_fileio_request, which is correct. However during the review, the patch is changed and ends up with "not setting rs->waiting_for_stop_reply to zero". I manually test GDB, but I don't have a way to run regression tests. gdb: 2016-02-04 Yao Qi <yao.qi@linaro.org> * remote.c (remote_wait_as): Set rs->waiting_for_stop_reply to 0 before handling 'F' and set it back afterwards.
2016-02-02ui-out.c: Remove unused enumSimon Marchi2-6/+4
This is unused since 54eb231c4bca046e8b8cd73461f695e02c5620d5, where static arrays of ui_out_levels were replaced with vectors. gdb/ChangeLog: * ui-out.c (MAX_UI_OUT_LEVELS): Remove.
2016-02-02Adaptation of siginfo fixup for the new bnd fieldsWalfred Tedeschi3-102/+240
New bnds fields will be always present for x86 architecture. Fixup for compatibility layer 32bits has to be fixed. It was added the nat_siginfo to serving as intermediate step between kernel provided siginfo and the fix up routine. When executing compat_siginfo_from_siginfo or compat_x32_siginfo_from_siginfo first the buffer read from the kernel are converted into the nat_signfo for homogenization, then the fields of nat_siginfo are use to set the compat and compat_x32 siginfo fields. In other to make this conversion independent of the system where gdb is compiled the most complete version of the siginfo, named as native siginfo, is used internally as an intermediate step. Conversion using nat_siginfo is exemplified below: compat_siginfo_from_siginfo or compat_x32_siginfo_from_siginfo: buffer (from the kernel) -> nat_siginfo -> 32 / X32 siginfo (memcpy) (field by field) siginfo_from_compat_x32_siginfo or siginfo_from_compat_siginfo: 32 / X32 siginfo -> nat_siginfo -> buffer (to the kernel) (field by field) (memcpy) Caveat: No support for MPX on x32. 2016-02-02 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/ChangeLog: * amd64-linux-siginfo.c (nat_siginfo_t, nat_sigval_t, nat_timeval): New types. (compat_siginfo): New bound fields added. (compat_x32_siginfo): New field added. (cpt_si_addr_lsb): New define. (compat_siginfo_from_siginfo): Use nat_siginfo. (siginfo_from_compat_siginfo): Use nat_siginfo. (compat_x32_siginfo_from_siginfo): Likewise. (siginfo_from_compat_x32_siginfo): Likewise.
2016-02-02Add bound related fields to the siginfo structureWalfred Tedeschi2-2/+21
Both Linux and glibc have introduced bound related fields in the segmentation fault fields of the siginfo_t type. Add the new fields to our x86's siginfo_t type too. Kernel patch: http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=ee1b58d36aa1b5a79eaba11f5c3633c88231da83 Glibc patch: http://repo.or.cz/w/glibc.git/commit/d4358b51c26a634eb885955aea06cad26af6f696 2016-02-02 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/ChangeLog: * linux-tdep.c (linux_get_siginfo_type): Add the _addr_bnd structure to the siginfo if extra_fields contains LINUX_SIGINFO_FIELD_ADDR_BND.
2016-02-02Use linux_get_siginfo_type_with_fields for x86Walfred Tedeschi6-3/+34
Use linux_get_siginfo_type_with_fields for adding bound fields on segmentation fault for i386/amd64 siginfo. 2016-02-02 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/ChangeLog: * linux-tdep.h (linux_get_siginfo_type_with_fields): Make extern. * linux-tdep.c (linux_get_siginfo_type_with_fields): Make extern. * i386-linux-tdep.h (x86_linux_get_siginfo_type): New function. * amd64-linux-tdep.c (amd64_linux_init_abi_common): Add x86_linux_get_siginfo_type for the amd64 abi. * i386-linux-tdep.c (x86_linux_get_siginfo_type): New function. (i386_linux_init_abi): Add new function at the i386 ABI initialization.
2016-02-02Preparation for new siginfo on LinuxWalfred Tedeschi3-3/+32
First add new structure and function to allow architecture customization for the siginfo structure. 2016-01-15 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/ChangeLog: * linux-tdep.h (linux_siginfo_extra_field_values): New enum values. (linux_siginfo_extra_fields): New enum type. * linux-tdep.c (linux_get_siginfo_type_with_fields): New function. (linux_get_siginfo_type): Use new function.
2016-02-02Merge gdb and gdbserver implementations for siginfoWalfred Tedeschi10-844/+563
Extract the compatible siginfo handling from amd64-linux-nat.c and gdbserver/linux-x86-low to a new file nat/amd64-linux-siginfo.c. 2016-02-02 Walfred Tedeschi <walfred.tedeschi@intel.com> gdb/ChangeLog: * nat/amd64-linux-siginfo.c: New file. * nat/amd64-linux-siginfo.h: New file. * Makefile.in (HFILES_NO_SRCDIR): Add nat/amd64-linux-siginfo.h. (amd64-linux-siginfo.o): New rule. * config/i386/linux64.mh (NATDEPFILES): Add amd64-linux-siginfo.o. * amd64-linux-nat.c (nat/amd64-linux-siginfo.h): New include. (compat_siginfo_from_siginfo, siginfo_from_compat_siginfo) (compat_x32_siginfo_from_siginfo, siginfo_from_compat_x32_siginfo) (compat_timeval, compat_sigval, compat_x32_clock, cpt_si_pid) (cpt_si_uid, cpt_si_timerid, cpt_si_overrun, cpt_si_status) (cpt_si_utime, cpt_si_stime, cpt_si_ptr, cpt_si_addr, cpt_si_band) (cpt_si_fd, si_timerid, si_overrun): Move to nat/amd64-linux-siginfo.c. gdb/gdbserver/ChangeLog: * configure.srv (x86_64-*-linux*): Add amd64-linux-siginfo.o to srv_tgtobj. (i[34567]86-*-linux*): Add amd64-linux-siginfo.o to srv_tgtobj. * linux-x86-low.c [__x86_64__]: Include "nat/amd64-linux-siginfo.h". (compat_siginfo_from_siginfo, siginfo_from_compat_siginfo) (compat_x32_siginfo_from_siginfo, siginfo_from_compat_x32_siginfo) (compat_timeval, compat_sigval, compat_x32_clock, cpt_si_pid) (cpt_si_uid, cpt_si_timerid, cpt_si_overrun, cpt_si_status) (cpt_si_utime, cpt_si_stime, cpt_si_ptr, cpt_si_addr, cpt_si_band) (cpt_si_fd, si_timerid, si_overrun): Move from nat/amd64-linux-siginfo.c. * Makefile.in (amd64-linux-siginfo.o:): New rule.
2016-02-01gdb.texinfo (Value Sizes): Fix typo.Doug Evans2-1/+5
2016-02-01gdb.texinfo (Skipping Over Functions and Files): Fix typo.Doug Evans2-1/+5
2016-02-01gdb.base/skip.exp: Clean up multiple references to same test name.Doug Evans2-11/+18
2016-02-01Mention PR remote/19496 in gdb/testsuite/ChangeLog entryPedro Alves1-0/+1
2016-02-01Test gdb.threads/forking-threads-plus-breakpoint.exp with displaced stepping offPedro Alves2-5/+67
This exposes the internal error Don mentioned in PR19496: (1) internal error -- gdb/target.c:2713: internal-error: Can't determine the current address space of thread More analysis here: https://sourceware.org/ml/gdb-patches/2016-01/msg00685.html The (now kfailed) internal error looks like: continue & Continuing. (gdb) PASS: gdb.threads/forking-threads-plus-breakpoint.exp: cond_bp_target=1: detach_on_fork=on: displaced=off: continue & [New Thread 2846.2847] (...) [New Thread 2867.2867] /home/pedro/gdb/mygit/src/gdb/target.c:2723: internal-error: Can't determine the current address space of thread Thread 2846.2846 A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) KFAIL: gdb.threads/forking-threads-plus-breakpoint.exp: cond_bp_target=1: detach_on_fork=on: displaced=off: inferior 1 exited (GDB internal error) (PRMS: remote/19496) Resyncing due to internal error. gdb/testsuite/ChangeLog: 2016-02-01 Pedro Alves <palves@redhat.com> PR remote/19496 * gdb.threads/forking-threads-plus-breakpoint.exp (displaced_stepping_supported): New global. (probe_displaced_stepping_support): New procedure. (do_test): Add 'displaced' parameter, and use it. (top level): Check for displaced stepping support. Add displaced stepping on/off testing axis.
2016-02-01gdb: Guard against undefined behaviour in mi-vla-fortran.expAndrew Burgess2-16/+38
The test gdb.mi/mi-vla-fortran.exp reveals an issue with the DWARF generated by gfortran. In the test a pointer variable 'pvla2' is created: real, pointer :: pvla2 (:, :) Initially this variable will be unassociated, so something like this: l = associated(pvla2) should return false. In the test gdb stops at a point _before_ pvla2 is associated with anything, and we then try to print pvla2, the expectation is that gdb should reply <not associated>. The problem is that the data the DWARF directs gdb to read (to identify if the variable is associated or not) is not initialised until the first time pvla2 is accessed. As a result gdb ends up reading uninitialised memory, sometimes this uninitialised memory indicates the variable is associated (when it's not). This first mistake can lead to a cascade of errors, reading uninitialised memory, with the result that gdb builds an invalid type to associate with the variable pvla2. In some cases, this invalid type can be very large, which when we try to print pvla2 causes gdb to allocate a large amount of memory. A recent commit added a new gdb variable 'max-value-size', which prevents gdb from allocating values of extreme size. As a result directly trying to print pvla2 will now now error rather than allocate a large amount of memory. However, some of the later tests create a varobj for pvla2, and then ask for the children of that varobj to be displayed. In the case where an invalid type has been computed for pvla2 then the number of children can be wrong, and very big, in which case trying to display all of these children can cause gdb to consume an excessive amount of memory. This commit first detects if printing pvla2 triggers the max-value-size error, if it does then we avoid all the follow on tests relating to the unassociated pvla2, which avoids the second error printing the varobj children. gdb/testsuite/ChangeLog: * gdb.mi/mi-vla-fortran.exp: Add XFAIL for accessing unassociated pointer. Don't perform further tests on the unassociated pointer if the first test fails.
2016-02-01gdb: New set/show max-value-size command.Andrew Burgess9-4/+289
For languages with dynamic types, an incorrect program, or uninitialised variables within a program, could result in an incorrect, overly large type being associated with a value. Currently, attempting to print such a variable will result in gdb trying to allocate an overly large buffer. If this large memory allocation fails then the result can be gdb either terminating, or (due to memory contention) becoming unresponsive for the user. A new user visible variable in gdb helps guard against such problems, two new commands are available: set max-value-size show max-value-size The 'max-value-size' is the maximum size of memory in bytes that gdb will allocate for the contents of a value. Any attempt to allocate a value with a size greater than this will result in an error. The initial default for this limit is set at 64k, this is based on a similar limit that exists within the ada specific code. It is possible for the user to set max-value-size to unlimited, in which case the old behaviour is restored. gdb/ChangeLog: * value.c (max_value_size): New variable. (MIN_VALUE_FOR_MAX_VALUE_SIZE): New define. (show_max_value_size): New function. (check_type_length_before_alloc): New function. (allocate_value_contents): Call check_type_length_before_alloc. (set_value_enclosing_type): Likewise. (_initialize_values): Add set/show handler for max-value-size. * NEWS: Mention new set/show command. gdb/doc/ChangeLog: * gdb.texinfo (Value Sizes): New section. (Data): Add the 'Value Sizes' node to the menu. gdb/testsuite/ChangeLog: * gdb.base/max-value-size.c: New file. * gdb.base/max-value-size.exp: New file. * gdb.base/huge.exp: Disable max-value-size for this test.
2016-01-31Fix some comments in varobj.{c,h}Simon Marchi3-6/+13
A few typos. The comment about varobj_create has been misplaced since the dawn of time. gdb/ChangeLog: * varobj.h (struct varobj): Fix typos in comments. (struct lang_varobj_ops): Likewise. * varobj.c (VAROBJ_TABLE_SIZE): Likewise. (varobj_create): Move misplaced comment.
2016-01-29Fix two misleading indentation warningsSimon Marchi3-16/+23
Two small changes so everything builds with latest GCC and its -Wmisleading-indentation. In the aarch64-tdep.c case, the two misindented lines should actually be part of the for loop. It looks like the indentation is all done using spaces in that file though... I fixed it (changed for tabs + spaces) for the lines I touched. In the xcoffread.c case, we can simply remove the braces and fix the indentation. gdb/ChangeLog: * aarch64-tdep.c (aarch64_record_asimd_load_store): Add braces to for include additional lines. * xcoffread.c (scan_xcoff_symtab): Remove unnecessary braces.
2016-01-28Add ChangeLog entry for update to gdb.dlang demangle tests.Iain Buclaw1-0/+4
2016-01-28Align dlang demangle tests with libiberty.Iain Buclaw1-15/+18
gdb/testsuite/ChangeLog: * gdb.dlang/demangle.exp: Sync tests from libiberty testsuite.
2016-01-28Add rawmemchr to imported gnulib modulesSimon Marchi5-3/+12
rawmemchr is a dependency of strchrnul, so it should be explicitly listed. gdb/ChangeLog: * gnulib/import/Makefile.am: Regenerate. * gnulib/import/Makefile.in: Regenerate. * gnulib/import/m4/gnulib-cache.m4: Regenerate. * gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add rawmemchr.
2016-01-28Import strchrnul from gnulib and use itSimon Marchi18-42/+639
For a forthcoming patch, I need a "skip_to_colon" function. I noticed there are two skip_to_semicolon (one in gdb and one in gdbserver). I thought we could put it in common/, and generalize it for any character. It turns out that the strchrnul function does exactly that. I imported the corresponding module from gnulib, for those systems that do not have it. There are probably more places where this function can be used instead of doing the work by hand (I am looking at remote-utils.c::look_up_one_symbol). gdb/ChangeLog: * remote.c (skip_to_semicolon): Remove. (remote_parse_stop_reply): Use strchrnul instead of skip_to_semicolon. * gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add strchrnul. * gnulib/aclocal.m4: Regenerate. * gnulib/config.in: Regenerate. * gnulib/configure: Regenerate. * gnulib/import/Makefile.am: Regenerate. * gnulib/import/Makefile.in: Regenerate. * gnulib/import/m4/gnulib-cache.m4: Regenerate. * gnulib/import/m4/gnulib-comp.m4: Regenerate. * gnulib/import/m4/rawmemchr.m4: New file. * gnulib/import/m4/strchrnul.m4: New file. * gnulib/import/rawmemchr.c: New file. * gnulib/import/rawmemchr.valgrind: New file. * gnulib/import/strchrnul.c: New file. * gnulib/import/strchrnul.valgrind: New file. gdb/gdbserver/ChangeLog: * server.c (skip_to_semicolon): Remove. (process_point_options): Use strchrnul instead of skip_to_semicolon.
2016-01-28[testsuite] Fix tiemout fail in gdb.fortran/vla-value.expYao Qi2-3/+17
In vla.f90, this single line of source is compiled to many instructions, vla2(:, :, :) = 1311 ! vla2-allocated it is quite slow (about several minutes in my testing) to step over this source line without range stepping. This patch is to increase the timeout value by 15 times, which is a magic number to make sure timeout disappears in my testing with a slow arm-linux board. gdb/testsuite: 2016-01-28 Yao Qi <yao.qi@linaro.org> * gdb.fortran/vla-value.exp: Wrap test with with_timeout_factor.
2016-01-28Fix GDB crash in dprintf.expYao Qi2-9/+6
I see GDB crashes in dprintf.exp on aarch64-linux testing, (gdb) PASS: gdb.base/dprintf.exp: agent: break 29 set dprintf-style agent^M (gdb) PASS: gdb.base/dprintf.exp: agent: set dprintf style to agent continue^M Continuing. ASAN:SIGSEGV ================================================================= ==22475==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x000000494820 sp 0x7fff389b83a0 bp 0x62d000082417 T0) #0 0x49481f in remote_add_target_side_commands /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9190^M #1 0x49e576 in remote_add_target_side_commands /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9174^M #2 0x49e576 in remote_insert_breakpoint /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:9240^M #3 0x5278b7 in insert_bp_location /home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:2734^M #4 0x52ac09 in insert_breakpoint_locations /home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:3159^M #5 0x52ac09 in update_global_location_list /home/yao/SourceCode/gnu/gdb/git/gdb/breakpoint.c:12686 the root cause of this problem in this case is about linespec and symtab which produces additional incorrect location and a NULL is added to bp_tgt->tcommands. I posted a patch https://sourceware.org/ml/gdb-patches/2015-12/msg00321.html to fix it in linespec (the fix causes regression), but GDB still shouldn't add NULL into bp_tgt->tcommands. The logic of build_target_command_list looks odd to me. If we get something wrong in parse_cmd_to_aexpr (it returns NULL), we shouldn't continue, instead we should set flag null_command_or_parse_error. This is what this patch does. In the meantime, we find build_target_condition_list has the same problem, so fix it too. gdb: 2016-01-28 Yao Qi <yao.qi@linaro.org> * breakpoint.c (build_target_command_list): Don't call continue if aexpr is NULL. (build_target_condition_list): Likewise.
2016-01-27rx: Treat scalars larger than 8 bytes as aggregates in rx_push_dummy_call.Kevin Buettner2-1/+7
This patch fixes the following failures (which are also GDB internal errors) for the -m64bit-doubles multilib: FAIL: gdb.base/callfuncs.exp: p t_double_complex_values(dc1, dc2) (GDB internal error) FAIL: gdb.base/callfuncs.exp: p t_double_complex_values(dc3, dc4) (GDB internal error) FAIL: gdb.base/callfuncs.exp: p t_double_complex_many_args(dc1, dc2, dc3, dc4, dc1, dc2, dc3, dc4, dc1, dc2, dc3, dc4, dc1, dc2, dc3, dc4) (GDB internal error) FAIL: gdb.base/callfuncs.exp: p t_double_complex_many_args(dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1) (GDB internal error) FAIL: gdb.base/callfuncs.exp: p t_long_double_complex_values(ldc1, ldc2) (GDB internal error) FAIL: gdb.base/callfuncs.exp: p t_long_double_complex_values(ldc3, ldc4) (GDB internal error) FAIL: gdb.base/callfuncs.exp: p t_long_double_complex_many_args(ldc1, ldc2, ldc3, ldc4, ldc1, ldc2, ldc3, ldc4, ldc1, ldc2, ldc3, ldc4, ldc1, ldc2, ldc3, ldc4) (GDB internal error) FAIL: gdb.base/callfuncs.exp: p t_long_double_complex_many_args(ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1,ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1) (GDB internal error) FAIL: gdb.base/callfuncs.exp: noproto: p t_double_complex_values(dc1, dc2) (GDB internal error) FAIL: gdb.base/callfuncs.exp: noproto: p t_double_complex_values(dc3, dc4) (GDB internal error) FAIL: gdb.base/callfuncs.exp: noproto: p t_double_complex_many_args(dc1, dc2, dc3, dc4, dc1, dc2, dc3, dc4, dc1, dc2, dc3, dc4, dc1, dc2, dc3, dc4) (GDB internal error) FAIL: gdb.base/callfuncs.exp: noproto: p t_double_complex_many_args(dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1, dc1) (GDB internal error) FAIL: gdb.base/callfuncs.exp: noproto: p t_long_double_complex_values(ldc1, ldc2) (GDB internal error) FAIL: gdb.base/callfuncs.exp: noproto: p t_long_double_complex_values(ldc3, ldc4) (GDB internal error) FAIL: gdb.base/callfuncs.exp: noproto: p t_long_double_complex_many_args(ldc1, ldc2, ldc3, ldc4, ldc1, ldc2, ldc3, ldc4, ldc1, ldc2, ldc3, ldc4, ldc1, ldc2, ldc3, ldc4) (GDB internal error) FAIL: gdb.base/callfuncs.exp: noproto: p t_long_double_complex_many_args(ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1,ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1, ldc1) (GDB internal error) FAIL: gdb.base/varargs.exp: print find_max_double_real(4, dc1, dc2, dc3, dc4) (GDB internal error) FAIL: gdb.base/varargs.exp: print find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4) (GDB internal error) The assertion failure which is tripped is: gdb_assert (arg_size <= 4); While it may seem that the patch ought to disallow scalars larger than 4, scalars of size 8 are explicitly handled by the code elsewhere. This came up because gcc has a complex type that is 16 bytes in length when 64-bit doubles are used. gdb/ChangeLog: * rx-tdep.c (rx_push_dummy_call): Treat scalars larger than 8 bytes as aggregates.
2016-01-27Add Keith Seitz as Linespec MaintainerJoel Brobecker2-0/+7
gdb/ChangeLog: * MAINTAINERS (Responsible Maintainers): Add Keith Seitz as Linespec Maintainers.
2016-01-26Fix function commentsSimon Marchi2-2/+7
Two obvious fixes. gdb/ChangeLog: * common/common-utils.c (skip_spaces): Fix comment. (skip_to_space_const): Likewise.
2016-01-26Fix subject verb agreement in the description of several debug settings.John Baldwin2-7/+11
gdb/doc/ChangeLog: * gdb.texinfo (Debugging Output): Fix subject verb disagreements.
2016-01-26Remove argument pc in get_next_pcsYao Qi9-21/+38
Nowadays, get_next_pcs in linux_target_ops has two parameters PC and REGCACHE. Parameter PC looks redundant because it can be go from REGCACHE. The patch is to remove PC from the arguments for various functions. gdb: 2016-01-26 Yao Qi <yao.qi@linaro.org> * arch/arm-get-next-pcs.c (thumb_deal_with_atomic_sequence_raw): Remove argument pc. Get pc by regcache_read_pc. Callers updated. (arm_deal_with_atomic_sequence_raw): Likewise. (thumb_get_next_pcs_raw): Likewise. (arm_get_next_pcs_raw): Likewise. (arm_get_next_pcs): Remove argument pc. Callers updated. * arch/arm-get-next-pcs.h (arm_get_next_pcs): Update declaration. gdb/gdbserver: 2016-01-26 Yao Qi <yao.qi@linaro.org> * linux-arm-low.c (arm_gdbserver_get_next_pcs): Remove argument pc. * linux-low.c (install_software_single_step_breakpoints): Don't call regcache_read_pc. * linux-low.h (struct linux_target_ops) <get_next_pcs>: Remove argument pc.
2016-01-26[GDBserver] Use regcache_read_pc in install_software_single_step_breakpointsYao Qi2-1/+7
In install_software_single_step_breakpoints, we've got the regcache of current_thread, so we don't have to bother get_pc to get pc, instead we can get pc from regcache directly. Note that the callers of install_software_single_step_breakpoints have already switched current_thread to LWP. Since the pc is got from regcache_read_pc, in the next patch, we can get pc inside the implementation of *the_low_target.get_next_pcs and stop passing pc to *the_low_target.get_next_pcs. gdb/gdbserver: 2016-01-26 Yao Qi <yao.qi@linaro.org> * linux-low.c (install_software_single_step_breakpoints): Call regcache_read_pc instead of get_pc.
2016-01-26[GDBserver] Block and unblock SIGIOYao Qi2-14/+30
Nowadays, GDBserver disables async io (by ignoring SIGIO) when process a serial event, and enables async io (by installing signal handler) when resume the inferior and wait. GDBserver may miss SIGIO (by interrupt) and doesn't process SIGIO in time, which is shown by gdb.base/interrupt-noterm.exp. In the test, GDB sends "continue &" and then "interrupt". if '\003' arrives at a period between GDBserver receives vCont;c and enables async io, SIGIO is ignored because signal handler isn't installed. GDBserver waits for the inferior and can not notice '\003' until it returns from wait. This patch changes the code to install SIGIO handler early, but block and unblock SIGIO as needed. In this way, we don't remove SIGIO handler, so SIGIO can't be ignored. However, GDBserver needs to remove the signal handler when connection is closed. gdb/gdbserver: 2016-01-26 Yao Qi <yao.qi@linaro.org> * remote-utils.c (remote_close) [!USE_WIN32API]: Ignore SIGIO. (unblock_async_io): Rename to ... (block_unblock_async_io): ... it. New function. (enable_async_io): Don't install SIGIO handler. Unblock it instead. (disable_async_io): Don't ignore SIGIO. Block it instead. (initialize_async_io): Install SIGIO handler. Don't call unblock_async_io.
2016-01-26[GDBserver] Check input interrupt after reading in a packetYao Qi2-0/+21
GDBserver may read some packet together with '\003' in one go. We've already checked '\003' first when reading packet by my patch, Check input interrupt first when reading packet https://sourceware.org/ml/gdb-patches/2016-01/msg00057.html but if we don't check '\003' *after* each packet, the interrupt will be processed next time GDBserver reads from the buffer, so that the interrupt isn't processed in time. For example, GDB sends vCont;c and interrupt (see gdb.base/interrupt-noterm.exp), we'll resume the inferior and wait once packet vCont;c is seen. If we don't check the interrupt character after vCont;c packet, interrupt character will stay in the buffer unattended until GDBserver returns from the wait, which may take a while. Note that since we've read '\003' from file descriptor, SIGIO signal handler input_interrupt doesn't help either. This issue can be exposed by hacking the end of getpkt like @@ -1041,6 +1050,9 @@ getpkt (char *buf) } } + if (readchar_bufcnt > 0) + gdb_assert (*readchar_bufp != '\003'); + return bp - buf; } and this can trigger internal error, (gdb) PASS: gdb.base/interrupt-noterm.exp: interrupt Remote connection closed^M (gdb) FAIL: gdb.base/interrupt-noterm.exp: inferior received SIGINT Remote debugging from host 10.2.206.40^M /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/remote-utils.c:1054: A problem internal to GDBserver has been detected.^M getpkt: Assertion `*readchar_bufp != '\003'' failed.^M This patch is to peek the buffer, if it is '\003', consume it and call *the_target->request_interrupt. gdb/gdbserver: 2016-01-26 Yao Qi <yao.qi@linaro.org> * remote-utils.c (getpkt): If the buffer isn't empty, and the first character is '\003', call *the_target->request_interrupt.
2016-01-26Fix GCC6 -Wmisleading-indentation issues.Mark Wielaard5-29/+42
GCC6 will warn about misleading indentation issues like: gdb/ada-lang.c: In function ‘ada_evaluate_subexp’: ada-lang.c:11423:9: error: statement is indented as if it were guarded by... arg1 = unwrap_value (arg1); ^~~~ gdb/ada-lang.c:11421:7: note: ...this ‘else’ clause, but it is not else ^~~~ In this case it would be a bug except for the fact the if clause already returned early. So this misindented statement really only got executed for the else case. But it could easily mislead a reader, so adding a proper else block is the correct solution. In case of c-typeprint.c (c_type_print_base) the if statement is indeed misleadingly indented, but not a bug. Just indent correctly. The inflow.c (terminal_ours_1) misindented block comes from the removal of an if clause in commit d9d2d8b which looks correct. Just introduce an else to fixup the indentation of the block. The linux-record.c misleadingly indented return statements are just that. Misleading to the reader, but not actual bugs. Just unindent them so they don't look like they fall under the wrong if clause.
2016-01-25Remove new_thread_notify and dead_thread_notifyYao Qi3-35/+7
They were added by PATCH: Multithreaded debugging for gdbserver https://sourceware.org/ml/gdb-patches/2002-06/msg00157.html but as a no-op, and the last usage of them was removed by [gdbserver/RFC/RFA] Implement multiprocess extensions, add linux multiproces support. https://sourceware.org/ml/gdb-patches/2009-03/msg00667.html This patch is to remove them. gdb/gdbserver: 2016-01-25 Yao Qi <yao.qi@linaro.org> * remote-utils.c (new_thread_notify): Remove. (dead_thread_notify): Likewise. * remote-utils.h (new_thread_notify): Remove declaration. (dead_thread_notify): Likewise.
2016-01-25Fix PR 19461: strange "info thread" behavior in non-stopPedro Alves5-0/+269
If you have "set follow-fork child" set, then if you do "info threads" right after a fork, and before the child reports any other event to GDB core, you'll see: (gdb) info threads Id Target Id Frame * 1.1 Thread 0x7ffff7fc1740 (LWP 31875) "fork-plus-threa" (running) 2.1 process 31879 "fork-plus-threa" Selected thread is running. (gdb) The "Selected thread is running." bit is a bogus error. That was GDB trying to fetch the current frame of thread 2.1, because the external runnning state is "stopped", and then throwing an error because the thread is actually running. This actually affects all-stop + schedule-multiple as well. The problem here is that on a fork event, GDB doesn't update the external parent/child running states. New comprehensive test included. The "kill inferior 1" / "kill inferior 2" bits also trip on PR gdb/19494 (hang killing unfollowed fork children), which was fixed by the previous patch. gdb/ChangeLog: 2016-01-25 Pedro Alves <palves@redhat.com> PR threads/19461 * infrun.c (handle_inferior_event_1) <fork/vfork>: Update parent/child running states. gdb/testsuite/ChangeLog: 2016-01-25 Pedro Alves <palves@redhat.com> PR threads/19461 * gdb.base/fork-running-state.c: New file. * gdb.base/fork-running-state.exp: New file.
2016-01-25Fix PR 19494: hang when killing unfollowed fork childrenPedro Alves5-35/+281
linux_nat_kill relies on get_last_target_status to determine whether the current inferior is stopped at a unfollowed fork/vfork event. This is bad because many things can happen ever since we caught the fork/vfork event... This commit rewrites that code to instead walk the thread list looking for unfollowed fork events, similarly to what was done for remote.c. New test included. The main idea of the test is make sure that when the program stops for a fork catchpoint, and the user kills the parent, gdb also kills the unfollowed fork child. Since the child hasn't been added as an inferior at that point, we need some other portable way to detect that the child is gone. The test uses a pipe for that. The program forks twice, so you have grandparent, child and grandchild. The grandchild inherits the write side of the pipe. The grandparent hangs reading from the pipe, since nothing ever writes to it. If, when GDB kills the child, it also kills the grandchild, then the grandparent's pipe read returns 0/EOF and the test passes. Otherwise, if GDB doesn't kill the grandchild, then the pipe read never returns and the test times out, like: FAIL: gdb.base/catch-fork-kill.exp: fork-kind=fork: exit-kind=kill: fork: kill parent (timeout) FAIL: gdb.base/catch-fork-kill.exp: fork-kind=vfork: exit-kind=kill: vfork: kill parent (timeout) No regressions on x86_64 Fedora 20. New test passes with gdbserver as well. gdb/ChangeLog: 2016-01-25 Pedro Alves <palves@redhat.com> PR gdb/19494 * linux-nat.c (kill_one_lwp): New, factored out from ... (kill_callback): ... this. (kill_wait_callback): New, factored out from ... (kill_wait_one_lwp): ... this. (kill_unfollowed_fork_children): New function. (linux_nat_kill): Use it. gdb/testsuite/ChangeLog: 2016-01-25 Pedro Alves <palves@redhat.com> PR gdb/19494 * gdb.base/catch-fork-kill.c: New file. * gdb.base/catch-fork-kill.exp: New file.
2016-01-25Move foreach_with_prefix to lib/gdb.expPedro Alves5-36/+22
gdb/testsuite/ChangeLog: 2016-01-25 Pedro Alves <palves@redhat.com> * gdb.base/step-sw-breakpoint-adjust-pc.exp (foreach_with_prefix): Delete, moved to lib/gdb.exp. * gdb.threads/forking-threads-plus-breakpoint.exp (foreach_with_prefix): Likewise. * gdb.threads/process-dies-while-handling-bp.exp (foreach_with_prefix): Likewise. * lib/gdb.exp (foreach_with_prefix): New procedure.
2016-01-25Delete ChangeLog entry from the wrong placePedro Alves1-63/+0
Missed actually removing this in 37e42b4fe92c...
2016-01-25gdb.trace/testsuite: Bump stack collection fudge factor.Marcin Kościelnicki3-2/+7
These two tests collect 64 words from $sp onwards, hoping that's enough to capture a few whole stack frames. Unfortunately, that's not enough for s390, which tends to have large frame sizes - minimum 24 words on s390, 20 on s390x (which just barely passes). Bump it to 128 words, let's hope no machine needs more. Tested on x86_64, s390, s390x. gdb/testsuite/ChangeLog: * gdb.trace/backtrace.exp: Bump stack collection fudge factor. * gdb.trace/entry-values.exp: Bump stack collection fudge factor.
2016-01-23gdb.trace: Fix unavailable-dwarf-piece.exp on big endian targetsMarcin Kościelnicki2-3/+22
The test constructs fake DWARF info for a C structure involving bitfields. DWARF bitfields are always counted from LSB, while the order in which bitfields are allocated in a C struct depends on the target endianness - thus the generated DWARF marks different bitfields as unavailable when target is big endian. Accordingly, we need different expected outputs. Tested on s390 and s390x, no regression on x86_64. gdb/testsuite/ChangeLog: * gdb.trace/unavailable-dwarf-piece.exp: Fix bitfield handling on big endian targets.
2016-01-23gdb.trace: Fix another expected message on continue.Marcin Kościelnicki2-1/+5
Missed one message in bd0a71fa16f668341a9361c695bc3ca44d27b322, since it didn't trigger on s390x or amd64 (fast tracepoint out of range due to shared library usage), noticed on s390. Pushed as obvious. gdb/testsuite/ChangeLog: * gdb.trace/pending.exp: Fix expected message on continue.
2016-01-22testsuite: gdb.gdb/selftest.exp: Drop expected Thread numberJan Kratochvil2-1/+8
Pedro Alves: Looks like you forgot to amend before pushing though -- the version checked in still had "Thread 1". gdb/testsuite/ChangeLog 2016-01-22 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> Fix testsuite compatibility with Guile. * gdb.gdb/selftest.exp (send ^C to child process): Drop expected Thread number.
2016-01-22testsuite: Fix PR threads/19422 regression + Guile regressionJan Kratochvil2-1/+12
The PR threads/19422 patchset added a new regression. Additionally below it there was already a regression if --with-guile (which is default if Guile is found) was used. racy case #1: (xgdb) PASS: gdb.gdb/selftest.exp: Set xgdb_prompt ^M Thread 1 "xgdb" received signal SIGINT, Interrupt.^M 0x00007ffff583bfdd in poll () from /lib64/libc.so.6^M (gdb) FAIL: gdb.gdb/selftest.exp: send ^C to child process signal SIGINT^M Continuing with signal SIGINT.^M ^C^M Thread 1 "xgdb" received signal SIGINT, Interrupt.^M 0x00007ffff5779da0 in sigprocmask () from /lib64/libc.so.6^M (gdb) PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process backtrace^M errstring=errstring@entry=0x7e0e6c "", mask=mask@entry=RETURN_MASK_ALL) at exceptions.c:240^M errstring=errstring@entry=0x7e0e6c "", mask=mask@entry=RETURN_MASK_ALL) at exceptions.c:240^M (gdb) PASS: gdb.gdb/selftest.exp: backtrace through signal handler racy case #2: (xgdb) PASS: gdb.gdb/selftest.exp: Set xgdb_prompt ^M Thread 1 "xgdb" received signal SIGINT, Interrupt.^M 0x00007ffff583bfdd in poll () from /lib64/libc.so.6^M (gdb) FAIL: gdb.gdb/selftest.exp: send ^C to child process signal SIGINT^M Continuing with signal SIGINT.^M ^C^M Thread 2 "xgdb" received signal SIGINT, Interrupt.^M [Switching to Thread 0x7ffff3b7f700 (LWP 13227)]^M 0x00007ffff6b88b10 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0^M (gdb) PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process backtrace^M (gdb) FAIL: gdb.gdb/selftest.exp: backtrace through signal handler Pedro Alves: Not all targets support thread names, and even those that do, not all use the program name as default thread name -- I think that's only true for GNU/Linux, actually. So I think it's best to not expect that, like: -re "(Thread .*|Program) received signal SIGINT.*$gdb_prompt $" { gdb/testsuite/ChangeLog 2016-01-22 Jan Kratochvil <jan.kratochvil@redhat.com> Fix testsuite compatibility with Guile. * gdb.gdb/selftest.exp (send ^C to child process): Accept also Thread. (thread 1): New test for backtrace through signal handler.
2016-01-22Reword the string description of native FreeBSD ptids.John Baldwin2-1/+5
The prior format led to confusing messages when threads were created or added such as "[New process 14757, LWP 100537]". The new format reports this as "[New LWP 100434 of process 15652]". gdb/ChangeLog: * fbsd-nat.c (fbsd_pid_to_str): Adjust string format.
2016-01-22gdb.trace: Fix write_inferior_data_ptr on 32-bit big-endian machines.Marcin Kościelnicki2-3/+10
Noticed and tested on 31-bit s390. This bug caused completely broken fast tracepoints. gdb/gdbserver/ChangeLog: * tracepoint.c (write_inferior_data_ptr): Cast to uintptr_t, so that it works properly on big-endian machines where sizeof (CORE_ADDR) != sizeof (void *).
2016-01-22[testsuite] Unbuffer the output in gdb.base/multi-forks.cYao Qi2-0/+11
This patch unbuffer the output of the program so that the test harness can count the number of "done" from output correctly. gdb/testsuite: 2016-01-22 Yao Qi <yao.qi@linaro.org> PR testsuite/19491 * gdb.base/multi-forks.c: Include ../lib/unbuffer_output.c (main): Call gdb_unbuffer_output.
2016-01-22[ARM] perror_with_name when failed to fetch/store registersYao Qi2-48/+20
I see the following test fail on native arm-linux gdb testing... (gdb) PASS: gdb.base/killed-outside.exp: registers: get pid of inferior Executing on target: kill -9 2346 (timeout = 300) spawn kill -9 2346^M flushregs^M Register cache flushed.^M warning: Unable to fetch general registers.^M PC not available^M (gdb) PASS: gdb.base/killed-outside.exp: registers: flushregs info threads^M Id Target Id Frame ^M * 1 process 2346 "killed-outside" (gdb) FAIL: gdb.base/killed-outside.exp: registers: info threads (timeout) since the inferior disappeared, ptrace will fail. In that case, the exception should be thrown, so that the caller can handle that. gdb: 2016-01-22 Yao Qi <yao.qi@linaro.org> * arm-linux-nat.c (fetch_fpregs): Call perror_with_name instead of warning. (store_fpregs, fetch_regs, store_regs): Likewise. (fetch_wmmx_regs, store_wmmx_regs): Likewise. (fetch_vfp_regs, store_vfp_regs): Likewise.
generated by cgit v1.1 at 2024-07-28 11:52:22 +0000