summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-04-27ILP32: GDBHEADgdb-8.1-amp-branchYao Qi
Rebased 5e5a2a68c772d59c41d4e536949ce4ba3dc9b3ea from linaro's gdb-aarch64-ilp32 branch on GDB 8.1-release. gdb: 2017-03-06 Andrew Pinski <apinski@cavium.com> Steve Ellcey <sellcey@cavium.com> Yao Qi <yao.qi@linaro.org> * aarch64-linux-nat.c (IS_ARM32): New macro. (fetch_gregs_from_thread): Use IS_ARM32 macro. (store_gregs_to_thread): Ditto. (fetch_fpregs_from_thread): Ditto. (store_fpregs_to_thread): Ditto. (ps_get_thread_area): Ditto. (aarch64_linux_siginfo_fixup): Ditto. * aarch64-linux-tdep.c (aarch64_linux_init_abi): Set link map offsets to 32 or 64 bits. * aarch64-tdep.c (aarch64_ilp32_register_type): New function. (aarch64_gdbarch_init): Setup ILP32 support. Make sure the gdbarches have compatible ilp32 flags. Set long and ptr sizes correctly for ilp32. * aarch64-tdep.h (gdbarch_tdep) <ilp32>: New field. gdb/gdbserver: 2017-03-06 Andrew Pinski <apinski@cavium.com> Steve Ellcey <sellcey@cavium.com> * linux-aarch64-low.c (aarch64_linux_read_description):
2018-04-27ILP32: BFDYao Qi
Rebased 2c5e2ba3ced851a18c488c630abd00ca99523bbd from linaro's gdb-aarch64-ilp32 branch on GDB 8.1-release. bfd: 2017-03-06 Andrew Pinski <apinski@cavium.com> Steve Ellcey <sellcey@cavium.com> * cpu-aarch64.c (compatible): Don't reject different ILP32/LP64 ABI's here. * elfnn-aarch64.c (elfNN_aarch64_merge_private_bfd_data): Add an error message on why endianess is rejected. Reject different ILP32/LP64 ABI settings. * elfxx-aarch64.c (_bfd_aarch64_elf_grok_prstatus): Handle size and offset of ILP32 executables. (_bfd_aarch64_elf_grok_psinfo): Ditto.
2018-01-31Set GDB version number to 8.1.Joel Brobecker
gdb/ChangeLog: * version.in: Set GDB version number to 8.1. * PROBLEMS: Likewise.
2018-01-31Automatic date update in version.inGDB Administrator
2018-01-30Automatic date update in version.inGDB Administrator
2018-01-29Automatic date update in version.inGDB Administrator
2018-01-28Automatic date update in version.inGDB Administrator
2018-01-27Avoid compilation errors in MinGW native builds of GDBEli Zaretskii
The error is triggered by including python-internal.h, and the error message is: In file included from d:\usr\lib\gcc\mingw32\6.3.0\include\c++\math.h:36:0, from build-gnulib/import/math.h:27, from d:/usr/Python26/include/pyport.h:235, from d:/usr/Python26/include/Python.h:58, from python/python-internal.h:94, from python/py-arch.c:24: d:\usr\lib\gcc\mingw32\6.3.0\include\c++\cmath:1157:11: error: '::hypot' has not been declared using ::hypot; ^~~~~ This happens because Python headers define 'hypot' to expand to '_hypot' in the Windows builds. gdb/ChangeLog: 2018-01-27 Eli Zaretskii <eliz@gnu.org> * python/python-internal.h (_hypot) [__MINGW32__]: Define back to 'hypoth'. This avoids a compilation error. (cherry picked from commit b2a426e2c5632644b6b8bc0dde4cd32d42d548e2)
2018-01-27Avoid compilation warning in libiberty/simple-object-xcoff.cEli Zaretskii
gdb/ChangeLog: 2018-01-27 Eli Zaretskii <eliz@gnu.org> * simple-object-xcoff.c (simple_object_xcoff_find_sections): Avoid compilation warning in 32-bit builds not supported by AC_SYS_LARGEFILE. (cherry picked from commit de54ee813f35cdeee51729c6d50b82935dc88634)
2018-01-27Automatic date update in version.inGDB Administrator
2018-01-26Automatic date update in version.inGDB Administrator
2018-01-25Automatic date update in version.inGDB Administrator
2018-01-24Fix GCC PR83906 - [8 Regression] Random FAIL: ↵Pedro Alves
libstdc++-prettyprinters/80276.cc whatis p4 GCC PR83906 [1] is about a GCC/libstdc++ GDB/Python type printer testcase failing randomly, as shown by running (in libstdc++'s testsuite): make check RUNTESTFLAGS=prettyprinters.exp=80276.cc in a loop. Sometimes you get this: FAIL: libstdc++-prettyprinters/80276.cc whatis p4 I.e., this: type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >>[]>>[99]> instead of this: type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::string>[]>>[99]> Jonathan Wakely tracked it on the printer side to this bit in libstdc++'s type printer: if self.type_obj == type_obj: return strip_inline_namespaces(self.name) This assumes the two types resolve to the same gdb.Type but some times the comparison unexpectedly fails. Running the testcase manually under Valgrind finds the problem in GDB: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ==6118== Conditional jump or move depends on uninitialised value(s) ==6118== at 0x4C35CB0: bcmp (vg_replace_strmem.c:1100) ==6118== by 0x6F773A: check_types_equal(type*, type*, VEC_type_equality_entry_d**) (gdbtypes.c:3515) ==6118== by 0x6F7B00: check_types_worklist(VEC_type_equality_entry_d**, bcache*) (gdbtypes.c:3618) ==6118== by 0x6F7C03: types_deeply_equal(type*, type*) (gdbtypes.c:3655) ==6118== by 0x4D5B06: typy_richcompare(_object*, _object*, int) (py-type.c:1007) ==6118== by 0x63D7E6C: PyObject_RichCompare (object.c:961) ==6118== by 0x646EAEC: PyEval_EvalFrameEx (ceval.c:4960) ==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519) ==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519) ==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519) ==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519) ==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ That "bcmp" call is really a memcmp call in check_types_equal. The problem is that gdb is memcmp'ing two objects that are equal in value: (top-gdb) p *TYPE_RANGE_DATA (type1) $1 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0, flag_bound_evaluated = 0} (top-gdb) p *TYPE_RANGE_DATA (type2) $2 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0, flag_bound_evaluated = 0} but differ in padding. Notice the 4-byte hole: (top-gdb) ptype /o range_bounds /* offset | size */ type = struct range_bounds { /* 0 | 16 */ struct dynamic_prop { /* 0 | 4 */ dynamic_prop_kind kind; /* XXX 4-byte hole */ /* 8 | 8 */ union dynamic_prop_data { /* 8 */ LONGEST const_val; /* 8 */ void *baton; /* total size (bytes): 8 */ } data; which is filled with garbage: (top-gdb) x /40bx TYPE_RANGE_DATA (type1) 0x2fa7ea0: 0x01 0x00 0x00 0x00 0x43 0x01 0x00 0x00 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0x2fa7ea8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x2fa7eb0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00 0x2fa7eb8: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x2fa7ec0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 (top-gdb) x /40bx TYPE_RANGE_DATA (type2) 0x20379b0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0x20379b8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20379c0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00 0x20379c8: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20379d0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 (top-gdb) p memcmp (TYPE_RANGE_DATA (type1), TYPE_RANGE_DATA (type2), sizeof (*TYPE_RANGE_DATA (type1))) $3 = -187 In some cases objects of type range_bounds are memset when allocated, but then their dynamic_prop low/high fields are copied over from some template dynamic_prop object that wasn't memset. E.g., create_static_range_type's low/high locals are left with garbage in the padding, and then that padding is copied over to the range_bounds object's low/high fields. At first, I considered making sure to always memset range_bounds objects, thinking that maybe type objects are being put in some bcache instance somewhere. But then I hacked bcache/bcache_full to poison non-pod types, and made dynamic_prop a non-pod, and GDB still compiled. So given that, it seems safest to not assume padding will always be memset, and instead treat them as regular value types, implementing (in)equality operators and using those instead of memcmp. This fixes the random FAILs in GCC's testcase. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 gdb/ChangeLog: 2018-01-24 Pedro Alves <palves@redhat.com> GCC PR libstdc++/83906 * gdbtypes.c (operator==(const dynamic_prop &, const dynamic_prop &)): New. (operator==(const range_bounds &, const range_bounds &)): New. (check_types_equal): Use them instead of memcmp. * gdbtypes.h (operator==(const dynamic_prop &, const dynamic_prop &)): Declare. (operator!=(const dynamic_prop &, const dynamic_prop &)): Declare. (operator==(const range_bounds &, const range_bounds &)): Declare. (operator!=(const range_bounds &, const range_bounds &)): Declare.
2018-01-24Automatic date update in version.inGDB Administrator
2018-01-23Automatic date update in version.inGDB Administrator
2018-01-22MAINTAINERS: Update my company e-mail addressMaciej W. Rozycki
Following my recent transition from Imagination Technologies to the reincarnated MIPS company update MAINTAINERS entries accordingly. binutils/ * MAINTAINERS: Update my company e-mail address. gdb/ * MAINTAINERS: Update my company e-mail address. sim/ * MAINTAINERS: Update my company e-mail address. (cherry picked from commit d65ce302abcb260e14ca5f201b78e8e6d4a2e720)
2018-01-22Fix segfault with 'set print object on' + 'whatis <struct>' & coPedro Alves
Compiling GDB with a recent GCC exposes a problem: ../../gdb/typeprint.c: In function 'void whatis_exp(const char*, int)': ../../gdb/typeprint.c:515:12: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized] real_type = value_rtti_type (val, &full, &top, &using_enc); ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The warning is correct. There are indeed code paths that use uninitialized 'val', leading to crashes. Inside the value_rtti_indirect_type/value_rtti_type calls here in whatis_exp: if (opts.objectprint) { if (((TYPE_CODE (type) == TYPE_CODE_PTR) || TYPE_IS_REFERENCE (type)) && (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_STRUCT)) real_type = value_rtti_indirect_type (val, &full, &top, &using_enc); else if (TYPE_CODE (type) == TYPE_CODE_STRUCT) real_type = value_rtti_type (val, &full, &top, &using_enc); } We reach those calls above with "set print object on", and then with any of: (gdb) whatis struct some_structure_type (gdb) whatis struct some_structure_type * (gdb) whatis struct some_structure_type & because "whatis" with a type argument enters this branch: /* The behavior of "whatis" depends on whether the user expression names a type directly, or a language expression (including variable names). If the former, then "whatis" strips one level of typedefs, only. If an expression, "whatis" prints the type of the expression without stripping any typedef level. "ptype" always strips all levels of typedefs. */ if (show == -1 && expr->elts[0].opcode == OP_TYPE) { which does not initialize VAL. Trying the above triggers crashes like this: (gdb) set print object on (gdb) whatis some_structure_type Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. 0x00000000005dda90 in check_typedef (type=0x6120736573756170) at src/gdb/gdbtypes.c:2388 2388 int instance_flags = TYPE_INSTANCE_FLAGS (type); ... This is a regression caused by a recent-ish refactoring of the code on 'whatis_exp', introduced by: commit c973d0aa4a2c737ab527ae44a617f1c357e07364 Date: Mon Aug 21 11:34:32 2017 +0100 Fix type casts losing typedefs and reimplement "whatis" typedef stripping Fix this by setting VAL to NULL in the "whatis TYPE" case, and skipping fetching the dynamic type if there's no value to fetch it from. New tests included. gdb/ChangeLog: 2018-01-22 Pedro Alves <palves@redhat.com> Sergio Durigan Junior <sergiodj@redhat.com> * typeprint.c (whatis_exp): Initialize "val" in the "whatis type" case. gdb/testsuite/ChangeLog: 2018-01-22 Pedro Alves <palves@redhat.com> Sergio Durigan Junior <sergiodj@redhat.com> * gdb.base/whatis.exp: Add tests for 'set print object on' + 'whatis <struct>' 'whatis <struct> *' and 'whatis <struct> &'.
2018-01-22Automatic date update in version.inGDB Administrator
2018-01-21Automatic date update in version.inGDB Administrator
2018-01-20Automatic date update in version.inGDB Administrator
2018-01-19Automatic date update in version.inGDB Administrator
2018-01-18Automatic date update in version.inGDB Administrator
2018-01-17Fix warning on gdb/compile/compile.c (C++-ify "triplet_rx")Sergio Durigan Junior
This fixes a GCC warning that happens when compiling gdb/compile/compile.c on some GCC versions (e.g., "gcc (GCC) 7.2.1 20180104 (Red Hat 7.2.1-6)"): ../../gdb/compile/compile.c: In function 'void eval_compile_command(command_line*, const char*, compile_i_scope_types, void*)': ../../gdb/compile/compile.c:548:19: warning: 'triplet_rx' may be used uninitialized in this function [-Wmaybe-uninitialized] error_message = compiler->fe->ops->set_arguments_v0 (compiler->fe, triplet_rx, ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ argc, argv); ~~~~~~~~~~~ ../../gdb/compile/compile.c:466:9: note: 'triplet_rx' was declared here char *triplet_rx; ^~~~~~~~~~ It's a simple patch that converts "triplet_rx" from "char *" to "std::string", thus guaranteeing that it will be always initialized. I've regtested this patch and did not find any regressions. OK to apply on both master and 8.1 (after creating a bug for it)? gdb/ChangeLog: 2018-01-17 Sergio Durigan Junior <sergiodj@redhat.com> * compile/compile.c (compile_to_object): Convert "triplet_rx" to "std::string".
2018-01-17configure: Fix test for fs_base/gs_base in <sys/user.h>Eldar Abusalimov
Make <sys/types.h> be included prior to including <sys/user.h>. glibc versions older than 2.14 use __uintNN_t types within certain structures defined in <sys/user.h> probably assuming these types are defined prior to including the header. This results in the following `configure` feature test compilation error that makes it think that `struct user_regs_struct` doesn't have `fs_base`/`gs_base` fields, althouh it does. configure:13617: checking for struct user_regs_struct.fs_base configure:13617: gcc -c -g -O2 -I/linux/include conftest.c >&5 In file included from conftest.c:158:0: /usr/include/sys/user.h:32:3: error: unknown type name '__uint16_t' __uint16_t cwd; ^ /usr/include/sys/user.h:33:3: error: unknown type name '__uint16_t' __uint16_t swd; ^ /usr/include/sys/user.h:34:3: error: unknown type name '__uint16_t' __uint16_t ftw; ^ /usr/include/sys/user.h:35:3: error: unknown type name '__uint16_t' __uint16_t fop; ^ /usr/include/sys/user.h:36:3: error: unknown type name '__uint64_t' __uint64_t rip; ^ /usr/include/sys/user.h:37:3: error: unknown type name '__uint64_t' __uint64_t rdp; ^ /usr/include/sys/user.h:38:3: error: unknown type name '__uint32_t' __uint32_t mxcsr; ^ /usr/include/sys/user.h:39:3: error: unknown type name '__uint32_t' __uint32_t mxcr_mask; ^ /usr/include/sys/user.h:40:3: error: unknown type name '__uint32_t' __uint32_t st_space[32]; /* 8*16 bytes for each FP-reg = 128 bytes */ ^ /usr/include/sys/user.h:41:3: error: unknown type name '__uint32_t' __uint32_t xmm_space[64]; /* 16*16 bytes for each XMM-reg = 256 bytes */ ^ /usr/include/sys/user.h:42:3: error: unknown type name '__uint32_t' __uint32_t padding[24]; ^ configure:13617: $? = 1 configure: failed program was: | /* confdefs.h */ ... | /* end confdefs.h. */ | #include <sys/user.h> | | int | main () | { | static struct user_regs_struct ac_aggr; | if (ac_aggr.fs_base) | return 0; | ; | return 0; | } Recent glibc versions don't use typedef'ed int types in <sys/user.h>, thus allowing it to be included as is (glibc commit d79a9c949c84e7f0ba33e87447c47af833e9f11a). However there're still some distros alive that use older glibc, for instance, RHEL/CentOS 6 package glibc 2.12. Also affects PR gdb/21559: ../../gdb/regcache.c:1087: internal-error: void regcache_raw_supply(regcache, int, const void): Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed. As noted by Andrew Paprocki, who submitted the PR (https://sourceware.org/bugzilla/show_bug.cgi?id=21559#c3): > It should be noted that modifying `configure` to force on > `HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE` and > `HAVE_STRUCT_USER_REGS_STRUCT_GS_BASE` fixes this issue. For some > reason the `configure` tests for `fs_base` and `gs_base` fail > even though `sys/user.h` on RHEL5 has the fields defined in > `user_regs_struct`. Note that this patch does NOT fix the root cause of PR gdb/21559, although now that `configure` properly detects the presence of the fields and sets HAVE_XXX accordingly, the execution takes another path, which doesn't lead to the assertion failure in question. gdb/ChangeLog: 2018-01-17 Eldar Abusalimov <eldar.abusalimov@jetbrains.com> PR gdb/21559 * configure.ac: Include <sys/types.h> prior to <sys/user.h> when checking for fs_base/gs_base fields in struct user_regs_struct. * configure: Regenerate. gdb/gdbserver/ChangeLog: 2018-01-17 Eldar Abusalimov <eldar.abusalimov@jetbrains.com> PR gdb/21559 * configure.ac: Include <sys/types.h> prior to <sys/user.h> when checking for fs_base/gs_base fields in struct user_regs_struct. * configure: Regenerate.
2018-01-17Don't pass -m64 to libcc1 on aarch64-linux.Yao Qi
Nowadays, if we use "compile" on aarch64-linux, we'll get the following error, (gdb) compile code -- ; aarch64-none-linux-gnu-gcc: error: unrecognized command line option '-m64' because the default gcc_target_options returns "-m64" and "-mcmodel=large", neither is useful to aarch64-linux. gdb: 2018-01-17 Yao Qi <yao.qi@linaro.org> * aarch64-linux-tdep.c (aarch64_linux_gcc_target_options): New function. (aarch64_linux_init_abi): Install it to gdbarch hook gcc_target_options.
2018-01-17Relax gdb.compile/compile.exp to match the address printed for frameYao Qi
One test in gdb.compile/compile.exp passes on one fedora builder, bt #0 0x00007ffff7ff43f6 in _gdb_expr (__regs=0x7ffff7ff2000) at gdb command line:1^M #1 <function called from gdb>^M #2 main () at /home/gdb-buildbot/fedora-x86-64-1/fedora-x86-64/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.compile/compile.c:106^M (gdb) PASS: gdb.compile/compile.exp: bt but fails on my machine with gcc trunk, bt^M #0 _gdb_expr (__regs=0x7ffff7ff3000) at gdb command line:1^M #1 <function called from gdb>^M #2 main () at gdb/testsuite/gdb.compile/compile.c:106^M (gdb) FAIL: gdb.compile/compile.exp: bt The test should be tweaked to match both cases (pc in the start of line vs pc in the middle of line). Note that I am not clear that why libcc1 emits debug info this way so that the address is in the middle of line. gdb/testsuite: 2018-01-17 Yao Qi <yao.qi@linaro.org> * gdb.compile/compile.exp: Match the address printed for frame in the output of command "bt".
2018-01-17Automatic date update in version.inGDB Administrator
2018-01-16Automatic date update in version.inGDB Administrator
2018-01-15Fix scm-ports.exp regressionTom Tromey
In https://sourceware.org/ml/gdb-patches/2017-12/msg00215.html, Jan pointed out that the scalar printing patches caused a regression in scm-ports.exp on x86. What happens is that on x86, this: set sp_reg [get_integer_valueof "\$sp" 0] ... ends up setting sp_reg to a negative value, because get_integer_valueof uses "print/d": print /d $sp $1 = -11496 Then later the test suite does: gdb_test "guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))" \ "= $sp_reg" \ "seek to \$sp" ... expecting this value to be identical to the saved $sp_reg value. However it gets: guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET)) = 4294955800 "print" is just a wrapper for guile's format: gdb_test_no_output "guile (define (print x) (format #t \"= ~A\" x) (newline))" The seek function returns a scm_t_off, the printing of which is handled by guile, not by gdb. Tested on x86-64 Fedora 26 using an ordinary build and also a -m32 build. 2018-01-15 Tom Tromey <tom@tromey.com> * gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to compute sp_reg.
2018-01-15Automatic date update in version.inGDB Administrator
2018-01-14Automatic date update in version.inGDB Administrator
2018-01-13Automatic date update in version.inGDB Administrator
2018-01-12Add testcase for GDB hang fixed by previous commitPedro Alves
This adds a testcase for the previous commit. The regression was related to in-line step overs. The reason we didn't see it on native x86-64/s390 GNU/Linux testing is that native debugging uses displaced stepping by default (because native debugging defaults to "maint set target-non-stop on"), unlike remote debugging. So in order to trigger the bug with native debugging as well, the testcase disables displaced stepping explicitly. Also, instead of using watchpoints to trigger the regression, the testcase uses a breakpoint at address 0, which should be more portable. gdb/testsuite/ChangeLog: 2018-01-12 Pedro Alves <palves@redhat.com> * gdb.base/continue-after-aborted-step-over.c: New. * gdb.base/continue-after-aborted-step-over.exp: New.
2018-01-12Fix GDB hang with remote after error from resumeAndreas Arnez
Since this commit -- Fix PR18360 - internal error when using "interrupt -a" (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=c65d6b55) -- the testsuite shows long delays on s390 with native-gdbserver when executing certain tests, such as watchpoints.exp. These hangs have been discussed before in the context of buildbot problems, see here: https://sourceware.org/ml/gdb-patches/2017-12/msg00413.html The problem can easily be triggered by stopping on a breakpoint, then setting impossible watchpoints, and finally doing "continue". Then, after having set the step-over state (in keep_going_pass_signal in infrun.c), GDB tries to insert breakpoints and watchpoints into the inferior. This fails, and the "continue" command is aborted. But the step-over state is not cleared in this case, which causes future step-over attempts to be skipped since GDB thinks that "we already have an in-line step-over operation ongoing" (see start_step_over in infrun.c). Thus the next "continue" just goes on to wait for events from the remote, which will never occur. The problem can also be reproduced on amd64 with native-gdbserver, using the following change to watchpoints.exp: -- >8 -- --- a/gdb/testsuite/gdb.base/watchpoints.exp +++ b/gdb/testsuite/gdb.base/watchpoints.exp @@ -61,2 +61,3 @@ with_test_prefix "before inferior start" { gdb_test "watch ival3" ".*" "" + gdb_test "watch *(char \[256\] *) main" -- >8 -- To fix the hang, this patch clears the step-over info when insert_breakpoints has failed. Of course, with native-gdbserver the watchpoints.exp test case still causes many FAILs on s390, because gdbserver does not support watchpoints for that target. This is a separate issue. gdb/ChangeLog: 2018-01-12 Andreas Arnez <arnez@linux.vnet.ibm.com> * infrun.c (keep_going_pass_signal): Clear step-over info when insert_breakpoints fails.
2018-01-12Bump GDB version number to 8.0.91.DATE-git.Joel Brobecker
gdb/ChangeLog: * version.in: Set GDB version number to 8.0.91.DATE-git. * PROBLEMS: Likewise.
2018-01-12Document the GDB 8.0.91 release in gdb/ChangeLogJoel Brobecker
gdb/ChangeLog: GDB 8.0.91 released.
2018-01-12Set GDB version number to 8.0.91.Joel Brobecker
gdb/ChangeLog: * version.in: Set GDB version number to 8.0.91. * PROBLEMS: Likewise.
2018-01-12gdb/NEWS: Rename "Changes since 8.0" into "Changes in 8.1".Joel Brobecker
gdb/ChangeLog: * NEWS: Rename "Changes since 8.0" into "Changes in 8.1".
2018-01-12Automatic date update in version.inGDB Administrator
2018-01-11gdb.base/breakpoint-in-ro-region.exp regression on sss targets (PR gdb/22583)Pedro Alves
As Maciej reported at <https://sourceware.org/ml/gdb-patches/2017-12/msg00212.html>, this commit: commit d930703d68ae160ddfe8ebe5fdcf416fb6090e1e Date: Thu Nov 16 18:44:43 2017 +0000 Subject: Don't ever Quit out of resume caused regressions on software single-set targets, specifically: FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: single-step breakpoint is not left behind FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: step in ro region (cannot insert hw break) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: single-step breakpoint is not left behind FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: single-step breakpoint is not left behind and indeed detailed logs indicate a breakpoint is left lingering, e.g.: (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break) maint info breakpoints 0 Num Type Disp Enb Address What 0 sw single-step keep y 0x00400774 in main at [...]/gdb/testsuite/gdb.base/breakpoint-in-ro-region.c:24 inf 1 thread 1 stop only in thread 1 (gdb) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind vs: (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break) maint info breakpoints 0 No breakpoint or watchpoint matching '0'. (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind as at commit d930703d68ae^. Before commit d930703d68ae, we had a cleanup installed in 'resume' that would delete single-step breakpoints on error: /* Resuming. */ /* Things to clean up if we QUIT out of resume (). */ static void resume_cleanups (void *ignore) { if (!ptid_equal (inferior_ptid, null_ptid)) delete_single_step_breakpoints (inferior_thread ()); normal_stop (); } That whole function was removed by d930703d68ae mainly to eliminate the normal_stop call: ~~~~ Note that the exception called from within resume ends up calling normal_stop via resume_cleanups. That's very borked though, because normal_stop is going to re-handle whatever was the last reported event, possibly even re-running a hook stop... ~~~~ But as the regression shows, removing resume_cleanups completely went a bit too far, as the delete_single_step_breakpoints call is still necessary. So fix the regression by reinstating the delete_single_step_breakpoints call on error. However, since we're trying to eliminate cleanups, restore it in a different form (using TRY/CATCH). Tested on x86-64 GNU/Linux both top of master and on top of a series that implements software single-step on x86. gdb/ChangeLog: 2018-01-11 Pedro Alves <palves@redhat.com> PR gdb/22583 * infrun.c (resume): Rename to ... (resume_1): ... this. (resume): Reimplement as wrapper around resume_1.
2018-01-11Fix backwards compatibility with old GDBservers (PR remote/22597)Pedro Alves
At <https://sourceware.org/ml/gdb-patches/2017-12/msg00285.html>, Maciej reported that commit: commit 5cd63fda035d4ba949e6478406162c4673b3c9ef Date: Wed Oct 4 18:21:10 2017 +0100 Subject: Fix "Remote 'g' packet reply is too long" problems with multiple inferiors made GDB stop working with older stubs. Any attempt to continue execution after the initial connection fails with: [...] Process .../gdb/testsuite/outputs/gdb.base/advance/advance created; pid = 2670 Listening on port 2346 target remote [...]:2346 Remote debugging using [...]:2346 Reading symbols from .../lib64/ld.so.1...done. [Switching to Thread <main>] (gdb) continue Cannot execute this command without a live selected thread. (gdb) The problem is: (gdb) c Cannot execute this command without a live selected thread. (gdb) info threads Id Target Id Frame 1 Thread 14917 0x00007f341cd98ed0 in _start () from /lib64/ld-linux-x86-64.so.2 The current thread <Thread ID 2> has terminated. See `help thread'. ^^^^^^^^^^^ (gdb) Note, thread _2_. There's really only one thread in the inferior (it's still at the entry point), but still GDB added a bogus second thread. The reason GDB started adding a second thread after 5cd63fda035d is this hunk: + if (event->ptid == null_ptid) + { + const char *thr = strstr (p1 + 1, ";thread:"); + if (thr != NULL) + event->ptid = read_ptid (thr + strlen (";thread:"), + NULL); + else + event->ptid = magic_null_ptid; + } Note the else branch that falls back to magic_null_ptid. We reach that when we process the initial stop reply sent back in response to the the "?" (status) packet early in the connection setup: Sending packet: $?#3f...Ack Packet received: T0506:0000000000000000;07:40a510f4fd7f0000;10:d0fe1201577f0000; And note that that response does not include a ";thread:XXX" part. This stop reply is processed after listing threads with qfThreadInfo / qsThreadInfo : Sending packet: $qfThreadInfo#bb...Ack Packet received: m3915 Sending packet: $qsThreadInfo#c8...Ack Packet received: l meaning, when we process that stop reply, we treat the event as coming from a thread with ptid == magic_null_ptid, which is not yet in the thread list, so we add it then: (top-gdb) p ptid $1 = {m_pid = 42000, m_lwp = -1, m_tid = 1} (top-gdb) bt #0 0x0000000000840a8c in add_thread_silent(ptid_t) (ptid=...) at src/gdb/thread.c:269 #1 0x00000000007ad61d in remote_add_thread(ptid_t, int, int) (ptid=..., running=0, executing=0) at src/gdb/remote.c:1838 #2 0x00000000007ad8de in remote_notice_new_inferior(ptid_t, int) (currthread=..., executing=0) at src/gdb/remote.c:1921 #3 0x00000000007b758b in process_stop_reply(stop_reply*, target_waitstatus*) (stop_reply=0x1158860, status=0x7fffffffcc00) at src/gdb/remote.c:7217 #4 0x00000000007b7a38 in remote_wait_as(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/remote.c:7380 #5 0x00000000007b7cd1 in remote_wait(target_ops*, ptid_t, target_waitstatus*, int) (ops=0x102fac0 <remote_ops>, ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/remote.c:7446 #6 0x000000000081587b in delegate_wait(target_ops*, ptid_t, target_waitstatus*, int) (self=0x102fac0 <remote_ops>, arg1=..., arg2=0x7fffffffcc00, arg3=0) at src/gdb/target-delegates.c:138 #7 0x0000000000827d77 in target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/target.c:2179 #8 0x0000000000715fda in do_target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/infrun.c:3589 #9 0x0000000000716351 in wait_for_inferior() () at src/gdb/infrun.c:3707 #10 0x0000000000715435 in start_remote(int) (from_tty=1) at src/gdb/infrun.c:3212 things go downhill from this. We don't see the problem with current master gdbserver, because that version always sends the ";thread:" part in the initial stop reply: Sending packet: $?#3f...Packet received: T0506:0000000000000000;07:a0d4ffffff7f0000;10:d05eddf7ff7f0000;thread:p3cea.3cea;core:3; Years ago I had added a "--disable-packet=" command line option to gdbserver which comes in handy for testing this, since the existing "--disable-packet=Tthread" precisely makes gdbserver not send that ";thread:" part in stop replies. The testcase added by this commit emulates old gdbserver making use of that. I've compared a testrun at 5cd63fda035d^ (before regression) with 'current master+patch', against old gdbserver at f8b73d13b7ca^. I hacked out --once, and "monitor exit" to be able to test. The results are a bit too unstable to tell accurately, but it looked like there were no regressions. Maciej confirmed this worked for him as well. No regressions on master (against master gdbserver). gdb/ChangeLog: 2018-01-11 Pedro Alves <palves@redhat.com> PR remote/22597 * remote.c (remote_parse_stop_reply): Default to the last-set general thread instead of to 'magic_null_ptid'. gdb/testsuite/ChangeLog: 2018-01-11 Pedro Alves <palves@redhat.com> PR remote/22597 * gdb.server/stop-reply-no-thread.c: New file. * gdb.server/stop-reply-no-thread.exp: New file.
2018-01-11Automatic date update in version.inGDB Administrator
2018-01-10language_get_symbol_name_matcher -> get_symbol_name_matcherPedro Alves
Rename language_get_symbol_name_matcher -> get_symbol_name_matcher, since the function is no longer a straight "language method". gdb/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> * language.h (language_get_symbol_name_matcher): Rename ... (get_symbol_name_matcher): ... this. * language.c (language_get_symbol_name_matcher): Ditto. * dictionary.c, linespec.c, minsyms.c, psymtab.c, symtab.c: All callers adjusted.
2018-01-10Ada: make verbatim matcher override other language matchers (PR gdb/22670)Pedro Alves
A previous patch fixed verbatim matching in the lookup at the minimal symbol level, but we should also be finding that same symbol through the partial/full symtab search. For example, this is what happens if we use "print" instead of "break": (gdb) p <MixedCaseFunc> $1 = {<text variable, no debug info>} 0x4024dc <MixedCaseFunc> Before the C++ wildmatching series, GDB knows that MixedCaseFunc is a function without parameters, and the expression above means calling it. If you try it before having started the inferior, you'd get the following (expected) error: (gdb) print <MixedCaseFunc> You can't do that without a process to debug. The main idea behind making the name matcher be determined by the symbol's language is so that C++ (etc.) wildmatching in linespecs works even if the current language is not C++, as e.g., when you step through C or assembly code. Ada's verbatim matching syntax however ("<...>") isn't quite the same. It is more a property of the current language than of a particular symbol's language. We want to support this syntax when debugging an Ada program, but it's reason of existence is to find non-Ada symbols. This suggests going back to enabling it depending on current language instead of language of the symbol being matched. I'm not entirely happy with the "current_language" reference (though I think that it's harmless). I think we could try storing the current language in the lookup_name_info object, and then convert a bunch of functions more to pass around lookup_name_info objects instead of "const char *" names. I.e., build the lookup_name_info higher up. I'm not sure about that, I'll have to think more about it. Maybe something different will be better. Meanwhile, this gets us going. I've extended the testcase to also exercise a no-debug-info function, for extra coverage of the minsyms-only paths. gdb/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * dwarf2read.c (gdb_index_symbol_name_matcher::gdb_index_symbol_name_matcher): Adjust to use language_get_symbol_name_matcher instead of language_defn::la_get_symbol_name_matcher. * language.c (language_get_symbol_name_matcher): If in Ada mode and the lookup name is a verbatim match, return Ada's matcher. * language.h (language_get_symbol_name_matcher): Adjust comment. (ada_lookup_name_info::verbatim_p):: New method. gdb/testsuite/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * gdb.ada/bp_c_mixed_case.exp: Add intro comment. Test printing C functions too. Test setting breakpoints and printing C functions with no debug info too. * gdb.ada/bp_c_mixed_case/qux.c: New file.
2018-01-10Fix gdb.ada/complete.exp's "complete break ada" test (PR gdb/22670)Pedro Alves
This patch fixes the regression covered by the test added by: commit 344420da6beac1e0b2f7964e7101f8dcdb509b0d Date: Thu Jan 4 03:30:37 2018 -0500 Subject: Add "complete break ada" test to gdb.ada/complete.exp The regression had been introduced by: commit b5ec771e60c1a0863e51eb491c85c674097e9e13 Date: Wed Nov 8 14:22:32 2017 +0000 Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching The gist of it is that linespec completion in Ada mode is generating additional matches that should not appear in the match list (internally generated symbols, or symbols that should be enclosed between "<...>"). These extraneous entries have uppercase characters, such as: break ada__stringsS break ada__strings__R11s [etc] These matches come from minimal symbols. The problem is that Ada minsyms end up with no language set (language_auto), and thus we end up using the generic symbol name matcher for those instead of Ada's. We already had a special case for in compare_symbol_name to handle this, but it was limited to expressions, while the case at hand is completing a linespec. Fix this by applying the special case to linespec completion as well. I.e., remove the EXPRESSION check from compare_symbol_name. That alone turns out to not be sufficient still -- GDB would still show a couple entries that shouldn't be there: ~~ break ada__exceptions__exception_data__append_info_exception_name__2Xn break ada__exceptions__exception_data__exception_name_length__2Xn ~~ The reason is that these minimal symbols end up with their language set to language_cplus / C++, because those encoded names manage to demangle successfully as C++ symbols (using an old C++ mangling scheme): $ echo ada__exceptions__exception_data__append_info_exception_name__2Xn | c++filt Xn::ada__exceptions__exception_data__append_info_exception_name(void) It's unfortunate that Ada's encoding scheme doesn't start with some unique prefix like "_Z" in the C++ Itanium ABI mangling scheme. For now, paper over that by treating C++ minsyms as Ada minsyms. gdb/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * ada-lang.c (ada_collect_symbol_completion_matches): If the minsym's language is language_auto or language_cplus, pass down language_ada instead. * symtab.c (compare_symbol_name): Don't frob symbol language here. gdb/testsuite/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * gdb.ada/complete.exp ("complete break ada"): Replace kfail with a fail.
2018-01-10Fix gdb.ada/bp_c_mixed_case.exp (PR gdb/22670)Pedro Alves
The problem here is that we are using the user-provided lookup name literally for name comparisons. I.e., "<MixedCase>" with the "<>"s included. This commit fixes the minsym lookup case. psymbol/symbol lookup will be fixed in a follow up. In the minsym case, we're using using the user-provided lookup name literally for linkage name comparisons. That obviously can't work since the "<>" are not really part of the linkage name. The original idea was that we'd use the symbol's language to select the right symbol name matching algorithm, but that doesn't work for Ada because it's not really possible to unambiguously tell from the linkage name alone whether we're dealing with Ada symbols, so Ada minsyms end up with no language set, or sometimes C++ set. So fix this by treating Ada mode specially when determining the linkage name to match against. gdb/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * minsyms.c (linkage_name_str): New function. (iterate_over_minimal_symbols): Use it. gdb/testsuite/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * gdb.ada/bp_c_mixed_case.exp: Remove setup_kfail calls.
2018-01-10Automatic date update in version.inGDB Administrator
2018-01-09Automatic date update in version.inGDB Administrator
2018-01-08hurd: Add enough auxv support for AT_ENTRY for PIE binariesSamuel Thibault
Add PIE support for hurd, by faking an AT_ENTRY auxv entry. That value is expected to be read by svr4_exec_displacement, which will propagate the executable displacement. gdb/ChangeLog: * gdb/gnu-nat.c: Include <elf.h> and <link.h>. (gnu_xfer_auxv): New function. (gnu_xfer_partial): Call gnu_xfer_auxv when `object' is TARGET_OBJECT_AUXV.
2018-01-08Fix GDBserver build failure when $development is falseYao Qi
When we set bfd/development.sh:$development to false, GDBserver failed to build, selftest.o: In function `selftests::run_tests(char const*)': binutils-gdb/gdb/gdbserver/../common/selftest.c:97:undefined reference to `selftests::reset()' collect2: error: ld returned 1 exit status selftest.o shouldn't be compiled and linked when $development is false. With this patch, in release mode, GDBserver doesn't nothing with option --selftest, $ ./gdbserver --selftest=foo Selftests are not available in a non-development build. $ ./gdbserver --selftest Selftests are not available in a non-development build. gdb/gdbserver: 2018-01-08 Yao Qi <yao.qi@linaro.org> Simon Marchi <simon.marchi@ericsson.com> * Makefile.in (OBS): Remove selftest.o. * configure.ac: Set srv_selftest_objs if $development is true. (GDBSERVER_DEPFILES): Append $srv_selftest_objs. * configure: Re-generated. * server.c (captured_main): Wrap variable selftest_filter with GDB_SELF_TEST. gdb/testsuite: 2018-01-08 Simon Marchi <simon.marchi@ericsson.com> * gdb.server/unittest.exp: Match the output in non-development mode.
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-04 23:11:53 +0000