aboutsummaryrefslogtreecommitdiff
path: root/gdb/ChangeLog
AgeCommit message (Collapse)AuthorFilesLines
2017-01-21Bump GDB version number to 7.12.1.DATE-git.Joel Brobecker1-0/+5
gdb/ChangeLog: * version.in: Set GDB version number to 7.12.1.DATE-git. * PROBLEMS: Likewise.
2017-01-21Document the GDB 7.12.1 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 7.12.1 released.
2017-01-21Set GDB version number to 7.12.1.gdb-7.12.1-releaseJoel Brobecker1-0/+5
gdb/ChangeLog: * version.in: Set GDB version number to 7.12.1. * PROBLEMS: Likewise.
2017-01-20Fix python-interactive with Python 3.6Simon Marchi1-0/+8
New in v2: - Define PyMem_RawMalloc as PyMem_Malloc for Python < 3.4 and use PyMem_RawMalloc in the code. Since Python 3.4, the callback installed in PyOS_ReadlineFunctionPointer should return a value allocated with PyMem_RawMalloc instead of PyMem_Malloc. The reason is that PyMem_Malloc must be called with the Python Global Interpreter Lock (GIL) held, which is not the case in the context where this function is called. PyMem_RawMalloc was introduced for cases like this. In Python 3.6, it looks like they added an assert to verify that PyMem_Malloc was not called without the GIL. The consequence is that typing anything in the python-interactive mode of gdb crashes the process. The same behavior was observed with the official package on Arch Linux as well as with a manual Python build on Ubuntu 14.04. This is what is shown with a debug build of Python 3.6 (the error with a non-debug build is far less clear): (gdb) pi >>> print(1) Fatal Python error: Python memory allocator called without holding the GIL Current thread 0x00007f1459af8780 (most recent call first): [1] 21326 abort ./gdb and the backtrace: #0 0x00007ffff618bc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff618f028 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff6b104d6 in Py_FatalError (msg=msg@entry=0x7ffff6ba15b8 "Python memory allocator called without holding the GIL") at Python/pylifecycle.c:1457 #3 0x00007ffff6a37a68 in _PyMem_DebugCheckGIL () at Objects/obmalloc.c:1972 #4 0x00007ffff6a3804e in _PyMem_DebugFree (ctx=0x7ffff6e65290 <_PyMem_Debug+48>, ptr=0x24f8830) at Objects/obmalloc.c:1994 #5 0x00007ffff6a38e1d in PyMem_Free (ptr=<optimized out>) at Objects/obmalloc.c:442 #6 0x00007ffff6b866c6 in _PyFaulthandler_Fini () at ./Modules/faulthandler.c:1369 #7 0x00007ffff6b104bd in Py_FatalError (msg=msg@entry=0x7ffff6ba15b8 "Python memory allocator called without holding the GIL") at Python/pylifecycle.c:1431 #8 0x00007ffff6a37a68 in _PyMem_DebugCheckGIL () at Objects/obmalloc.c:1972 #9 0x00007ffff6a37aa3 in _PyMem_DebugMalloc (ctx=0x7ffff6e65290 <_PyMem_Debug+48>, nbytes=5) at Objects/obmalloc.c:1980 #10 0x00007ffff6a38d91 in PyMem_Malloc (size=<optimized out>) at Objects/obmalloc.c:418 #11 0x000000000064dbe2 in gdbpy_readline_wrapper (sys_stdin=0x7ffff6514640 <_IO_2_1_stdin_>, sys_stdout=0x7ffff6514400 <_IO_2_1_stdout_>, prompt=0x7ffff4d4f7d0 ">>> ") at /home/emaisin/src/binutils-gdb/gdb/python/py-gdb-readline.c:75 The documentation is very clear about it [1] and it was also mentioned in the "What's New In Python 3.4" page [2]. [1] https://docs.python.org/3/c-api/veryhigh.html#c.PyOS_ReadlineFunctionPointer [2] https://docs.python.org/3/whatsnew/3.4.html#changes-in-the-c-api gdb/ChangeLog: * python/python-internal.h (PyMem_RawMalloc): Define for Python < 3.4. * python/py-gdb-readline.c (gdbpy_readline_wrapper): Use PyMem_RawMalloc instead of PyMem_Malloc.
2017-01-20Throw SJ/LJ exception on error in disassemblyYao Qi1-0/+17
PR 20939 reports that GDB will abort on memory error in disassembly, (gdb) disassemble 0x0,+4 Dump of assembler code from 0x0 to 0x4: terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR' 0x0000000000000000: Aborted (gdb) guile (print (arch-disassemble arch 0 #:size 4))^M terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'^M ERROR: Process no longer exists This patch fixes PR 20939 by catching C++ exception, throwing SJ/LJ exception in the call back passed to C functions of opcodes, and catching SJ/LJ exception in gdb, and throw exception. The patch follows this commit 89525768cd086a0798a504c81fdf7ebcd4c904e1 Propagate GDB/C++ exceptions across readline using sj/lj-based TRY/CATCH rather than "backport" the fix to this PR I posted for mainline https://sourceware.org/ml/gdb-patches/2017-01/msg00288.html because the fix for mainline includes 1) some changes to opcodes, 2) some refactors in C++. All of them are risky to backport to 7.12 branch. With this patch applied to 7.12 branch, GDB doesn't abort on memory error in disassembly. It fixes some test failures in gdb.guile/scm-disasm.exp and gdb.python/py-arch.exp on aarch64-linux. -ERROR: Process no longer exists -UNRESOLVED: gdb.guile/scm-disasm.exp: test bad memory access +PASS: gdb.guile/scm-disasm.exp: test bad memory access -ERROR: Process no longer exists -UNRESOLVED: gdb.python/py-arch.exp: test bad memory access +PASS: gdb.python/py-arch.exp: test bad memory access I'll add the scm-disasm test to master later. gdb: 2017-01-20 Yao Qi <yao.qi@linaro.org> PR gdb/20939 * disasm.c (dis_asm_memory_error): Catch the error and rethrow it as a SJ/LJ exception. Add GDB_NOEXCEPT. (disasm_print_insn_noexcept): New function. (disasm_print_insn): New function. (gdb_pretty_print_insn): Call disasm_print_insn instead of gdbarch_print_insn. (gdb_print_insn): Likewise. (gdb_buffered_insn_length): Likewise. * event-top.c (GDB_NOEXCEPT): Move it to ... * exceptions.h (GDB_NOEXCEPT): ... here. * guile/scm-disasm.c (gdbscm_disasm_memory_error): Remove. (gdbscm_print_insn_from_port): Don't set di.memory_errro_func. Call disasm_print_insn rather than gdbarch_print_insn.
2017-01-12Fix some error-handling bugs in python frame filtersTom Tromey1-0/+5
While writing a Python frame filter, I found a few bugs in the current frame filter code. In particular: * One spot converts a Python long to a CORE_ADDR using PyLong_AsLong. However, this can fail on overflow. I changed this to use get_addr_from_python. * Another spot is doing the same but with PyLong_AsUnsignedLongLong; I changed this as well just for consistency. * Converting line numbers can print "-1" if conversion from long fails. This isn't fatal but just a bit ugly. I've included a test case for the first issue. The line number one didn't seem important enough to bother with. 2016-11-08 Tom Tromey <tom@tromey.com> * python/py-framefilter.c (py_print_frame): Use get_addr_from_python. Check for errors when getting line number. 2016-11-08 Tom Tromey <tom@tromey.com> * gdb.python/py-framefilter.py (ElidingFrameDecorator.address): New method.
2016-12-20gdb: Fix C and C++03 buildsPedro Alves1-0/+8
The readline/sjlj-exceptions fix added an unconditional use of noexcept, but that's only valid C++11, and 7.12 must build with C and C++03 too. Fix this by adding a GDB_EXCEPT macro that compiles away to nothing in C, and to throw() in C++03, which I've confirmed fixes the original issue just the same as noexcept, with GCC 7 + -std=gnu+03 + sjlj-exceptions. gdb/ChangeLog: 2016-12-20 Pedro Alves <palves@redhat.com> PR gdb/20977 * event-top.c (GDB_NOEXCEPT): Define. (gdb_rl_callback_read_char_wrapper_noexcept): Use GDB_NOEXCEPT instead of noexcept and use (void) instead of (). (gdb_rl_callback_handler): Use GDB_NOEXCEPT instead of noexcept.
2016-12-20Fix longjmp across readline w/ --enable-sjlj-exceptions toolchainsPedro Alves1-0/+9
Nowadays, GDB propagates C++ exceptions across readline using setjmp/longjmp 89525768cd08 ("Propagate GDB/C++ exceptions across readline using sj/lj-based TRY/CATCH") because DWARF-based unwinding can't cross C functions compiled without -fexceptions (see details from the commit above). Unfortunately, toolchains that use SjLj-based C++ exceptions got broken with that fix, because _Unwind_SjLj_Unregister, which is put at the exit of a function, is not executed due to the longjmp added by that commit. (gdb) [New Thread 2936.0xb80] kill Thread 1 received signal SIGSEGV, Segmentation fault. 0x03ff662b in ?? () top?bt 15 #0 0x03ff662b in ?? () #1 0x00526b92 in stdin_event_handler (error=0, client_data=0x172ed8) at ../../binutils-gdb/gdb/event-top.c:555 #2 0x00525a94 in handle_file_event (ready_mask=<optimized out>, file_ptr=0x3ff5cb8) at ../../binutils-gdb/gdb/event-loop.c:733 #3 gdb_wait_for_event (block=block@entry=1) at ../../binutils-gdb/gdb/event-loop.c:884 #4 0x00525bfb in gdb_do_one_event () at ../../binutils-gdb/gdb/event-loop.c:347 #5 0x00525ce5 in start_event_loop () at ../../binutils-gdb/gdb/event-loop.c:371 #6 0x0051fada in captured_command_loop (data=0x0) at ../../binutils-gdb/gdb/main.c:324 #7 0x0051cf5d in catch_errors ( func=func@entry=0x51fab0 <captured_command_loop(void*)>, func_args=func_args@entry=0x0, errstring=errstring@entry=0x7922bf <VEC_interp_factory_p_quick_push(VEC_inte rp_factory_p*, interp_factory*, char const*, unsigned int)::__PRETTY_FUNCTION__+351> "", mask=mask@entry=RETURN_MASK_ALL) at ../../binutils-gdb/gdb/exceptions.c:236 #8 0x00520f0c in captured_main (data=0x328feb4) at ../../binutils-gdb/gdb/main.c:1149 #9 gdb_main (args=args@entry=0x328feb4) at ../../binutils-gdb/gdb/main.c:1159 #10 0x0071e400 in main (argc=1, argv=0x171220) at ../../binutils-gdb/gdb/gdb.c:32 Fix this by making the functions involved in setjmp/longjmp as noexcept, so that the compiler knows it doesn't need to emit the _Unwind_SjLj_Register / _Unwind_SjLj_Unregister calls for C++ exceptions. Tested on x86_64 Fedora 23 with: - GCC 5.3.1 w/ DWARF-based exceptions. - GCC 7 built with --enable-sjlj-exceptions. gdb/ChangeLog: 2016-12-20 Pedro Alves <palves@redhat.com> Yao Qi <yao.qi@linaro.org> PR gdb/20977 * event-top.c (gdb_rl_callback_read_char_wrapper_noexcept): New noexcept function, factored out from ... (gdb_rl_callback_read_char_wrapper): ... this. (gdb_rl_callback_handler): Mark noexcept.
2016-12-12Remove assert on exec_bfd in cris_delayed_get_disassemblerYao Qi1-0/+6
cris_delayed_get_disassembler has an assert that exec_bfd can't be NULL, but this assert can be triggered like this, (gdb) set architecture cris The target architecture is assumed to be cris (gdb) disassemble 0x0,+4 Dump of assembler code from 0x0 to 0x4: 0x00000000: ../../binutils-gdb/gdb/cris-tdep.c:3798: internal-error: int cris_delayed_get_disassembler(bfd_vma, disassemble_info*): Assertion `exec_bfd != NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. however, cris_get_disassembler does have code to handle the case that bfd is NULL, /* If there's no bfd in sight, we return what is valid as input in all contexts if fed back to the assembler: disassembly *with* register prefix. Unfortunately this will be totally wrong for v32. */ if (abfd == NULL) return print_insn_cris_with_register_prefix; This patch is to remove this assert. gdb: 2016-12-12 Yao Qi <yao.qi@linaro.org> PR tdep/20955 * cris-tdep.c (cris_delayed_get_disassembler): Remove the assert.
2016-12-09Create tdep->rx_psw_type and tdep->rx_fpsw_type lazilyYao Qi1-0/+9
I build GDB with all targets enabled, and "set architecture rx", GDB crashes, (gdb) set architecture rx Program received signal SIGSEGV, Segmentation fault. append_flags_type_flag (type=0x20cc360, bitpos=bitpos@entry=0, name=name@entry=0xd27529 "C") at ../../binutils-gdb/gdb/gdbtypes.c:4926 4926 name); (gdb) bt 10 #0 append_flags_type_flag (type=0x20cc360, bitpos=bitpos@entry=0, name=name@entry=0xd27529 "C") at ../../binutils-gdb/gdb/gdbtypes.c:4926 #1 0x00000000004ce725 in rx_gdbarch_init (info=..., arches=<optimized out>) at ../../binutils-gdb/gdb/rx-tdep.c:1051 #2 0x00000000006b05a4 in gdbarch_find_by_info (info=...) at ../../binutils-gdb/gdb/gdbarch.c:5269 #3 0x000000000060eee4 in gdbarch_update_p (info=...) at ../../binutils-gdb/gdb/arch-utils.c:557 #4 0x000000000060f8a8 in set_architecture (ignore_args=<optimized out>, from_tty=1, c=<optimized out>) at ../../binutils-gdb/gdb/arch-utils.c:531 #5 0x0000000000593d0b in do_set_command (arg=<optimized out>, arg@entry=0x20bee81 "rx ", from_tty=from_tty@entry=1, c=c@entry=0x20b1540) at ../../binutils-gdb/gdb/cli/cli-setshow.c:455 #6 0x00000000007665c3 in execute_command (p=<optimized out>, p@entry=0x20bee70 "set architecture rx ", from_tty=1) at ../../binutils-gdb/gdb/top.c:666 #7 0x00000000006935f4 in command_handler (command=0x20bee70 "set architecture rx ") at ../../binutils-gdb/gdb/event-top.c:577 #8 0x00000000006938d8 in command_line_handler (rl=<optimized out>) at ../../binutils-gdb/gdb/event-top.c:767 #9 0x0000000000692c2c in gdb_rl_callback_handler (rl=0x20be7f0 "") at ../../binutils-gdb/gdb/event-top.c:200 The cause is that we want to access some builtin types in gdbarch init, but it is not initialized yet. I fix it by creating the type when it is to be used. We've already done this in sparc, sparc64 and m68k. gdb: 2016-12-09 Yao Qi <yao.qi@linaro.org> PR tdep/20954 * rx-tdep.c (rx_psw_type): New function. (rx_fpsw_type): New function. (rx_register_type): Call rx_psw_type and rx_fpsw_type. (rx_gdbarch_init): Move code to rx_psw_type and rx_fpsw_type.
2016-12-09Create tdep->rl78_psw_type lazilyYao Qi1-0/+7
I build GDB for all targets enabled. When I "set architecture rl78", GDB crashes, (gdb) set architecture rl78 Program received signal SIGSEGV, Segmentation fault. append_flags_type_flag (type=0x20cc0e0, bitpos=bitpos@entry=0, name=name@entry=0x11dba3f "CY") at ../../binutils-gdb/gdb/gdbtypes.c:4926 4926 name); (gdb) bt 10 #0 append_flags_type_flag (type=0x20cc0e0, bitpos=bitpos@entry=0, name=name@entry=0x11dba3f "CY") at ../../binutils-gdb/gdb/gdbtypes.c:4926 #1 0x00000000004aaca8 in rl78_gdbarch_init (info=..., arches=<optimized out>) at ../../binutils-gdb/gdb/rl78-tdep.c:1410 #2 0x00000000006b05a4 in gdbarch_find_by_info (info=...) at ../../binutils-gdb/gdb/gdbarch.c:5269 #3 0x000000000060eee4 in gdbarch_update_p (info=...) at ../../binutils-gdb/gdb/arch-utils.c:557 #4 0x000000000060f8a8 in set_architecture (ignore_args=<optimized out>, from_tty=1, c=<optimized out>) at ../../binutils-gdb/gdb/arch-utils.c:531 #5 0x0000000000593d0b in do_set_command (arg=<optimized out>, arg@entry=0x20be851 "rl78", from_tty=from_tty@entry=1, c=c@entry=0x20b1540) at ../../binutils-gdb/gdb/cli/cli-setshow.c:455 #6 0x00000000007665c3 in execute_command (p=<optimized out>, p@entry=0x20be840 "set architecture rl78", from_tty=1) at ../../binutils-gdb/gdb/top.c:666 #7 0x00000000006935f4 in command_handler (command=0x20be840 "set architecture rl78") at ../../binutils-gdb/gdb/event-top.c:577 #8 0x00000000006938d8 in command_line_handler (rl=<optimized out>) at ../../binutils-gdb/gdb/event-top.c:767 #9 0x0000000000692c2c in gdb_rl_callback_handler (rl=0x20be890 "") at ../../binutils-gdb/gdb/event-top.c:200 The cause is that we want to access some builtin types in gdbarch init, but it is not initialized yet. I fix it by creating the type when it is to be used. We've already done this in sparc, sparc64 and m68k. gdb: 2016-12-09 Yao Qi <yao.qi@linaro.org> PR tdep/20953 * rl78-tdep.c (rl78_psw_type): New function. (rl78_register_type): Call rl78_psw_type. (rl78_gdbarch_init): Move code to rl78_psw_type.
2016-10-25Added forgotten gdb/ChangeLog entry.Rainer Orth1-0/+35
2016-10-24PR gdb/20653 - small cleanup in string_to_explicit_locationTom Tromey1-0/+5
This bug points out that string_to_explicit_location compares a char* against '\0'; whereas comparing against NULL is more normal. 2016-10-24 Tom Tromey <tom@tromey.com> PR breakpoints/20653: * location.c (string_to_explicit_location): Use NULL, not '\0'.
2016-10-14Include strings.h where availableEli Zaretskii1-0/+5
gdb/ChangeLog 2016-10-14 Eli Zaretskii <eliz@gnu.org> * common/common-defs.h [HAVE_STRINGS_H]: Include strings.h if available, to get prototypes of 'strcasecmp' and 'strncasecmp'. (cherry picked from commit 8ffc1bb12a22e548835c9291871ad0eb68b7f6f0)
2016-10-12[AArch64] Track FP registers in prologue analyzerYao Qi1-0/+10
We don't track FP registers in aarch64 prologue analyzer, so this causes an internal error when FP registers are saved by "stp" instruction in prologue (stp d8, d9, [sp,#128]), tbreak _Unwind_RaiseException^M aarch64-tdep.c:335: internal-error: CORE_ADDR aarch64_analyze_prologue(gdbarch*, CORE_ADDR, CORE_ADDR, aarch64_prologue_cache*): Assertion `inst.operands[0].type == AARCH64_OPND_Rt' failed.^M A problem internal to GDB has been detected, This patch teaches GDB to track FP registers (D registers) in prologue analyzer. gdb: 2016-10-12 Yao Qi <yao.qi@linaro.org> PR tdep/20682 * aarch64-tdep.c: Replace 32 with AARCH64_D_REGISTER_COUNT. (aarch64_analyze_prologue): Extend array 'regs' for D registers. Assert that operand 0 and 1 can be X or D registers. Update register number for D registers. Update registers in frame cache. * aarch64-tdep.h (AARCH64_D_REGISTER_COUNT): New macro.
2016-10-07Bump GDB version number to 7.12.0.DATE-git.Joel Brobecker1-0/+4
gdb/ChangeLog: * version.in: Set GDB version number to 7.12.0.DATE-git.
2016-10-07Document the GDB 7.12 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 7.12 released.
2016-10-07Set GDB version number to 7.12.gdb-7.12-releaseJoel Brobecker1-0/+4
gdb/ChangeLog: * version.in: Set GDB version number to 7.12.
2016-10-06frame.h: Forward-declare struct ui_outSimon Marchi1-0/+4
Fixes this failure when building in C mode. I think it's relevant for master as well, since it's a good practice to include (or forward-declare) what you use. In file included from ../../binutils-gdb/gdb/gdbarch.h:38:0, from ../../binutils-gdb/gdb/defs.h:653, from ../../binutils-gdb/gdb/dictionary.c:23: ../../binutils-gdb/gdb/frame.h:710:48: warning: ‘struct ui_out’ declared inside parameter list will not be visible outside of this definition or declaration extern void print_stack_frame_to_uiout (struct ui_out *uiout, gdb/ChangeLog: * frame.h: Forward-declare struct ui_out.
2016-10-06mips-tdep: Make FCRs always 32-bitMaciej W. Rozycki1-0/+5
Fix a regression from commit f8b73d13b7ca ("Target-described register support for MIPS"), <https://sourceware.org/ml/gdb-patches/2007-05/msg00340.html>, <https://sourceware.org/ml/gdb-patches/2007-06/msg00256.html>, which caused Floating Point Control Registers (FCRs) to be shown as 64-bit with 64-bit targets. This came from the legacy register format where all raw registers matched the width of the architecture regardless of their actual size. The correct size was then set in `mips_register_type' for cooked registers presented to the user, which in the case of FCRs meant the cooked size was always forced to 32 bits, reflecting their actual hardware size, even though the raw format carried them in 64-bit quantities on 64-bit targets. The upper 32 bits carried in the raw FCR format have always been don't-cares, not actually retrieved from hardware and never written back. With the introduction of XML register descriptions the layout of previously defined raw registers has been preserved, so as to keep existing register handling code unchanged and make it easier for GDB and `gdbserver' to interact with each other whether neither, either or both parties talking over RSP support XML register descriptions. For the XML-described case however `mips_register_type' is not used in raw to cooked register conversion, so any special cases coded there are not taken into account. Instead a new function, `mips_pseudo_register_type', has been introduced to handle size conversion, however lacking the special case for FCRs for the Linux and the now defunct IRIX target. The correct size has been maintained for embedded targets however, due to the bundling of FCRs with the embedded registers under the `rawnum >= MIPS_EMBED_FP0_REGNUM + 32' condition. Add the missing case to `mips_pseudo_register_type' then, referring to the FCR indices explicitly, and observing that between `MIPS_EMBED_FP0_REGNUM + 32' and `MIPS_FIRST_EMBED_REGNUM' there is an unused register slot whose contents are ignored so with the removal of embedded FCRs from under that condition we don't have to care about it and we can refer to the embedded registers starting from MIPS_FIRST_EMBED_REGNUM instead. Add a test case too so that we have means to check automatically that the correct user-visible size of FCRs is maintained. gdb/ * mips-tdep.c (mips_pseudo_register_type): Make FCRs always 32-bit. gdb/testsuite/ * gdb.arch/mips-fcr.exp: New test. * gdb.arch/mips-fcr.c: Source for the new test. (cherry picked from commit 78b86327b5301231005b08a7c589b2b58e6b4322)
2016-10-06mips-tdep: Rearrange comments in `mips_pseudo_register_type'Maciej W. Rozycki1-0/+5
Rearrange comments throughout `mips_pseudo_register_type', placing them ahead the condtionals they apply to consistently. gdb/ * mips-tdep.c (mips_pseudo_register_type): Rearrange comments throughout. (cherry picked from commit a6912260f813b1493efefd27cbcb6a73d933accc)
2016-10-06stack: fix gdb.dwarf2/dw2-undefined-ret-addr.exp regressionMarkus Metzger1-0/+5
Commit a038fa3e14a4 stack: check frame_unwind_caller_id adds a frame_id check to frame_info and treats a missing frame_id as NOT_AVAILABLE_ERROR. This causes a regression in gdb.dwarf2/dw2-undefined-ret-addr.exp. Treat a missing frame_id as OPTIMIZED_OUT_ERROR instead. See also https://sourceware.org/ml/gdb-patches/2016-07/msg00273.html.
2016-10-06Fix PR11094: JIT breakpoint is not properly recreated on rerunsPedro Alves1-0/+5
Even though this was supposedly in the gdb 7.2 timeframe, the testcase in PR11094 crashes current GDB with a segfault: Program received signal SIGSEGV, Segmentation fault. 0x00000000005ee894 in event_location_to_string (location=0x0) at src/gdb/location.c:412 412 if (EL_STRING (location) == NULL) (top-gdb) bt #0 0x00000000005ee894 in event_location_to_string (location=0x0) at src/gdb/location.c:412 #1 0x000000000057411a in print_breakpoint_location (b=0x18288e0, loc=0x0) at src/gdb/breakpoint.c:6201 #2 0x000000000057483f in print_one_breakpoint_location (b=0x18288e0, loc=0x182cf10, loc_number=0, last_loc=0x7fffffffd258, allflag=1) at src/gdb/breakpoint.c:6473 #3 0x00000000005751e1 in print_one_breakpoint (b=0x18288e0, last_loc=0x7fffffffd258, allflag=1) at src/gdb/breakpoint.c:6707 #4 0x000000000057589c in breakpoint_1 (args=0x0, allflag=1, filter=0x0) at src/gdb/breakpoint.c:6947 #5 0x0000000000575aa8 in maintenance_info_breakpoints (args=0x0, from_tty=0) at src/gdb/breakpoint.c:7026 [...] This is GDB trying to print the location spec of the JIT event breakpoint, but that's an internal breakpoint without one. If I add a NULL check, then we see that the JIT breakpoint is now pending (because its location has shlib_disabled set): (gdb) maint info breakpoints Num Type Disp Enb Address What [...] -8 jit events keep y <PENDING> inf 1 [...] But that's incorrect. GDB should have managed to recreate the JIT breakpoint's location for the second run. So the problem is elsewhere. The problem is that if the JIT loads at the same address on the second run, we never recreate the JIT breakpoint, because we hit this early return: static int jit_breakpoint_re_set_internal (struct gdbarch *gdbarch, struct jit_program_space_data *ps_data) { [...] if (ps_data->cached_code_address == addr) return 0; [...] delete_breakpoint (ps_data->jit_breakpoint); [...] ps_data->jit_breakpoint = create_jit_event_breakpoint (gdbarch, addr); Fix this by deleting the breakpoint and discarding the cached code address when the objfile where the previous JIT breakpoint was found is deleted/unloaded in the first place. The test that was originally added for PR11094 doesn't trip on this because: #1 - It doesn't test the case of the JIT descriptor's address _not_ changing between reruns. #2 - And then it doesn't do "maint info breakpoints", or really anything with the JIT at all. #3 - and even then, to trigger the problem the JIT descriptor needs to be in a separate library, while the current test puts it in the main program. The patch extends the test to cover all combinations of these scenarios. gdb/ChangeLog: 2016-10-06 Pedro Alves <palves@redhat.com> * jit.c (free_objfile_data): Delete the JIT breakpoint and clear the cached code address. gdb/testsuite/ChangeLog: 2016-10-06 Pedro Alves <palves@redhat.com> * gdb.base/jit-simple-dl.c: New file. * gdb.base/jit-simple-jit.c: New file, factored out from ... * gdb.base/jit-simple.c: ... this. * gdb.base/jit-simple.exp (jit_run): Delete. (build_jit): New proc. (jit_test_reread): Recompile either the main program or the shared library, depending on what is being tested. Skip changing address if caller wants to. Compare before/after addresses. If testing standalone, explicitly load the binary. Test "maint info breakpoints". (top level): Add "standalone vs shared lib" and "change address" vs "same address" axes.
2016-10-03Introduce cleanup to restore current_uioutSimon Marchi1-0/+13
Make a globally available cleanup from a pre-existing one in infrun.c. This is used in a following patch. gdb/ChangeLog: * infrun.c (restore_current_uiout_cleanup): Move to ui-out.c. (print_stop_event): Use make_cleanup_restore_current_uiout. * python/python.c (execute_gdb_command): Likewise. * ui-out.c (restore_current_uiout_cleanup): Move from infrun.c. (make_cleanup_restore_current_uiout): New function definition. * ui-out.h (make_cleanup_restore_current_uiout): New function declaration. * utils.c (do_restore_ui_out): Remove. (make_cleanup_restore_ui_out): Remove. * utils.h (make_cleanup_restore_ui_out): Remove.
2016-10-03Emit inferior, thread and frame selection events to all UIsAntoine Tremblay1-0/+58
With this patch, when an inferior, thread or frame is explicitly selected by the user, notifications will appear on all CLI and MI UIs. When a GDB console is integrated in a front-end, this allows the front-end to follow a selection made by the user ont he CLI, and it informs the user about selection changes made behind the scenes by the front-end. This patch addresses PR gdb/20487. In order to communicate frame changes to the front-end, this patch adds a new field to the =thread-selected event for the selected frame. The idea is that since inferior/thread/frame can be seen as a composition, it makes sense to send them together in the same event. The vision would be to eventually send the inferior information as well, if we find that it's needed, although the "=thread-selected" event would be ill-named for that job. Front-ends need to handle this new field if they want to follow the frame selection changes that originate from the console. The format of the frame attribute is the same as what is found in the *stopped events. Here's a detailed example for each command and the events they generate: thread ------ 1. CLI command: thread 1.3 MI event: =thread-selected,id="3",frame={...} 2. MI command: -thread-select 3 CLI event: [Switching to thread 1.3 ...] 3. MI command (CLI-in-MI): thread 1.3 MI event/reply: &"thread 1.3\n" ~"#0 child_sub_function () ... =thread-selected,id="3",frame={level="0",...} ^done frame ----- 1. CLI command: frame 1 MI event: =thread-selected,id="3",frame={level="1",...} 2. MI command: -stack-select-frame 1 CLI event: #1 0x00000000004007f0 in child_function... 3. MI command (CLI-in-MI): frame 1 MI event/reply: &"frame 1\n" ~"#1 0x00000000004007f9 in ..." =thread-selected,id="3",frame={level="1"...} ^done inferior -------- Inferior selection events only go from the console to MI, since there's no way to select the inferior in pure MI. 1. CLI command: inferior 2 MI event: =thread-selected,id="3" Note that if the user selects an inferior that is not started or exited, the MI doesn't receive a notification. Since there is no threads to select, the =thread-selected event does not apply... 2. MI command (CLI-in-MI): inferior 2 MI event/reply: &"inferior 2\n" ~"[Switching to inferior 2 ...]" =thread-selected,id="4",frame={level="0"...} ^done Internal implementation detail: this patch makes it possible to suppress notifications caused by a CLI command, like what is done in mi-interp.c. This means that it's now possible to use the add_com_suppress_notification function to register a command with some event suppressed. It is used to implement the select-frame command in this patch. The function command_notifies_uscc_observer was added to extract the rather complicated logical expression from the if statement. It is also now clearer what that logic does: if the command used by the user already notifies the user_selected_context_changed observer, there is not need to notify it again. It therefore protects again emitting the event twice. No regressions, tested on ubuntu 14.04 x86 with target boards unix and native-extended-gdbserver. gdb/ChangeLog: YYYY-MM-DD Antoine Tremblay <antoine.tremblay@ericsson.com> YYYY-MM-DD Simon Marchi <simon.marchi@ericsson.com> PR gdb/20487 * NEWS: Mention new frame field of =thread-selected event. * cli/cli-decode.c (add_cmd): Initialize c->suppress_notification. (add_com_suppress_notification): New function definition. (cmd_func): Set and restore the suppress_notification flag. * cli/cli-deicode.h (struct cmd_list_element) <suppress_notification>: New field. * cli/cli-interp.c (cli_suppress_notification): New global variable. (cli_on_user_selected_context_changed): New function. (_initialize_cli_interp): Attach to user_selected_context_changed observer. * command.h (struct cli_suppress_notification): New structure. (cli_suppress_notification): New global variable declaration. (add_com_suppress_notification): New function declaration. * defs.h (enum user_selected_what_flag): New enum. (user_selected_what): New enum flag type. * frame.h (print_stack_frame_to_uiout): New function declaration. * gdbthread.h (print_selected_thread_frame): New function declaration. * inferior.c (print_selected_inferior): New function definition. (inferior_command): Remove printing of inferior/thread/frame switch notifications, notify user_selected_context_changed observer. * inferior.h (print_selected_inferior): New function declaration. * mi/mi-cmds.c (struct mi_cmd): Add user_selected_context suppression to stack-select-frame and thread-select commands. * mi/mi-interp.c (struct mi_suppress_notification) <user_selected_context>: Initialize. (mi_user_selected_context_changed): New function definition. (_initialize_mi_interp): Attach to user_selected_context_changed. * mi/mi-main.c (mi_cmd_thread_select): Print thread selection reply. (mi_execute_command): Handle notification suppression. Notify user_selected_context_changed observer on thread change instead of printing event directly. Don't send it if command already sends the notification. (command_notifies_uscc_observer): New function. (mi_cmd_execute): Don't handle notification suppression. * mi/mi-main.h (struct mi_suppress_notification) <user_selected_context>: New field. * stack.c (print_stack_frame_to_uiout): New function definition. (select_frame_command): Notify user_selected_context_changed observer. (frame_command): Call print_selected_thread_frame if there's no frame change or notify user_selected_context_changed observer if there is. (up_command): Notify user_selected_context_changed observer. (down_command): Likewise. (_initialize_stack): Suppress user_selected_context notification for command select-frame. * thread.c (thread_command): Notify user_selected_context_changed if the thread has changed, print thread info directly if it hasn't. (do_captured_thread_select): Do not print thread switch event. (print_selected_thread_frame): New function definition. * tui/tui-interp.c (tui_on_user_selected_context_changed): New function definition. (_initialize_tui_interp): Attach to user_selected_context_changed observer. gdb/doc/ChangeLog: PR gdb/20487 * gdb.texinfo (Context management): Update mention of frame change notifications. (gdb/mi Async Records): Document frame field in =thread-select event. * observer.texi (GDB Observers): New user_selected_context_changed observer. gdb/testsuite/ChangeLog: PR gdb/20487 * gdb.mi/mi-pthreads.exp (check_mi_thread_command_set): Adapt =thread-select-event check.
2016-09-29PR gdb/20609 - attach of JIT-debug-enabled inf 7.11.1 regressionJan Kratochvil1-0/+9
Regression: gdb --pid $(pidof qemu-system-x86_64) stopped working with gdb 7.11.1 https://sourceware.org/bugzilla/show_bug.cgi?id=20609 It was reported for qemu-system-x86_64 but it happens for any multithreaded inferior with a JIT debugging hook. 136613ef0c6850427317e57be1b644080ff6decb is the first bad commit Author: Pedro Alves <palves@redhat.com> Fix PR gdb/19828: gdb -p <process from a container>: internal error Message-ID: <cbdf2e04-4fa8-872a-2a23-08c9c1b26e00@redhat.com> https://sourceware.org/ml/gdb-patches/2016-05/msg00450.html jit_breakpoint_re_set() is specific by trying to insert a breakpoint into the main executable, not into a shared library. During attachment GDB thinks it needs to use 'breakpoint always-inserted' from breakpoints_should_be_inserted_now() as a newly attached thread is 'thread_info->executing' due to 'lwp_info->must_set_ptrace_flags' enabled and the task not yet stopped. This did not happen before the 'bad commit' above which adds tracking of such thread. GDB then fails to insert the breakpoints to invalid address as PIE executable gets properly relocated during later phase of attachment. One can see in the backtraces below: -> jit_breakpoint_re_set_internal() later: -> svr4_exec_displacement() One can suppress the initial breakpoint_re_set() call as there will be another breakpoint_re_set() done from the final post_create_inferior() call in setup_inferior(). BTW additionally 'threads_executing' cache bool is somehow stale (somewhere is missing update_threads_executing()). I was trying to deal with that in my first/second attempt below but in my final third attempt (attached) I have left it as it is. First attempt trying not to falsely require 'breakpoint always-inserted': https://people.redhat.com/jkratoch/rhbz1375553-fix1.patch Reduced first attempt: https://people.redhat.com/jkratoch/rhbz1375553-fix2.patch The third attempt suppresses breakpoint insertion until PIE executable gets relocated by svr4_exec_displacement(). Applied. gdb/ChangeLog 2016-09-29 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/20609 - attach of JIT-debug-enabled inf 7.11.1 regression * exec.c (exec_file_locate_attach): Add parameter defer_bp_reset. Use it. * gdbcore.h (exec_file_locate_attach): Add parameter defer_bp_reset. * infcmd.c (setup_inferior): Update caller. * remote.c (remote_add_inferior): Likewise. gdb/testsuite/ChangeLog 2016-09-29 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/20609 - attach of JIT-debug-enabled inf 7.11.1 regression * gdb.base/jit-attach-pie.c: New file. * gdb.base/jit-attach-pie.exp: New file.
2016-09-28Fix PR 20345 - call_function_by_hand_dummy: Assertion `tp->thread_fsm == ↵Pedro Alves1-0/+5
&sm->thread_fsm' failed If you run an infcall from the command line, and immediately after run some other command, GDB incorrectly processes the other command before the infcall finishes. The problem is that the fix for PR gdb/20418 (Problems with synchronous commands and new-ui, git 3eb7562a983b) moved the add_file_handler/delete_file_handler calls out of target_terminal_$foo, and missed adjusting the infcall code. gdb/ChangeLog: 2016-09-28 Pedro Alves <palves@redhat.com> * infcall.c (run_inferior_call): Remove input from the event loop while running the infcall. gdb/testsuite/ChangeLog: 2016-09-28 Pedro Alves <palves@redhat.com> * gdb.base/infcall-input.c: New file. * gdb.base/infcall-input.exp: New file.
2016-09-27Detect the magic address of EXC_RETURN in ARM coretx-m profileFredrik Hederstierna1-0/+6
On ARMv6-M and ARMv7-M, the exception return address is sort of magic address defined by the manual. This patch is to let GDB well handle these magic addresses. 2016-09-27 Fredrik Hederstierna <fredrik.hederstierna@verisure.com> * arm-tdep.c (arm_m_addr_is_magic): New function. (arm_addr_bits_remove): Call arm_m_addr_is_magic. (arm_m_exception_unwind_sniffer): Likewise.
2016-09-21Keep reserved bits in CPSR on writeYao Qi1-0/+5
In patch https://sourceware.org/ml/gdb-patches/2016-04/msg00529.html I cleared reserved bits when reading CPSR. It makes a problem that these bits (zero) are written back to kernel through ptrace, and it changes the state of the processor on some recent kernel, which is unexpected. In this patch, I keep these reserved bits when write CPSR back to hardware. gdb: 2016-09-21 Yao Qi <yao.qi@linaro.org> * aarch32-linux-nat.c (aarch32_gp_regcache_collect): Keep bits 20 to 23. gdb/gdbserver: 2016-09-21 Yao Qi <yao.qi@linaro.org> * linux-aarch32-low.c (arm_fill_gregset): Keep bits 20 to 23.
2016-09-20ppc: Fix record support of Store String Word instructionsEdjunior Barbosa Machado1-0/+5
gdb/ChangeLog 2016-09-20 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com> * rs6000-tdep.c (ppc_process_record_op31): Fix record of Store String Word instructions.
2016-09-06new-ui command: gdb internal errors if input is already pendingPedro Alves1-0/+6
I noticed that if input is already pending on the new-ui TTY, gdb internal-errors. E.g., create /dev/pts/2, and type anything there (even just <return> is sufficient). Now start GDB creating a new UI on that TTY, while at the same time, running a synchronous execution command. Something like: $ gdb program -ex "new-ui console /dev/pts/2" -ex "start" Back on /dev/pts/2, we get: (gdb) .../src/gdb/event-top.c:360: internal-error: double prompt A problem internal to GDB has been detected, further debugging may prove unreliable. While the main UI was waiting for "start" to finish, gdb kepts pumping events, including the input fd of the extra console. The problem is that stdin_event_handler doesn't restore the current UI back to what it was, assuming that it's only ever called from the top level event loop. However, in this case, it's being called from the nested event loop from within maybe_wait_sync_command_done. When finally the "start" command is done, we reach the code that prints the prompt in the main UI, just before starting the main event loop. Since now the current UI is pointing at the extra console (by mistake), we find ourselves printing a double prompt on the extra console. This is caught by the assertion that fails, as shown above. Since other event handlers also don't restore the UI (e.g., signal event handlers), I think it's better if whatever is pumping events to take care to restore the UI, if it cares. That's what this patch does. New test included. gdb/ChangeLog: 2016-09-06 Pedro Alves <palves@redhat.com> * top.c (wait_sync_command_done): Don't assume current_ui doesn't change across events. Restore the current UI before returning. (gdb_readline_wrapper): Restore the current UI before returning. gdb/testsuite/ChangeLog: 2016-09-06 Pedro Alves <palves@redhat.com> * gdb.base/new-ui-pending-input.c: New file. * gdb.base/new-ui-pending-input.exp: New file. * gdb.exp (clear_gdb_spawn_id): New procedure. (with_spawn_id): Check whether gdb_spawn_id exists before referencing it. If gdb_spawn_id didn't exist on entry, clear it on exit.
2016-09-06Introduce make_cleanup_restore_current_uiPedro Alves1-0/+11
Just a tidy, no functional changes. gdb/ChangeLog: 2016-09-06 Pedro Alves <palves@redhat.com> * event-top.c (restore_ui_cleanup): Now static. (make_cleanup_restore_current_ui): New function. (switch_thru_all_uis_init): Use it. * infcall.c (call_thread_fsm_should_stop): Use it. * infrun.c (fetch_inferior_event): Use it. * top.c (new_ui_command): Use it. * top.h (restore_ui_cleanup): Delete declaration. (make_cleanup_restore_current_ui): New declaration.
2016-08-30Fix order of inferiors in "thread apply all"Andreas Arnez1-0/+4
This inserts missing parentheses in the calculation of the comparison result between two different inferior numbers. The problem was found by Philipp Rudo. gdb/ChangeLog: * thread.c (tp_array_compar): Insert missing parentheses. gdb/testsuite/ChangeLog: * gdb.multi/tids.exp: Test "thread apply all".
2016-08-26xtensa: Avoid designated inits, for C++ complianceAndreas Arnez1-0/+6
C++ does not officially support designators in initializer lists. Thus some compilers may issue errors when encountering them. Modern versions of GCC seem to allow them by default, as a GCC extension, even though the GCC documentation explicitly states otherwise: "[...] This extension is not implemented in GNU C++." But some older GCC versions (like 4.4.7) did indeed emit an error instead, like this: .../gdb/xtensa-config.c:219: error: expected primary-expression before ‘.’ token This patch removes the only such instance I've seen when building with '--enable-targets=all'. gdb/ChangeLog: * xtensa-tdep.h (XTENSA_GDBARCH_TDEP_INSTANTIATE): Replace designated initializer list by plain initializer list, for C++ compliance.
2016-08-25Sync proc_service definition with GLIBCAdhemerval Zanella1-0/+14
GLIBC BZ#20311 [1] proc_service.h install patch also remove 'const' attributes from ps_get_thread_area and comment #15 discuss why to remove the const attribute (basically since it a callback with the struct ps_prochandle owned by the client it should be able to modify it if it the case). On default build this is not the issue and current g++ does not trigger any issue with this mismatch declaration. However, on some bootstrap build configuration where gdbserver is build with gcc instead this triggers: error: conflicting types for 'ps_get_thread_area' This patch fixes it by syncing the declaration with GLIBC. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=20311 gdb/ChangeLog: 2016-08-25 Adhemerval Zanella <adhemerval.zanella@linaro.org> * aarch64-linux-nat.c (ps_get_thread_area): Remove const from struct ps_prochandle. * amd64-linux-nat.c (ps_get_thread_area): Likewise. * arm-linux-nat.c (ps_get_thread_area): Likewise. * gdb_proc_service.h (ps_get_thread_area): Likewise. * i386-linux-nat.c (ps_get_thread_area): Likewise. * m68klinux-nat.c (ps_get_thread_area): Likewise. * mips-linux-nat.c (ps_get_thread_area): Likewise. * nat/aarch64-linux.c (aarch64_ps_get_thread_area): Likewise. * nat/aarch64-linux.h (aarch64_ps_get_thread_area): Likewise. * xtensa-linux-nat.c (ps_get_thread_area): Likewise. gdb/gdbserver/ChangeLog: 2016-08-25 Adhemerval Zanella <adhemerval.zanella@linaro.org> PR server/20491 * gdb_proc_service.h (ps_get_thread_area): Remove const from struct ps_prochandle. * linux-aarch64-low.c (ps_get_thread_area): Likewise. * linux-arm-low.c (ps_get_thread_area): Likewise. * linux-crisv32-low.c (ps_get_thread_area): Likewise. * linux-m68k-low.c (ps_get_thread_area): Likewise. * linux-mips-low.c (ps_get_thread_area): Likewise. * linux-nios2-low.c (ps_get_thread_area): Likewise. * linux-tic6x-low.c (ps_get_thread_area): Likewise. * linux-x86-low.c (ps_get_thread_area): Likewise. * linux-xtensa-low.c (ps_get_thread_area): Likewise.
2016-08-24Allow resetting an empty inferior-ttySimon Marchi1-0/+7
This patch allows the user to set the inferior-tty to "empty", in order to come back to the default behaviour of using the same tty as gdb is using. This is already supported in MI (and tested in gdb.mi/mi-basics.exp). I added a new test, set-inferior-tty.exp, where I test only the setting and unsetting of the parameter. It would be nice to actually test that the inferior output properly goes to the separate tty, but that will be for another day. gdb/ChangeLog: * infcmd.c (set_inferior_io_terminal): Set inferior terminal to NULL if terminal_name is an empty string. (_initialize_infcmd): Make the argument of "set inferior-tty" optional, mention it in the help doc. gdb/doc/ChangeLog: * gdb.texinfo (Input/Output): Mention possibility to unset inferior-tty. gdb/testsuite/ChangeLog: * gdb.base/set-inferior-tty.exp: New file. * gdb.base/set-inferior-tty.c: New file.
2016-08-23x32: gdb: Fix 'call' insn relocation with qRelocInsnPedro Alves1-0/+5
Running the fast tracepoints tests against x32 gdbserver exposes a latent bug. E.g.,: (gdb) continue Continuing. Reading /media/sf_host-pedro/gdb/mygit/build-ubuntu-x32/gdb/testsuite/outputs/gdb.trace/change-loc/change-loc-2.sl from remote target... Thread 1 "change-loc" received signal SIGSEGV, Segmentation fault. func4 () at /home/pedro/gdb/src/gdb/testsuite/gdb.trace/change-loc.h:24 24 } (gdb) FAIL: gdb.trace/change-loc.exp: 1 ftrace: continue to marker 2 The test sets a fast tracepoint on a shared library. On x32, shared libraries end up loaded somewhere in the upper 2GB of the 4GB address space x32 has access to. When gdbserver needs to copy an instruction to execute it in the jump pad, it asks gdb to relocate/adjust it, with the qRelocInsn packet. gdb converts "call" instructions into a "push $<2GB-4GB addr> + jmp" sequence, however, the "pushq" instruction sign extends its operand, so later when the called function returns, it returns to an incorrectly sign-extended address. E.g., 0xfffffffffabc0000 instead of 0xfabc0000, resulting in the segmentation fault. Fix this by converting calls at such addresses to "sub + mov + jmp" sequences instead. gdb/ChangeLog: 2016-08-23 Pedro Alves <palves@redhat.com> * amd64-tdep.c (amd64_relocate_instruction) <callq>: Handle return addresses over 0x7fffffff.
2016-08-23Fix PR20494 - User input stops being echoed in CLIPedro Alves1-0/+16
This patch fixes a problem that problem triggers if you start an inferior, e.g., with the "start" command, in a UI created with the new-ui command, and then run a foreground execution command in the main UI. Once the program stops for the latter command, typing in the main UI no longer echoes back to the user. The problem revolves around this: - gdb_has_a_terminal computes its result lazily, on first call. that is what saves gdb's initial main UI terminal state (the UI associated with stdin): our_terminal_info.ttystate = serial_get_tty_state (stdin_serial); This is the state that target_terminal_ours() restores. - In this scenario, the gdb_has_a_terminal function happens to be first ever called from within the target_terminal_init call in startup_inferior: (top-gdb) bt #0 gdb_has_a_terminal () at src/gdb/inflow.c:157 #1 0x000000000079db22 in child_terminal_init_with_pgrp () at src/gdb/inflow.c:217 [...] #4 0x000000000065bacb in target_terminal_init () at src/gdb/target.c:456 #5 0x00000000004676d2 in startup_inferior () at src/gdb/fork-child.c:531 [...] #7 0x000000000046b168 in linux_nat_create_inferior () at src/gdb/linux-nat.c:1112 [...] #9 0x00000000005f20c9 in start_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:657 If the command to start the inferior is issued on the main UI, then readline will have deprepped the terminal when we reach the above, and the problem doesn't appear. If however the command is issued on a non-main UI, then when we reach that gdb_has_a_terminal call, the main UI's terminal state is still set to whatever readline has sets it to in rl_prep_terminal, which happens to have echo disabled. Later, when the following synchronous execution command finishes, we'll call target_terminal_ours to restore gdb's the main UI's terminal settings, and that restores the terminal state with echo disabled... Conceptually, the fix is to move the gdb_has_a_terminal call earlier, to someplace during GDB initialization, before readline/ncurses have had a chance to change terminal settings. Turns out that "set_initial_gdb_ttystate" is exactly such a place. I say conceptually, because the fix actually inlines the gdb_has_a_terminal part that saves the terminal state in set_initial_gdb_ttystate and then simplifies gdb_has_a_terminal, since there's no point in making gdb_has_a_terminal do lazy computation. gdb/ChangeLog: 2016-08-23 Pedro Alves <palves@redhat.com> PR gdb/20494 * inflow.c (our_terminal_info, initial_gdb_ttystate): Update comments. (enum gdb_has_a_terminal_flag_enum, gdb_has_a_terminal_flag): Delete. (set_initial_gdb_ttystate): Record our_terminal_info here too, instead of ... (gdb_has_a_terminal): ... here. Reimplement in terms of initial_gdb_ttystate. Make static. * terminal.h (gdb_has_a_terminal): Delete declaration. (set_initial_gdb_ttystate): Add comment. * top.c (show_interactive_mode): Use input_interactive_p instead of gdb_has_a_terminal. gdb/testsuite/ChangeLog: 2016-08-23 Pedro Alves <palves@redhat.com> PR gdb/20494 * gdb.base/new-ui-echo.c: New file. * gdb.base/new-ui-echo.exp: New file.
2016-08-22Fix PR gdb/20505 - Make vDSO detection work with core filesPedro Alves1-0/+8
Loading a core dump that was either generated on a system running pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused set in the environment, solib-svr4.c:svr4_current_sos fails to filter out the vDSO, resulting in: (gdb) core-file corefile.core^M [New LWP 2362]^M warning: Could not load shared library symbols for linux-vdso.so.1.^M Do you need "set solib-search-path" or "set sysroot"?^M Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M ... The problem is that gdbarch_vsyscall_range does not support core inferiors at all. When live debugging, we're finding the vDSO's start address with auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the corresponding mapping, by parsing /proc/PID/maps. When debugging a core dump, we can also determine the starting address from auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core mappings out of the host's /proc. But we can instead look for a corresponding load segment in the core's bfd. gdb/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * linux-tdep.c (linux_vsyscall_range_raw): For core inferiors, find the vDSO's start address with AT_SYSINFO_EHDR too, and determine the vDSO's size by finding the PT_LOAD segment that matches AT_SYSINFO_EHDR. gdb/testsuite/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * gdb.base/vdso-warning.exp: Test core dumps too. Use with_test_prefix. Factor out bits to ... (test_no_vdso): ... this new procedure.
2016-08-19[AArch64] Match instruction "STP with base register" in prologueYao Qi1-0/+5
Nowadays, we only match pre-indexed STP in prologue. Due to the change in gcc, https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01933.html, it may generate "STP with base register" in prologue, which GDB doesn't handle. That is to say, previously GCC generates prologue like this, sub sp, sp, #490 stp x29, x30, [sp, #-96]! mov x29, sp with the gcc patch above, GCC generates prologue like like this, sub sp, sp, #4f0 stp x29, x30, [sp] mov x29, sp This patch is to teach GDB to recognize this instruction in prologue analysis. gdb: 2016-08-19 Yao Qi <yao.qi@linaro.org> * aarch64-tdep.c (aarch64_analyze_prologue): Handle register based STP instruction.
2016-08-19null-terminate string in linespec_location_completerYao Qi1-0/+5
If I build gdb with -fsanitize=address and run tests, I get error, malformed linespec error: unexpected colon^M (gdb) PASS: gdb.linespec/ls-errs.exp: lang=C: break : break :=================================================================^M ==3266==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000051451 at pc 0x2b5797a972a8 bp 0x7fffd8e0f3c0 sp 0x7fffd8e0f398^M READ of size 2 at 0x602000051451 thread T0 #0 0x2b5797a972a7 in __interceptor_strlen (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x322a7)^M #1 0x7bd004 in compare_filenames_for_search(char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:316^M #2 0x7bd310 in iterate_over_some_symtabs(char const*, char const*, int (*)(symtab*, void*), void*, compunit_symtab*, compunit_symtab*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:411^M #3 0x7bd775 in iterate_over_symtabs(char const*, int (*)(symtab*, void*), void*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:481^M #4 0x7bda15 in lookup_symtab(char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:527^M #5 0x7d5e2a in make_file_symbol_completion_list_1 /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:5635^M #6 0x7d61e1 in make_file_symbol_completion_list(char const*, char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/symtab.c:5684^M #7 0x88dc06 in linespec_location_completer /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:288 .... 0x602000051451 is located 0 bytes to the right of 1-byte region [0x602000051450,0x602000051451)^M mallocated by thread T0 here: #0 0x2b5797ab97ef in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x547ef)^M #1 0xbbfb8d in xmalloc /home/yao/SourceCode/gnu/gdb/git/gdb/common/common-utils.c:43^M #2 0x88dabd in linespec_location_completer /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:273^M #3 0x88e5ef in location_completer(cmd_list_element*, char const*, char const*) /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:531^M #4 0x8902e7 in complete_line_internal /home/yao/SourceCode/gnu/gdb/git/gdb/completer.c:964^ The code in question is here file_to_match = (char *) xmalloc (colon - text + 1); strncpy (file_to_match, text, colon - text + 1); it is likely that file_to_match is not null-terminated. The patch is to strncpy 'colon - text' bytes and explicitly set '\0'. gdb: 2016-08-19 Yao Qi <yao.qi@linaro.org> * completer.c (linespec_location_completer): Make file_to_match null-terminated.
2016-08-18ppc: Fix record of HTM instructionsEdjunior Barbosa Machado1-0/+4
The patch fixes the record support of Hardware Transactional Memory instructions on Power. It also solves a large number of unexpected failures from gdb.reverse testcases sigall-precsave.exp and sigall-reverse.exp that occur on distros which glibc uses HTM instructions. gdb/ChangeLog 2016-08-18 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com> * rs6000-tdep.c (ppc_process_record_op31): Handle HTM instructions.
2016-08-15[GDB] Fix builds broken by proc-service changes.Matthew Wahab1-0/+6
GLIBC BZ#20311 introduced a change to install proc_service.h so that gdb didn't have to use the version it embeds in gdb_proc_service.h. The embedded version is guarded by HAVE_PROC_SERVICE_H and gdb_proc_service.h has a number other of includes and definitions, all of which are uncondional except for an include for gregset.h. This is only included if HAVE_PROC_SERIVCE_H is not defined. This causes a build failure when cross compiling gdb with the latest glibc because type definitions in gregset are used independently of HAVE_PROC_SERIVCE_H. In particular, they are used in gdb_proc_service.h when PRFPREGSET_T_BROKEN is set. The error messages on the failure are ---- binutils-gdb/gdb/gdb_proc_service.h:173:9: error: ‘gdb_fpregset_t’ does not name a type; did you mean ‘elf_fpregset_t’? typedef gdb_fpregset_t gdb_prfpregset_t; ^~~~~~~~~~~~~~ elf_fpregset_t binutils-gdb/gdb/gdb_proc_service.h:173:9: error: ‘gdb_fpregset_t’ does not name a type; did you mean ‘elf_fpregset_t’? typedef gdb_fpregset_t gdb_prfpregset_t; ^~~~~~~~~~~~~~ elf_fpregset_t binutils-gdb/gdb/proc-service.c:218:15: error: ‘gdb_prfpregset_t’ does not name a type; did you mean ‘gdb_fpregset_t’? const gdb_prfpregset_t *fpregset) ^~~~~~~~~~~~~~~~ gdb_fpregset_t ---- This patch moves the include for gregset.h to before the code guarded by HAVE_PROC_SERIVCE_H, so that it is always included. This is enough to fix the build. 2016-08-15 Matthew Wahab <matthew.wahab@arm.com> PR gdb/20457 * gdb_proc_service.h: Add an include of gregset.h [!HAVE_PROC_SERVICE_H]: Remove the include of gregset.h.
2016-08-15Fix heap-buffer-overflow in explicit_location_lex_oneYao Qi1-0/+6
I build GDB with -fsanitize=address, and see the error in tests, (gdb) PASS: gdb.linespec/ls-errs.exp: lang=C++: break 3 foo break -line 3 foo^M =================================================================^M ==4401==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000047487 at pc 0x819d8e bp 0x7fff4e4e6bb0 sp 0x7fff4e4e6ba8^M READ of size 1 at 0x603000047487 thread T0^[[1m^[[0m^M #0 0x819d8d in explicit_location_lex_one /home/yao/SourceCode/gnu/gdb/git/gdb/location.c:502^M #1 0x81a185 in string_to_explicit_location(char const**, language_defn const*, int) /home/yao/SourceCode/gnu/gdb/git/gdb/location.c:556^M #2 0x81ac10 in string_to_event_location(char**, language_defn const*) /home/yao/SourceCode/gnu/gdb/git/gdb/location.c:687^ the code in question is: > /* Special case: C++ operator,. */ > if (language->la_language == language_cplus > && strncmp (*inp, "operator", 8) <--- [1] > && (*inp)[9] == ',') > (*inp) += 9; > ++(*inp); The error is caused by the access to (*inp)[9] if 9 is out of its bounds. However [1] looks odd to me, because if strncmp returns true (non-zero), the following check "(*inp)[9] == ','" makes no sense any more. I suspect it was a typo in the code we meant to "strncmp () == 0". Another problem in the code above is that if *inp is "operator,", we first increment *inp by 9, and then increment it by one again, which is wrong to me. We should only increment *inp by 8 to skip "operator", and go back to the loop header to decide where we stop. gdb: 2016-08-15 Yao Qi <yao.qi@linaro.org> * location.c (explicit_location_lex_one): Compare the return value of strncmp with zero. Don't check (*inp)[9]. Increment *inp by 8.
2016-08-11Fix fallout from gdb/20413's fix (x32: linux_ptrace_test_ret_to_nx: Cannot ↵Pedro Alves1-0/+6
PTRACE_PEEKUSER) Fixes, on NIOS GNU/Linux: In file included from /scratch/mbilal/nois-lite/src/gdb-trunk/gdb/gdbserver/../nat/linux-ptrace.c:26:0: /scratch/mbilal/nois-lite/src/gdb-trunk/gdb/gdbserver/../gregset.h:27:23: error: unknown type name 'gregset_t' #define GDB_GREGSET_T gregset_t ^ Fix this by including sys/procfs.h directly. We shouldn't really be including a gdb-only header in a gdb/nat/ file, anyway. Whoops. gdb/ChangeLog: 2016-08-11 Pedro Alves <palves@redhat.com> PR gdb/20413 * nat/linux-ptrace.c: Include <sys/procfs.h> instead of "gregset.h".
2016-08-10Fix PR gdb/19187 (process record over a fork causes internal error)Pedro Alves1-0/+7
Right after a fork is detected, we detach breakpoints from the child (detach_breakpoints), which calls into target_remove_breakpoint with inferior_ptid pointing at the child process, but leaves the breakpoint marked inserted (in the parent). The problem is that record-full.c always deletes all knowledge of the breakpoint. Then when we later really delete the breakpoint from the parent, we fail the assertion, since the breakpoint is unexpectedly not found in the record-full.c breakpoint table. The fix is simply to not forget about the breakpoint if we're detaching it from a fork child. gdb/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> PR gdb/19187 * record-full.c (record_full_remove_breakpoint): Don't remove the breakpoint from the record_full_breakpoints VEC if we're detaching the breakpoint from a fork child. gdb/testsuite/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> PR gdb/19187 * gdb.reverse/waitpid-reverse.exp: Add comment and remove setup_kfails.
2016-08-10Plumb enum remove_bp_reason all the way to target_remove_breakpointPedro Alves1-0/+35
So the target knows whether we're detaching breakpoints. Nothing uses the parameter in this patch yet. gdb/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> PR gdb/19187 * break-catch-sig.c (signal_catchpoint_remove_location): Adjust interface. * break-catch-syscall.c (remove_catch_syscall): * breakpoint.c (enum remove_bp_reason): Moved to breakpoint.h. (remove_breakpoint_1): Pass 'reason' down. (remove_catch_fork, remove_catch_vfork, remove_catch_solib) (remove_catch_exec, remove_watchpoint, remove_masked_watchpoint) (base_breakpoint_remove_location, bkpt_remove_location) (bkpt_probe_remove_location, bkpt_probe_remove_location): Adjust interface. * breakpoint.h (enum remove_bp_reason): Moved here from breakpoint.c. (struct breakpoint_ops) <remove_location>: Add 'reason' parameter. * corelow.c (core_remove_breakpoint): New function. (init_core_ops): Install it as to_remove_breakpoint method. * exec.c (exec_remove_breakpoint): New function. (init_exec_ops): Install it as to_remove_breakpoint method. * mem-break.c (memory_remove_breakpoint): Adjust interface. * record-btrace.c (record_btrace_remove_breakpoint): Adjust interface. * record-full.c (record_full_remove_breakpoint) (record_full_core_remove_breakpoint): Adjust interface. * remote.c (remote_remove_breakpoint): Adjust interface. * target-debug.h (target_debug_print_enum_remove_bp_reason): New macro. * target-delegates.c: Regenerate. * target.c (target_remove_breakpoint): Add 'reason' parameter. * target.h (struct target_ops) <to_remove_breakpoint>: Add 'reason' parameter. (target_remove_breakpoint, memory_remove_breakpoint): Add 'reason' parameter.
2016-08-10Introduce 'enum remove_bp_reason'Pedro Alves1-0/+8
Makes the code more obvious. gdb/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> PR gdb/19187 * breakpoint.c (insertion_state_t): Delete. (enum remove_bp_reason): New. (detach_breakpoints, remove_breakpoint_1, remove_breakpoint): Adjust to use enum remove_bp_reason instead of insertion_state_t.
2016-08-10Simplify remove_breakpoint interfacePedro Alves1-0/+9
All callers pass mark_uninserted, so there's no need for the 'is' parameter. gdb/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> PR gdb/19187 * breakpoint.c (remove_breakpoint): Remove 'is' parameter and always pass mark_uninserted to remove_breakpoint_1. (insert_breakpoint_locations, remove_breakpoints) (remove_breakpoints_pid, update_global_location_list): Update callers.
2016-08-10Quiet ARI gettext checksPedro Alves1-0/+6
The ARI complains about this new file: common/signals-state-save-restore.c:46: warning: gettext: All messages should be marked up with _. common/signals-state-save-restore.c:59: warning: gettext: All messages should be marked up with _. common/signals-state-save-restore.c:87: warning: gettext: All messages should be marked up with _. common/signals-state-save-restore.c:92: warning: gettext: All messages should be marked up with _. Since these are untranslatable strings, use () instead of _(). gdb/ChangeLog: 2016-08-10 Pedro Alves <palves@redhat.com> * common/signals-state-save-restore.c (save_original_signals_state, restore_original_signals_state): Wrap perror_with_name arguments with '()'.
generated by cgit v1.1 at 2024-11-22 06:30:33 +0000