aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-02-19Automatic date update in version.inGDB Administrator1-1/+1
2018-02-18Automatic date update in version.inGDB Administrator1-1/+1
2018-02-17Automatic date update in version.inGDB Administrator1-1/+1
2018-02-16Automatic date update in version.inGDB Administrator1-1/+1
2018-02-15Reset inferior::control on inferior exitYao Qi2-0/+7
When we kill an inferior, the inferior is not deleted. What is more, it is reused when the new process is created, so we need to reset inferior's state when it exits. gdb: 2018-02-15 Yao Qi <yao.qi@linaro.org> PR gdb/22849 * inferior.c (exit_inferior_1): Reset inf->control.
2018-02-15Automatic date update in version.inGDB Administrator1-1/+1
2018-02-14Automatic date update in version.inGDB Administrator1-1/+1
2018-02-13Automatic date update in version.inGDB Administrator1-1/+1
2018-02-12Automatic date update in version.inGDB Administrator1-1/+1
2018-02-11Automatic date update in version.inGDB Administrator1-1/+1
2018-02-10Automatic date update in version.inGDB Administrator1-1/+1
2018-02-09gdb/NEWS: Clarify the news entry for "rbreak" in GDB 8.1Joel Brobecker2-3/+9
gdb/ChangeLog: PR gdb/22824: * NEWS <Changes in GDB 8.1>: Clarify that "rbreak" is a new Python function, rather than a new command.
2018-02-09Automatic date update in version.inGDB Administrator1-1/+1
2018-02-08Automatic date update in version.inGDB Administrator1-1/+1
2018-02-07Automatic date update in version.inGDB Administrator1-1/+1
2018-02-06Automatic date update in version.inGDB Administrator1-1/+1
2018-02-05Automatic date update in version.inGDB Administrator1-1/+1
2018-02-04Automatic date update in version.inGDB Administrator1-1/+1
2018-02-03Automatic date update in version.inGDB Administrator1-1/+1
2018-02-02Automatic date update in version.inGDB Administrator1-1/+1
2018-02-01Automatic date update in version.inGDB Administrator1-1/+1
2018-01-31Bump GDB version number to 8.1.0.DATE-git.Joel Brobecker3-2/+7
gdb/ChangeLog: * version.in: Set GDB version number to 8.1.0.DATE-git. * PROBLEMS: Likewise.
2018-01-31Document the GDB 8.1 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 8.1 released.
2018-01-31Set GDB version number to 8.1.gdb-8.1-releaseJoel Brobecker3-2/+7
gdb/ChangeLog: * version.in: Set GDB version number to 8.1. * PROBLEMS: Likewise.
2018-01-31Automatic date update in version.inGDB Administrator1-1/+1
2018-01-30Automatic date update in version.inGDB Administrator1-1/+1
2018-01-29Automatic date update in version.inGDB Administrator1-1/+1
2018-01-28Automatic date update in version.inGDB Administrator1-1/+1
2018-01-27Avoid compilation errors in MinGW native builds of GDBEli Zaretskii2-0/+28
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 Zaretskii2-5/+17
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 Administrator1-1/+1
2018-01-26Automatic date update in version.inGDB Administrator1-1/+1
2018-01-25Automatic date update in version.inGDB Administrator1-1/+1
2018-01-24Fix GCC PR83906 - [8 Regression] Random FAIL: ↵Pedro Alves3-2/+72
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 Administrator1-1/+1
2018-01-23Automatic date update in version.inGDB Administrator1-1/+1
2018-01-22MAINTAINERS: Update my company e-mail addressMaciej W. Rozycki6-3/+15
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 Alves4-5/+38
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 Administrator1-1/+1
2018-01-21Automatic date update in version.inGDB Administrator1-1/+1
2018-01-20Automatic date update in version.inGDB Administrator1-1/+1
2018-01-19Automatic date update in version.inGDB Administrator1-1/+1
2018-01-18Automatic date update in version.inGDB Administrator1-1/+1
2018-01-17Fix warning on gdb/compile/compile.c (C++-ify "triplet_rx")Sergio Durigan Junior2-5/+11
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 Abusalimov6-6/+26
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 Qi2-0/+18
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 Qi2-2/+10
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 Administrator1-1/+1
2018-01-16Automatic date update in version.inGDB Administrator1-1/+1
2018-01-15Fix scm-ports.exp regressionTom Tromey2-1/+6
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.
generated by cgit v1.1 at 2025-09-20 13:10:20 +0000