aboutsummaryrefslogtreecommitdiff
path: root/gdb/ChangeLog
AgeCommit message (Collapse)AuthorFilesLines
2019-03-05Remove gdb_bfd_fdopenrTom Tromey1-0/+5
I noticed that gdb_bfd_fdopenr is no longer used, so this patch removes it. Tested by rebuilding and by grep. gdb/ChangeLog 2019-03-05 Tom Tromey <tromey@adacore.com> * gdb_bfd.c (gdb_bfd_fdopenr): Remove. * gdb_bfd.h (gdb_bfd_fdopenr): Don't declare.
2019-03-05Remove excess calls to gdb_flushTom Tromey1-0/+33
A customer noticed some mildly odd MI output, where CLI output was split into multiple MI strings at unusual boundaries, like this: ~"$1 = (b => true" ~", p => 0x407260" This is technically correct according to the MI spec, but still unusual, in that there's no particular reason for the string to be split where it is. I tracked this down to a call to gdb_flush in generic_val_print. Then, I went through all calls to gdb_flush and removed the ones I thought were superfluous. In particular: * Any call in the value-printing code; * Likewise the type-printing code (just a single call); and * Any call that immediately followed a printf that obviously ended with a newline, my belief being that gdb's standard output streams are line buffered (by inheriting the behavior from stdio) Regression tested on x86-64 Fedora 29. I didn't add a new test case. I tend to think we don't necessarily want to specify this behavior in the tests. Let me know what you think of this. gdb/ChangeLog 2019-03-05 Tom Tromey <tromey@adacore.com> * windows-nat.c (windows_nat_target::attach) (windows_nat_target::detach): Don't call gdb_flush. * valprint.c (generic_val_print, val_print, val_print_string): Don't call gdb_flush. * utils.c (defaulted_query): Don't call gdb_flush. * typeprint.c (print_type_scalar): Don't call gdb_flush. * target.c (target_announce_detach): Don't call gdb_flush. * sparc64-tdep.c (adi_print_versions): Don't call gdb_flush. * remote.c (extended_remote_target::attach): Don't call gdb_flush. * procfs.c (procfs_target::detach): Don't call gdb_flush. * printcmd.c (do_examine): Don't call gdb_flush. (info_display_command): Don't call gdb_flush. * p-valprint.c (pascal_val_print): Don't call gdb_flush. * nto-procfs.c (nto_procfs_target::attach): Don't call gdb_flush. * memattr.c (info_mem_command): Don't call gdb_flush. * mdebugread.c (mdebug_build_psymtabs): Don't call gdb_flush. * m2-valprint.c (m2_val_print): Don't call gdb_flush. * infrun.c (follow_exec, handle_command): Don't call gdb_flush. * inf-ptrace.c (inf_ptrace_target::attach): Don't call gdb_flush. * hppa-tdep.c (unwind_command): Don't call gdb_flush. * gnu-nat.c (gnu_nat_target::attach): Don't call gdb_flush. (gnu_nat_target::detach): Don't call gdb_flush. * f-valprint.c (f_val_print): Don't call gdb_flush. * darwin-nat.c (darwin_nat_target::attach): Don't call gdb_flush. * cli/cli-script.c (read_command_lines): Don't call gdb_flush. * cli/cli-cmds.c (shell_escape, print_disassembly): Don't call gdb_flush. * c-valprint.c (c_val_print): Don't call gdb_flush. * ada-valprint.c (ada_print_scalar): Don't call gdb_flush.
2019-03-05Add ATTRIBUTE_UNUSED_RESULT to ref_ptr::releaseTom Tromey1-0/+9
This applies ATTRIBUTE_UNUSED_RESULT to ref_ptr::release and updates a few spots to comply. I believe one use in install_default_visualizer was in error, fixed by this patch. gdb/ChangeLog 2019-03-05 Tom Tromey <tromey@adacore.com> * varobj.c (update_dynamic_varobj_children): Update. (install_default_visualizer): Use reset, not release. * value.c (set_internalvar): Update. * dwarf2loc.c (value_of_dwarf_reg_entry): Update. * common/gdb_ref_ptr.h (class ref_ptr) <release>: Add ATTRIBUTE_UNUSED_RESULT.
2019-03-05Add ATTRIBUTE_UNUSED_RESULT to scoped_remote_fd::releaseTom Tromey1-0/+5
This applies ATTRIBUTE_UNUSED_RESULT to scoped_remote_fd::release. gdb/ChangeLog 2019-03-05 Tom Tromey <tromey@adacore.com> * remote.c (class scoped_remote_fd) <release>: Add ATTRIBUTE_UNUSED_RESULT.
2019-03-05Add ATTRIBUTE_UNUSED_RESULT to macro_bufferTom Tromey1-0/+5
This applies ATTRIBUTE_UNUSED_RESULT to macro_buffer::release. gdb/ChangeLog 2019-03-05 Tom Tromey <tromey@adacore.com> * macroexp.c (struct macro_buffer) <release>: Add ATTRIBUTE_UNUSED_RESULT.
2019-03-05Add ATTRIBUTE_UNUSED_RESULT to scoped_mmapTom Tromey1-0/+6
This applies ATTRIBUTE_UNUSED_RESULT to scoped_mmap::release and fixes a couple of spots to comply. gdb/ChangeLog 2019-03-05 Tom Tromey <tromey@adacore.com> * nat/linux-btrace.c (linux_enable_bts, linux_enable_pt): Update. * common/scoped_mmap.h (class scoped_mmap) <release>: Add ATTRIBUTE_UNUSED_RESULT.
2019-03-05Add ATTRIBUTE_UNUSED_RESULT to scoped_fdTom Tromey1-0/+5
This applies ATTRIBUTE_UNUSED_RESULT to scoped_fd::release. gdb/ChangeLog 2019-03-05 Tom Tromey <tromey@adacore.com> * common/scoped_fd.h (class scoped_fd) <release>: Add ATTRIBUTE_UNUSED_RESULT.
2019-03-05Add ATTRIBUTE_UNUSED_RESULT to parser_stateTom Tromey1-0/+5
This applies ATTRIBUTE_UNUSED_RESULT to parser_state::release. gdb/ChangeLog 2019-03-05 Tom Tromey <tromey@adacore.com> * parser-defs.h (struct parser_state) <release>: Add ATTRIBUTE_UNUSED_RESULT.
2019-03-05Introduce ATTRIBUTE_UNUSED_RESULT and use itTom Tromey1-0/+6
This introduces the new ATTRIBUTE_UNUSED_RESULT define, and applies it to gdb_argv::release. gdb/ChangeLog 2019-03-05 Tom Tromey <tromey@adacore.com> * utils.h (class gdb_argv) <release>: Add ATTRIBUTE_UNUSED_RESULT. * common/common-defs.h (ATTRIBUTE_UNUSED_RESULT): Define.
2019-03-02Avoid compilation warnings on MinGW.Eli Zaretskii1-0/+6
gdb/ChangeLog: 2019-03-02 Eli Zaretskii <eliz@gnu.org> * xml-syscall.c (xml_list_syscalls_by_group): Drop 'struct' from for-loop range, to avoid compiler warnings. * tui/tui.c (tui_enable) [__MINGW32__]: Don't declare 'cap', to avoid compiler warnings about unused variables.
2019-03-02GDB no longer supports Windows before XP.Eli Zaretskii1-0/+3
gdb/ChangeLog: 2019-03-02 Eli Zaretskii <eliz@gnu.org> * NEWS: Mention end of support for native debugging on MS-Windows before XP.
2019-03-02Fix GDB compilation on MinGW (PR gdb/24292)Eli Zaretskii1-0/+14
gdb/ChangeLog: 2019-03-02 Eli Zaretskii <eliz@gnu.org> PR gdb/24292 * common/netstuff.c: * gdbserver/gdbreplay.c * gdbserver/remote-utils.c: * ser-tcp.c: * unittests/parse-connection-spec-selftests.c [USE_WIN32API]: Include ws2tcpip.h instead of wsiapi.h and winsock2.h. Redefine _WIN32_WINNT to 0x0501 if defined to a smaller value, as 'getaddrinfo' and 'freeaddrinfo' were not available before Windows XP, and mingw.org's MinGW headers by default define _WIN32_WINNT to 0x500.
2019-03-01Fix coff_start_symtab resource leak found by CoverityGary Benson1-0/+4
This commit fixes a resource leak found by Coverity, where coff_start_symtab performs an xstrdup that is now performed within start_symtab by buildsym_compunit::buildsym_compunit. gdb/ChangeLog: * coffread.c (coff_start_symtab): Remove unnecessary xstrdup.
2019-02-28Can't interrupt process without controlling terminal on Solaris (PR gdb/8527)Rainer Orth1-0/+7
If gdb attaches to a process that either has no controlling terminal, or the controlling terminal differs from the one gdb is running under, break/^C doesn't interrupt the debugged process on Solaris. Fixed as follows, analogous to what all all other targets do. Patch from the PR, recently re-submitted by Brian Vandenberg. Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. 2019-02-28 Brian Vandenberg <phantall@gmail.com> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> gdb: PR gdb/8527 * procfs.c (proc_wait_for_stop): Wrap write of PCWSTOP in set_sigint_trap, clear_sigint_trap. gdb/testsuite: PR gdb/8527 * gdb.base/interrupt-daemon-attach.c, gdb.base/interrupt-daemon-attach.exp: New test.
2019-02-27Fix regcache leak, and avoid possible regcache access after detach.Philippe Waroquiers1-1/+6
Valgrind reports leaks like the below in various tests, e.g. gdb.threads/attach-slow-waitpid.exp, gdb.ada/task_switch_in_core.exp, ... Fix the leak by clearing the regcache when detaching from an inferior. Note that these leaks are 'created' when GDB exits, when the regcache::current_regcache is destroyed : the elements of the forward_list are pointers, and the 'pointed to' memory is not deleted by the forward_list destructor. Nevertheless, fixing this leak is good as it makes a bunch of tests 'leak clean'. Also, it seems strange to keep a register cache for a process from which GDB detached : it is not clear if this cache is still valid after detach. And effectively, when clearing only the regcache, (and not the frame cache), then the frame cache was still 'pointing' at this regcache and was used when switching to the child process in the test gdb.threads/watchpoint-fork.exp, which seems strange. So, we solve the leak and avoid possible accesses to the regcache and frame cache of the detached inferior, by clearing both the regcache and the frame cache. Tested on debian/amd64, natively, under Valgrind, and with make check RUNTESTFLAGS="--target_board=native-gdbserver". ==27679== VALGRIND_GDB_ERROR_BEGIN ==27679== 1,123 (72 direct, 1,051 indirect) bytes in 1 blocks are definitely lost in loss record 2,942 of 3,400 ==27679== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344) ==27679== by 0x5CDF71: get_thread_arch_aspace_regcache(ptid_t, gdbarch*, address_space*) (regcache.c:330) ==27679== by 0x5CE12A: get_thread_regcache (regcache.c:366) ==27679== by 0x5CE12A: get_current_regcache() (regcache.c:372) ==27679== by 0x4FF63D: post_create_inferior(target_ops*, int) (infcmd.c:452) ==27679== by 0x43AF62: core_target_open(char const*, int) (corelow.c:458) ==27679== by 0x408B68: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1892) ... gdb/ChangeLog 2019-02-27 Philippe Waroquiers <philippe.waroquiers@skynet.be> * target.c (target_detach): Clear the regcache and the frame cache.
2019-02-27Make 'show width/height' display "unlimited" when capped for readlinePedro Alves1-0/+5
When we cap the height/width sizes before passing to readline, tweak the corresponding command variable to show "unlimited": (gdb) set height 0x8000 (gdb) show height Number of lines gdb thinks are in a page is unlimited. Instead of the current output: (gdb) set height 0x8000 (gdb) show height Number of lines gdb thinks are in a page is 32768. gdb/ChangeLog: 2019-02-27 Pedro Alves <palves@redhat.com> * utils.c (set_screen_size): When we cap the height/width sizes, tweak the corresponding command variable to show "unlimited": gdb/testsuite/ChangeLog: 2019-02-27 Pedro Alves <palves@redhat.com> * gdb.base/page.exp: Add tests for "set/show width/height" with "infinite" values.
2019-02-27Prevent overflow in rl_set_screen_sizeSaagar Jha1-0/+6
GDB calls rl_set_screen_size in readline with the current screen size, measured in rows and columns. To represent "infinite" sizes, GDB passes in INT_MAX; however, since rl_set_screen_size internally multiplies the number of rows and columns, this causes a signed integer overflow. To prevent this we can instead pass in the approximate square root of INT_MAX (which is still reasonably large), so that even when the number of rows and columns is "infinite" we don't overflow. gdb/ChangeLog: 2019-02-27 Saagar Jha <saagar@saagarjha.com> Pedro Alves <palves@redhat.com> * utils.c (set_screen_size): Reduce "infinite" rows and columns before calling rl_set_screen_size.
2019-02-27Remove Python 2.4 and 2.5 supportTom Tromey1-0/+25
This removes all the remainings spots I could find that work around issues in Python 2.4 and 2.5. I don't have a good way to test that Python 2.6 still works. Tested by the buildbot. gdb/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * config.in, configure: Rebuild. * configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never define. * python/py-value.c: Remove Python 2.4 workaround. * python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4 workaround. * python/py-type.c (convert_field, gdbpy_initialize_types): Remove Python 2.4 workaround. * python/python-internal.h: Remove Python 2.4 comment. (Py_ssize_t): Don't define. (PyVarObject_HEAD_INIT, Py_TYPE): Don't define. (gdb_Py_DECREF): Remove Python 2.4 workaround. (gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove. (gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove. * python/python.c (do_start_initialization): Remove Python 2.4 workaround. * python/py-prettyprint.c (class dummy_python_frame): Remove. (print_children): Remove Python 2.4 workaround. * python/py-inferior.c (buffer_procs): Remove Python 2.4 workaround. (CHARBUFFERPROC_NAME): Remove. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove Python 2.4 workaround. gdb/testsuite/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * lib/gdb.exp (skip_python_tests_prompt): Don't check for Python 2.4. * gdb.python/py-finish-breakpoint.exp: Remove Python 2.4 workaround. gdb/ChangeLog 2019-02-27 Tom Tromey <tromey@adacore.com> * config.in, configure: Rebuild. * configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never define. * python/py-value.c: Remove Python 2.4 workaround. * python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4 workaround. * python/py-type.c (convert_field, gdbpy_initialize_types): Remove Python 2.4 workaround. * python/python-internal.h: Remove Python 2.4 comment. (Py_ssize_t): Don't define. (PyVarObject_HEAD_INIT, Py_TYPE): Don't define. (gdb_Py_DECREF): Remove Python 2.4 workaround. (gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove. (gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove. * python/python.c (do_start_initialization): Remove Python 2.4 workaround. * python/py-prettyprint.c (class dummy_python_frame): Remove. (print_children): Remove Python 2.4 workaround. * python/py-inferior.c (buffer_procs): Remove Python 2.4 workaround. (CHARBUFFERPROC_NAME): Remove. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove Python 2.4 workaround.
2019-02-27Document fact that mininum Python version is now 2.6Kevin Buettner1-0/+4
gdb/ChangeLog: * NEWS: Note minimum Python version. gdb/doc/ChangeLog: * gdb.texinfo (Configure Options): Document minimum python version.
2019-02-27Use Python 2.[67] / 3.X / PEP 3118 buffer protocolKevin Buettner1-0/+8
This patch removes the non-IS_PY3K code in infpy_write_memory() and infpy_search_memory(). In both cases, the remaining code from these ifdefs is related to use of the PEP 3118 buffer protocol. (Deleted code is either due to simplification or related to use of the old buffer protocol.) PEP 3118 is sometimes referred to as the "new" buffer protocol, though it's not that new anymore. The link below describes new features in Python 2.6. In particular, it says that the buffer protocol described by PEP 3118 is in Python 2.6. It also says (at the top of the page) that Python 2.6 was released on Oct 1, 2008. https://docs.python.org/3/whatsnew/2.6.html#pep-3118-revised-buffer-protocol The last security release for the Python 2.6 series was 2.6.9. It was released on Oct 29, 2013. According to this document... https://www.python.org/download/releases/2.6.9/ ...support for the 2.6 series has ended: With the 2.6.9 release, and five years after its first release, the Python 2.6 series is now officially retired. All official maintenance for Python 2.6, including security patches, has ended. For ongoing maintenance releases, please see the Python 2.7 series. As noted earlier, Python 2.6, Python 2.7, and Python 3.X all have support for the PEP 3118 buffer protocol. Python releases prior to 2.6 use an older buffer protocol. Since Python 2.6 has been retired for a good while now, it seems reasonable to me to remove code using the older buffer protocol from GDB. I have also simplified some of the code via use of the Py_buffer unique_ptr specialization which I introduced in the two argument gdb.Value constructor patch series. Therefore, there is a dependency on patch #1 from that series. I have tested against both Python 2.7.15 and 3.7.2. I see no regressions among the non-racy tests. I've also verified that PyBuffer_Release is being called when the affected functions exit while running the tests in gdb.python/py-inferior.exp by hand. I've also tried running valgrind on GDB while running this test, but I'm puzzled by the results that I'm seeing - I'm seeing no additional leaks when I comment out the Py_buffer_up lines that I introduced. That said, I'm not seeing any leaks that obviously originate from either infpy_write_memory() or infpy_search_memory(). gdb/ChangeLog: * python/py-inferior.c (infpy_write_memory): Remove non-IS_PY3K code from these functions. Remove corresponding ifdefs. Use Py_buffer_up instead of explicit calls to PyBuffer_Release. Remove gotos and target of gotos. (infpy_search_memory): Likewise.
2019-02-27gdb/hppa: Use default gdbarch method default_dummy_id.Andrew Burgess1-0/+6
Make use of the default gdbarch method for gdbarch_dummy_id. I have not tested this change but, by inspecting the code, I believe the default method is equivalent to the code being deleted. gdb/ChangeLog: * gdb/hppa-tdep.c (hppa_dummy_id): Delete. (hppa_gdbarch_init): Don't register deleted functions with gdbarch.
2019-02-27gdb/h8300: Use default gdbarch methods where possibleAndrew Burgess1-0/+8
Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * gdb/h8300-tdep.c (h8300_unwind_pc): Delete. (h8300_unwind_sp): Delete. (h8300_dummy_id): Delete. (h8300_gdbarch_init): Don't register deleted functions with gdbarch.
2019-02-27gdb/ft32: Use default gdbarch methods where possibleAndrew Burgess1-0/+8
Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * gdb/ft32-tdep.c (ft32_dummy_id): Delete. (ft32_unwind_pc): Delete. (ft32_unwind_sp): Delete. (ft32_gdbarch_init): Don't register deleted functions with gdbarch.
2019-02-27gdb/frv: Use default gdbarch methods where possibleAndrew Burgess1-0/+8
Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * gdb/frv-tdep.c (frv_dummy_id): Delete. (frv_unwind_pc): Delete. (frv_unwind_sp): Delete. (frv_gdbarch_init): Don't register deleted functions with gdbarch.
2019-02-27gdb/riscv: Use default gdbarch methods where possibleAndrew Burgess1-0/+8
Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. This change has been tested with no regressions. gdb/ChangeLog: * gdb/riscv-tdep.c (riscv_dummy_id): Delete. (riscv_unwind_pc): Delete. (riscv_unwind_sp): Delete. (riscv_gdbarch_init): Don't register deleted functions with gdbarch.
2019-02-27gdb/csky: Use default gdbarch methods where possibleAndrew Burgess1-0/+8
Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * gdb/csky-tdep.c (csky_dummy_id): Delete. (csky_unwind_pc): Delete. (csky_unwind_sp): Delete. (csky_gdbarch_init): Don't register deleted functions with gdbarch.
2019-02-27gdb/cris: Use default gdbarch methods where possibleAndrew Burgess1-0/+8
Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * gdb/cris-tdep.c (cris_dummy_id): Delete. (cris_unwind_pc): Delete. (cris_unwind_sp): Delete. (cris_gdbarch_init): Don't register deleted functions with gdbarch.
2019-02-27gdb/bfin: Use default gdbarch methods where possibleAndrew Burgess1-0/+6
Make use of the default gdbarch methods for gdbarch_dummy_id, and gdbarch_unwind_pc. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * gdb/bfin-tdep.c (bfin_dummy_id): Delete. (bfin_unwind_pc): Delete. (bfin_gdbarch_init): Don't register deleted functions with gdbarch.
2019-02-27gdb/arm: Use default gdbarch methods where possibleAndrew Burgess1-0/+7
Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * gdb/arm-tdep.c (arm_dummy_id): Delete. (arm_unwind_pc): Delete. (arm_unwind_sp): Delete. (arm_gdbarch_init): Don't register deleted functions with gdbarch.
2019-02-27gdb/arc: Use default gdbarch methods where possibleAndrew Burgess1-0/+7
Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. The only difference is that the old ARC specific methods had additional debugging, however, this was discussed on the mailing list[1] and it was agreed these methods could be removed. [1] https://sourceware.org/ml/gdb-patches/2018-12/msg00386.html gdb/ChangeLog: * gdb/arc-tdep.c (arc_dummy_id): Delete. (arc_unwind_pc): Delete. (arc_unwind_sp): Delete. (arc_gdbarch_init): Don't register deleted functions with gdbarch.
2019-02-27gdb/alpha: Use default gdbarch methods where possibleAndrew Burgess1-0/+7
Make use of the default gdbarch methods for gdbarch_dummy_id, and gdbarch_unwind_pc. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * gdb/alpha-tdep.c (alpha_dummy_id): Delete. (alpha_unwind_pc): Delete. (alpha_gdbarch_init): Don't register deleted functions with gdbarch.
2019-02-27gdb/aarch64: Use default gdbarch methods where possibleAndrew Burgess1-0/+8
Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * gdb/aarch64-tdep.c (aarch64_dummy_id): Delete. (aarch64_unwind_pc): Delete. (aarch64_unwind_sp): Delete. (aarch64_gdbarch_init): Don't register deleted functions with gdbarch.
2019-02-27gdb: Handle alignment for C++ structures with static membersAndrew Burgess1-0/+5
In 'type_align' when computing the alignment of a structure we should not consider the alignment of static structure members, these are usually stored outside of the structure and therefore don't have any impact on the structures alignment requirements. I've extended the existing alignment calculating test to compile in both C and C++ now so that we can create structures with static members. gdb/ChangeLog: * gdbtypes.c (type_align): Don't consider static members when computing structure alignment. gdb/testsuite/ChangeLog: * gdb.base/align.exp: Extend to compile in both C and C++, and add tests for structs with static members.
2019-02-27gdb: Restructure type_align and gdbarch_type_alignAndrew Burgess1-0/+14
This commit restructures the relationship between the type_align function and the gdbarch_type_align method. The problem being addressed with this commit is this; previously the type_align function was structured so that for "basic" types (int, float, etc) the gdbarch_type_align hook was called, which for "compound" types (arrays, structs, etc) the common type_align code has a fixed method for how to extract a "basic" type and would then call itself on that "basic" type. The problem is that if an architecture wants to modify the alignment rules for a "compound" type then this is not currently possible. In the revised structure, all types pass through the gdbarch_type_align method. If this method returns 0 then this indicates that the architecture has no special rules for this type, and GDB should apply the default rules for alignment. However, the architecture is free to provide an alignment for any type, both "basic" and "compound". After this commit the default alignment rules now all live in the type_align function, the default_type_align only ever returns 0, meaning apply the default rules. I've updated the 3 targets (arc, i386, and nios2) that already override the gdbarch_type_align method to fit the new scheme. Tested on X86-64/GNU Linux with no regressions. gdb/ChangeLog: * arc-tdep.c (arc_type_align): Provide alignment for basic types, return 0 for other types. * arch-utils.c (default_type_align): Always return 0. * gdbarch.h: Regenerate. * gdbarch.sh (type_align): Extend comment. * gdbtypes.c (type_align): Add additional comments, always call gdbarch_type_align before applying the default rules. * i386-tdep.c (i386_type_align): Return 0 as the default rule, generic code will then apply a suitable default. * nios2-tdep.c (nios2_type_align): Provide alignment for basic types, return 0 for other types.
2019-02-27Update NEWS post GDB 8.3 branch creation.Joel Brobecker1-0/+6
gdb/ChangeLog: * NEWS: Create a new section for the next release branch. Rename the section of the current branch, now that it has been cut.
2019-02-27Bump version to 8.3.50.DATE-git.Joel Brobecker1-0/+5
Now that the GDB 8.3 branch has been created, we can bump the version number. gdb/ChangeLog: GDB 8.3 branch created (143420fb0d5ae54323ba9953f0818c194635228d): * version.in: Bump version to 8.3.50.DATE-git.
2019-02-26Fix build errors in aix-thread.cgdb-8.3-branchpointSimon Marchi1-0/+8
This patch fixes a few instances of unused variable and shadowed local variable errors. gdb/ChangeLog: * aix-thread.c (ptid_cmp): Remove unused variable. (get_signaled_thread): Likewise. (store_regs_user_thread): Likewise. (store_regs_kernel_thread): Likewise. (fetch_regs_kernel_thread): Remove shadowed variable.
2019-02-26gdb/riscv: Use legacy register numbers in default target descriptionAndrew Burgess1-0/+9
When the target description support was added to RISC-V, the register numbers assigned to the fflags, frm, and fcsr control registers in the default target descriptions didn't match the register numbers used by GDB before the target description support was added. What this means is that if a tools exists in the wild that is using hard-coded register number, setup to match GDB's old numbering, then this will have been broken (for fflags, frm, and fcsr) by the move to target descriptions. QEMU is such a tool. There are a couple of solutions that could be used to work around this issue: - The user can create their own xml description file with the register numbers setup to match their old tool, then load this by telling GDB 'set tdesc filename FILENAME'. - Update their old tool to use the newer default numbering scheme, or better yet add proper target description support to their tool. - We could have RISC-V GDB change to maintain the old defaults. This patch changes GDB back to using the old numbering scheme. This change is only visible to remote targets that don't supply their own xml description file and instead rely on GDB's default numbering. Note that even though 32bit-cpu.xml and 64bit-cpu.xml have changed, the corresponding .c file has not, this is because the numbering added to the registers in the xml files is number 0, this doesn't result in any new C code being generated . gdb/ChangeLog: * features/riscv/32bit-cpu.xml: Add register numbers. * features/riscv/32bit-fpu.c: Regenerate. * features/riscv/32bit-fpu.xml: Add register numbers. * features/riscv/64bit-cpu.xml: Add register numbers. * features/riscv/64bit-fpu.c: Regenerate. * features/riscv/64bit-fpu.xml: Add register numbers.
2019-02-26Document two argument form of gdb.Value constructorKevin Buettner1-0/+1
gdb/ChangeLog: * NEWS: Mention two argument form of gdb.Value constructor. gdb/doc/ChangeLog: * python.texi (Values From Inferior): Document second form of Value.__init__.
2019-02-26Define gdb.Value(bufobj, type) constructorKevin Buettner1-0/+5
Provided a buffer BUFOBJ and a type TYPE, construct a gdb.Value object with type TYPE, where the value's contents are taken from BUFOBJ. E.g... (gdb) python import struct (gdb) python unsigned_int_type=gdb.lookup_type('unsigned int') (gdb) python b=struct.pack('=I',0xdeadbeef) (gdb) python v=gdb.Value(b, unsigned_int_type) ; print("%#x" % v) 0xdeadbeef This two argument form of the gdb.Value constructor may also be used to obtain gdb values from selected portions of buffers read with Inferior.read_memory(). The test case (which is in a separate patch) demonstrates this use case. gdb/ChangeLog: * python/py-value.c (convert_buffer_and_type_to_value): New function. (valpy_new): Parse arguments via gdb_PyArg_ParseTupleAndKeywords. Add support for handling an optional second argument. Call convert_buffer_and_type_to_value as appropriate.
2019-02-26Define unique_ptr specialization for Py_buffer.Kevin Buettner1-0/+5
This patch causes PyBuffer_Release() to be called when the associated buffer goes out of scope. I've been using it as follows: ... Py_buffer_up buffer_up; Py_buffer py_buf; if (PyObject_CheckBuffer (obj) && PyObject_GetBuffer (obj, &py_buf, PyBUF_SIMPLE) == 0) { /* Got a buffer, py_buf, out of obj. Cause it to released when it goes out of scope. */ buffer_up.reset (&py_buf); } ... This snippet of code was taken directly from an upcoming patch to python-value.c. gdb/ChangeLog: * python/python-internal.h (Py_buffer_deleter): New struct. (Py_buffer_up): New typedef.
2019-02-25Fix BFD leak in dwarf2_get_dwz_file.John Baldwin1-0/+5
Previously if build_id_verify failed, dwz_bfd was cleared to NULL via release(), but the BFD object was not destroyed. Use reset() with nullptr instead to delete the BFD. gdb/ChangeLog: * dwarf2read.c (dwarf2_get_dwz_file): Reset dwz_bfd to nullptr instead of releasing ownership.
2019-02-25Fix crash when loading dwp filesJordan Rupprecht1-0/+6
When loading dwp files, we create an array of ELF sections indexed by the ELF section index in the dwp file. The size of this array is calculated by section_count, as returned by bfd_count_sections, plus 1 (to account for the null section at index 0). However, when loading the bfd file, strtab/symtab sections are not added to the list, nor do they increment section_count, so section_count is actually smaller than the number of ELF sections. This happens to work when using GNU dwp, which lays out .debug section first, with sections like .shstrtab coming at the end. Other tools, like llvm-dwp, put .strtab first, and gdb crashes when loading those dwp files. For instance, with the current state of gdb, loading a file like this: $ readelf -SW <file.dwp> [ 0] <empty> [ 1] .debug_foo PROGBITS ... [ 2] .strtab STRTAB ... ... results in section_count = 2 (.debug is the only thing placed into bfd->sections, so section_count + 1 == 2), and sectp->this_idx = 1 when mapping over .debug_foo in dwarf2_locate_common_dwp_sections, which passes the assertion that 1 < 2. However, using a dwp file produced by llvm-dwp: $ readelf -SW <file.dwp> [ 0] <empty> [ 1] .strtab STRTAB ... [ 2] .debug_foo PROGBITS ... ... results in section_count = 2 (.debug is the only thing placed into bfd->sections, so section_count + 1 == 2), and sectp->this_idx = 2 when mapping over .debug_foo in dwarf2_locate_common_dwp_sections, which fails the assertion that 2 < 2. The assertion hit is: gdb/dwarf2read.c:13009: internal-error: void dwarf2_locate_common_dwp_sections(bfd*, asection*, void*): Assertion `elf_section_nr < dwp_file->num_sections' failed. This patch changes the calculation of section_count to use elf_numsections, which should return the actual number of ELF sections.
2019-02-25Fix BFD leak in solib-darwin.cTom Tromey1-0/+4
commit 192b62ce0b4bb5c61188f570e127a26d2c32f716 ("Use class to manage BFD reference counts") changed darwin_get_dyld_bfd to use: + dyld_bfd.release (); rather than - do_cleanups (cleanup); However, using release here leaks the BFD. Instead, simply assigning "sub" to "dyld_bfd" achieves what was meant. gdb/ChangeLog 2019-02-25 Tom Tromey <tromey@adacore.com> * solib-darwin.c (darwin_get_dyld_bfd): Don't release dyld_bfd.
2019-02-23Use '--readnever' when invoking GDB from gcore.inSergio Durigan Junior1-0/+4
Back when I proposed the '--readnever' feature, I somehow forgot or decided not to include the bits related to gcore.in in the original patch. This patch finally updates the gcore script to invoke GDB using '--readnever'. We've been carrying this patch on Fedora GDB for quite some time, and as expected the corefiles generated by gcore on Fedora don't have problems, which I think is the best indicator that the it's safe to generate corefiles using '--readnever'. gdb/ChangeLog: 2019-02-23 Sergio Durigan Junior <sergiodj@redhat.com> * gcore.in: Add '--readnever' option when invoking GDB.
2019-02-22Update my email addressSimon Marchi1-0/+4
Since this is my last day at Ericsson, I am changing my email for my personal one in the MAINTAINERS file.
2019-02-22Look for build-id-based separate debug files under the sysrootSimon Marchi1-0/+6
When looking for a separate debug file that matches a given build-id, GDB only looks in the host's debug dir (typically /usr/lib/debug). This patch makes it look in the sysroot as well. This is to match the behavior of GDB when using debuglink-based separate debug files, introduced in : 402d2bfec42 ("Look for separate debug files in debug directories under a sysroot.") In the following example, my sysroot is "/tmp/sysroot" and I am trying to load symbols for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so. This is the current behavior: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path <snip> (No debugging symbols found in /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so) With this patch: (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so... Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path Trying /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... yes! Reading symbols from /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... In the original code, there is a suspicious "abfd.release ()" in build_id_to_debug_bfd, that I don't understand. If a file with the right name exists but its build-id note doesn't match, we release (leak) our reference, meaning the file will stay open? I removed it in the new code, so that the reference is dropped if we end up not using that file. I tested briefly by corrupting a separate debug file to trigger this code, nothing exploded. gdb/ChangeLog: * build-id.c (build_id_to_debug_bfd_1): New function. (build_id_to_debug_bfd): Look for separate debug file in sysroot.
2019-02-22gdb: Update copyright year range generated by gdbarch.shAndrew Burgess1-0/+5
The copyright year that gdbarch.sh places into the generated files gdbarch.{c,h} wasn't updated at the start of the year. After this commit the gdbarch.{c,h} files regenerate as the currently are in the tree. gdb/ChangeLog: * gdbarch.sh: Update the copyright year range that is placed into generated files.
2019-02-22Add missing ChangeLog entries for commit ↵Keith Seitz1-0/+6
bb995d00b3eef2f48d0be895c3509a7ddd8280a1
2019-02-21Document style behavior in batch mode.Alan Hayward1-0/+4
Style is disabled when running in batch mode. gdb/ChangeLog: * NEWS: Update style defaults. gdb/doc/ChangeLog: * gdb.texinfo: Update style defaults.
generated by cgit v1.1 at 2025-03-10 05:37:05 +0000