Nick Clifton [Mon, 7 Jan 2019 13:18:53 +0000 (13:18 +0000)]
Sync libiberty sources with master version in gcc repository. Updated stabs demangling and cxxfilt tests to match.
PR 24044
* stabs.c (parse_stab_argtypes): Remove call to
cplus_mangle_opcode.
* testsuite/binutils-all/cxxfilt.exp: Replace tests of v2 encoding
with v3 encoding. Add escape for known failures.
Kyrylo Tkachov [Mon, 7 Jan 2019 09:22:55 +0000 (09:22 +0000)]
[arm][gas] Add -mcpu support for Arm Ares
This adds support for the Arm Ares CPU in the arm port.
It implements the Armv8.2-A architecture with the relevant optional
features
of dot product and FP16 on by default.
Note: Ares is a codename to enable early adopters and in time
we will add the final product name once it's announced.
Tom Tromey [Thu, 3 Jan 2019 02:12:32 +0000 (19:12 -0700)]
Use std::vector in type stacks
This removes the use of VEC from parse.c and, at the same time,
removes some related cleanups from c-exp.y.
gdb/ChangeLog
2019-01-06 Tom Tromey <tom@tromey.com>
* parser-defs.h (type_ptr): Remove typedef. Don't declare VEC.
(union type_stack_elt) <typelist_val>: Now a pointer to
std::vector.
(type_stack_cleanup): Don't declare.
(push_typelist): Update.
* parse.c (pop_typelist): Return a std::vector.
(push_typelist): Take a std::vector.
(follow_types): Update. Do not free args.
(type_stack_cleanup): Remove.
* c-exp.y (struct c_parse_state): New.
(cpstate): New global.
(type_aggregate_p, exp, ptr_operator, parameter_typelist)
(nonempty_typelist): Update.
(func_mod): Create a new vector.
(c_parse): Create a c_parse_state.
(check_parameter_typelist): Do not delete params.
(function_method): Update. Do not delete type_list.
Tom Tromey [Sat, 29 Dec 2018 17:46:07 +0000 (10:46 -0700)]
Fix crash in "finish"
PR gdb/28155 notes a crash in "finish" that occurs with a particular
source file compiled by clang.
The bug is the typical gdb problem of a missing call to check_typedef.
clang emits a function whose return type is a typedef to void.
get_return_value asserts that the return type is not void, but the
callers were not using check_typedef first.
gdb/ChangeLog
2019-01-06 Tom Tromey <tom@tromey.com>
PR gdb/28155:
* python/py-finishbreakpoint.c (bpfinishpy_init): Use
check_typedef.
* infcmd.c (finish_command_fsm_should_stop): Use check_typedef.
(print_return_value): Likewise.
gdb/testsuite/ChangeLog
2019-01-06 Tom Tromey <tom@tromey.com>
PR gdb/28155:
* gdb.dwarf2/typedef-void-finish.exp: New file.
Tom Tromey [Mon, 24 Dec 2018 21:56:03 +0000 (14:56 -0700)]
Remove the exception and cleanup checkers
Now that gdb is transitioning away from cleanups, there is no reason
to keep the cleanup and exception checker scripts around. This patch
removes them.
gdb/ChangeLog
2019-01-05 Tom Tromey <tom@tromey.com>
Joel Brobecker [Sat, 5 Jan 2019 07:55:08 +0000 (11:55 +0400)]
GDB crash re-running program on Windows (native)
Running any program twice on Windows current results in GDB crashing:
$ gdb -q any_program
(gdb) run
$ gdb dummy -batch -ex run -ex run
[New Thread 684960.0xe5878]
[New Thread 684960.0xd75ac]
[New Thread 684960.0xddac8]
[New Thread 684960.0xc1f50]
[Thread 684960.0xd75ac exited with code 0]
[Thread 684960.0xddac8 exited with code 0]
[Thread 684960.0xc1f50 exited with code 0]
[Inferior 1 (process 684960) exited normally]
(gdb) run
Segmentation fault
The crash happens while processing the CREATE_PROCESS_DEBUG_EVENT
for the second run; in particular, we have in get_windows_debug_event:
| case CREATE_PROCESS_DEBUG_EVENT:
| [...]
| if (main_thread_id)
| windows_delete_thread (ptid_t (current_event.dwProcessId, 0,
| main_thread_id),
| 0);
The problem is that main_thread_id is the TID of the main thread from
the *previous* inferior, and this code is trying to delete that
thread. The problem is that it is constructing a PTID by pairing
the TID of the previous inferior with the PID of the new inferior.
As a result, when we dig inside windows_delete_thread to see
how it would handle that, we see...
| delete_thread (find_thread_ptid (ptid));
Since the PTID is bogus, we end up calling delete_thread with
a NULL thread_info. It used to be harmless, turning the delete_thread
into a nop, but the following change...
| commit 080363310650c93ad8e93018bcb6760ba5d32d1c
| Date: Thu Nov 22 16:09:14 2018 +0000
| Subject: Per-inferior thread list, thread ranges/iterators, down with ALL_THREADS, etc.
... changed delete_thread to get the list of threads from
the inferior, which itself is now accessed via the given
thread_info. This is the corresponding diff that shows the change:
As a result of this, passing a NULL thread_info is no longer
an option!
Stepping back a bit, the reason behind deleting the thread late
could be found in a patch from Dec 2003, which laconically explains:
| commit 87a45c96062d658ca83b50aa060a648bf5f5f1ff
| Date: Fri Dec 26 00:39:04 2003 +0000
|
| * win32-nat.c (get_child_debug_event): Keep main thread id around
| even after thread exits since Windows insists on continuing to
| report events against it.
A look at the gdb-patches archives did not provide any additional
clues (https://www.sourceware.org/ml/gdb-patches/2003-12/msg00478.html).
It is not clear whether this is still needed or not. This patch
assumes that whatever isue there was, the versions of Windows
we currently support no longer have it.
With that in mind, this commit fixes the issue by deleting the thread
when the inferior sends the exit-process event as opposed to deleting it
later, while starting a new inferior.
This also restores the printing of the thread-exit notification for
the main thread, which was missing before. Looking at the transcript
of the example shown above, we can see 4 thread creation notifications,
and only 3 notifications for thread exits. Now creation and exit
notifications are balanced.
In the handling of EXIT_THREAD_DEBUG_EVENT, the main_thread_id
check is removed because deemed unnecessary: The main thread was
introduced by a CREATE_PROCESS_DEBUG_EVENT, and thus the kernel
is expected to report its death via EXIT_PROCESS_DEBUG_EVENT.
And finally, because the behavior of delete_thread did change
(albeit when getting a value we probably never expected to receive),
this patch also adds a gdb_assert. The purpose is to provide some
immediate information in case there are other callers that mistakenly
call delete_thread with a NULL thread info. This can be useful
information when direct debugging of GDB isn't an option.
gdb/ChangeLog:
* thread.c (delete_thread_1): Add gdb_assert that THR is not
NULL. Initialize tpprev to NULL instead of assigning it
to NULL on the next statement.
* windows-nat.c (windows_delete_thread): Remove check for
main_thread_id before printing thread exit notifications.
(get_windows_debug_event) <EXIT_THREAD_DEBUG_EVENT>:
Remove thread ID check against main_thread_id.
<CREATE_PROCESS_DEBUG_EVENT>: Remove call to
windows_delete_thread.
<EXIT_PROCESS_DEBUG_EVENT>: Add call to windows_delete_thread.
Tom Tromey [Mon, 24 Dec 2018 21:41:40 +0000 (14:41 -0700)]
Use upper case for more metasyntactic variables in gdb
I noticed a few places where a Usage line in gdb did not use upper
case for metasyntactic variables. This patch fixes all the instances
I found.
Tested on x86-64 Fedora 28.
gdb/ChangeLog
2019-01-04 Tom Tromey <tom@tromey.com>
* compile/compile.c (_initialize_compile): Use upper case for
metasyntactic variables.
* symmisc.c (_initialize_symmisc): Use upper case for
metasyntactic variables.
* psymtab.c (_initialize_psymtab): Use upper case for
metasyntactic variables.
* demangle.c (demangle_command): Use upper case for metasyntactic
variables.
(_initialize_demangler): Likewise.
* ax-gdb.c (_initialize_ax_gdb): Use upper case for metasyntactic
variables.
Nick Clifton [Fri, 4 Jan 2019 12:11:51 +0000 (12:11 +0000)]
Fix ridiculously small memory leak.
PR 24001
* objcopy.c (copy_object): Free dhandle after writing out the
debug information.
* objdump.c (dump_bfd): Free dhandle after printing out the debug
information.
Tom Tromey [Thu, 27 Dec 2018 19:16:06 +0000 (12:16 -0700)]
Avoid questionable casts in py-symtab.c
py-symtab.c has some questionable casts of Py_None to symtab_object*.
This patch avoids these casts by instead using downcasts at the
appropriate places.
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* python/py-symtab.c (salpy_str): Update.
(struct salpy_sal_object) <symtab>: Now a PyObject.
(salpy_dealloc): Update.
(del_objfile_sal): Use gdbpy_ref.
Tom Tromey [Thu, 27 Dec 2018 18:57:28 +0000 (11:57 -0700)]
Simplify gdbpy_stop_recording
This simplifies gdbpy_stop_recording, by having it use Py_RETURN_NONE
rather than writing it out manually, and by usin the idiomatic
GDB_PY_HANDLE_EXCEPTION.
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* python/py-record.c (gdbpy_stop_recording): Use Py_RETURN_NONE.
Tom Tromey [Thu, 27 Dec 2018 18:53:20 +0000 (11:53 -0700)]
Remove more uses of explicit reference counting in Python
This changes some more place in the Python code to use gdbpy_ref
rather than explicit reference counting. While doing this I found a
latent bug in typy_fields_items -- it was not checking for errors in
one spot. I also changed valpy_dealloc to use Py_XDECREF rather than
an explicit "if".
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* python/py-value.c (valpy_dealloc): Use Py_XDECREF.
* python/py-type.c (typy_fields_items): Use gdbpy_ref.
* python/py-progspace.c (pspy_set_printers): Use gdbpy_ref.
(pspy_set_frame_filters, pspy_set_frame_unwinders)
(pspy_set_type_printers): Likewise.
* python/py-function.c (fnpy_init): Use gdbpy_ref.
* python/py-cmd.c (cmdpy_init): Use gdbpy_ref.
* python/py-objfile.c (objfpy_set_printers): Use gdbpy_ref.
(objfpy_set_frame_filters, objfpy_set_frame_unwinders)
(objfpy_set_type_printers): Likewise.
Tom Tromey [Thu, 27 Dec 2018 18:32:01 +0000 (11:32 -0700)]
Use a wrapper for PyErr_Fetch
This introduces a new class that wraps PyErr_Fetch and PyErr_Restore,
and then changes all the callers in gdb to use it. This reduces the
amount of explicit reference counting that is done in the Python code.
I also found and fixed a latent bug in gdbpy_print_stack -- it was not
correctly checking some error conditions, nor clearing the exception
when needed.
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* python/python.c (gdbpy_enter, ~gdbpy_enter): Update.
(gdbpy_print_stack): Use gdbpy_err_fetch.
* python/python-internal.h (class gdbpy_err_fetch): New class.
(class gdbpy_enter) <m_error_type, m_error_value,
m_error_traceback>: Remove.
<m_error>: New member.
(gdbpy_exception_to_string): Don't declare.
* python/py-varobj.c (py_varobj_iter_next): Use gdbpy_err_fetch.
* python/py-value.c (convert_value_from_python): Use
gdbpy_err_fetch.
* python/py-utils.c (gdbpy_err_fetch::to_string): Rename from
gdbpy_exception_to_string.
(gdbpy_handle_exception): Use gdbpy_err_fetch.
* python/py-prettyprint.c (print_stack_unless_memory_error): Use
gdbpy_err_fetch.
Andrew Burgess [Mon, 31 Dec 2018 22:20:56 +0000 (22:20 +0000)]
gdb: Remove cleanup from linux_nat_target::follow_fork
Remove cleanup from linux_nat_target::follow_fork, instead add a new
unique_ptr specialisation for holding lwp_info pointers and use this
to ensure the pointer is cleaned up when needed.
gdb/ChangeLog:
* linux-nat.c (delete_lwp_cleanup): Delete.
(struct lwp_deleter): New struct.
(lwp_info_up): New typedef.
(linux_nat_target::follow_fork): Delete cleanup, and make use of
lwp_info_up.
Andrew Burgess [Mon, 31 Dec 2018 17:41:38 +0000 (17:41 +0000)]
gdb: Remove a cleanup from find_overload_match
This patch changes cp-support.c:cp_func_name to return a
'gdb::unique_xmalloc_ptr<char>' instead of a 'char *'. This allows a
cleanup to be removed from valops.c:find_overload_match.
gdb/ChangeLog:
* compile/compile-cplus-types.c
(compile_cplus_instance::decl_name): Handle changes to
cp_func_name.
* cp-support.c (cp_func_name): Update header comment, update
return type.
* cp-support.h (cp_func_name): Update return type in declaration.
* valops.c (find_overload_match): Move temp_func local to top
level of function and change its type. Use temp_func to hold and
delete temporary string obtained from cp_func_name.
Jim Wilson [Thu, 3 Jan 2019 19:12:17 +0000 (11:12 -0800)]
RISC-V: Fix wrong use of s0 register name.
s0 is listed as both an int register name and an FP register name. The FP reg
name is wrong. This looks like a simple editting error, and has an easy fix.
Tested with riscv64-linux build and check, with no regressions.
gdb/
* riscv-tdep.c (riscv_freg_feature): Drop s0 name from f8.
John Darrington [Thu, 3 Jan 2019 17:30:40 +0000 (18:30 +0100)]
S12Z: opcodes: Separate the decoding of operations from their display.
This change adds an abstraction layer between the decoding of machine
operations and their disassembled textual representation. This allows
the decoding routines to be re-used for other purposes (at the expense)
of slightly slower running time.
ChangeLog: opcodes/
* s12z-opc.c: New file.
* s12z-opc.h: New file.
* s12z-dis.c: Removed all code not directly related to display
of instructions. Used the interface provided by the new files
instead.
* Makefile.am (TARGET_LIBOPCODES_CFILES) Add s12z-opc.c.
* Makefile.in: regenerate.
* configure.ac (bfd_s12z_arch): Correct the dependencies.
* configure: regenerate.
Tom Tromey [Wed, 2 Jan 2019 15:03:13 +0000 (08:03 -0700)]
Remove a cleanup from target-descriptions.c
This removes a cleanup from target-descriptions.c, by changing it to
use a unique_ptr instead. Note that a deletion adapter is used, even
though target_desc is allocated with new, to avoid moving target_desc
to target-descriptions.h.
gdb/ChangeLog
2019-01-02 Tom Tromey <tom@tromey.com>
* xml-tdesc.c (xml_cache): Hold a target_desc_up.
(tdesc_parse_xml): Remove cleanups.
* target-descriptions.h (make_cleanup_free_target_description):
Don't declare.
(target_desc_deleter): New struct.
(target_desc_up): New typedef.
* target-descriptions.c (target_desc_deleter::operator()): Rename
from free_target_description.
(make_cleanup_free_target_description): Remove.
Tom Tromey [Wed, 2 Jan 2019 16:17:43 +0000 (09:17 -0700)]
Remove cleanups from linespec.c
This removes the remaining cleanups from linespec.c. This adds a
constructor and destructor to linespec_parser, but in a minimal way --
the parser could still benefit from a bit more C++-ification.
gdb/ChangeLog
2019-01-02 Tom Tromey <tom@tromey.com>
Tom Tromey [Wed, 2 Jan 2019 16:58:14 +0000 (09:58 -0700)]
Change inferior_to_inferior_object to return a gdbpy_ref
Most callers of inferior_to_inferior_object already use a gdbpy_ref,
so this changes inferior_to_inferior_object to return one. Doing this
revealed that create_thread_object was not correctly handling the case
where inferior_to_inferior_object failed, so this patch fixes this as
well.
gdb/ChangeLog
2019-01-02 Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 2 Jan 2019 22:31:08 +0000 (17:31 -0500)]
Place displaced step data directly in inferior structure
This patch moves the per-inferior data related to displaced stepping to
be directly in the inferior structure, rather than in a container on the
side.
On notable difference is that previously, we deleted the state on
inferior exit, which guaranteed a clean state if re-using the inferior
for a new run or attach. We now need to reset the state manually.
At the same time, I changed step_saved_copy to be a gdb::byte_vector, so
it is automatically freed on destruction (which should plug the leak
reported here [1]).
Fix leak of struct call_thread_fsm in call_function_by_hand_dummy.
When the call does not complete, the call_thread_fsm allocated
by new_call_thread_fsm is not cleaned up and deleted, which causes
the following leak e.g. in gdb.base/callfuncs.exp:
==29263== 560 bytes in 7 blocks are definitely lost in loss record 2,833 of 3,341
==29263== at 0x4C2E0BC: calloc (vg_replace_malloc.c:762)
==29263== by 0x405110: xcalloc (common-utils.c:84)
==29263== by 0x4E67EB: xcnew<call_thread_fsm> (poison.h:122)
==29263== by 0x4E67EB: new_call_thread_fsm (infcall.c:516)
==29263== by 0x4E67EB: call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) (infcall.c:1154)
==29263== by 0x4E784E: call_function_by_hand(value*, type*, gdb::array_view<value*>) (infcall.c:693)
==29263== by 0x496111: eval_call(expression*, noside, int, value**, char const*, type*) [clone .isra.5] (eval.c:835)
Fix the leak by similarly doing cleanup/destroy when restoring
previous state machine.
Tested on debian/amd64, natively and under valgrind.
2019-01-02 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* infcall.c (call_function_by_hand_dummy): cleanup/destroy sm
in case of call that did not complete.
Andrey Utkin [Fri, 9 Nov 2018 19:09:40 +0000 (19:09 +0000)]
Fix search of debug files for remote debuggee
When using remote debugging server, and when debuggee filename is
inferred via qXfer:exec-file:read request, or sysroot starts with
"target:", this "target:" prefix of filepaths is not treated correctly
during debug file search - it appears in the middle of the looked up
paths.
In the following example, unpatched GDB can't find separate debug files for
neither the executable, nor standard libraries:
$ gdb -ex 'set debug separate-debug-file 1' -ex 'set sysroot target:/' -ex 'set debug-file-directory /usr/lib/debug:/home/j/hide' -ex 'target remote :3333' -ex 'break main' -ex 'continue' -ex 'bt' -ex 'info sharedlibrary' -ex 'set confirm off' -ex 'quit'
GNU gdb (Gentoo 9999 vanilla) 8.2.50.20181109-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using :3333
Reading /home/j/test from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /home/j/test from remote target...
Reading symbols from target:/home/j/test...
Looking for separate debug info (debug link) for target:/home/j/test
Trying target:/home/j/test.debug
Reading /home/j/test.debug from remote target...
Trying target:/home/j/.debug/test.debug
Reading /home/j/.debug/test.debug from remote target...
Trying /usr/lib/debug/target:/home/j/test.debug
Trying /home/j/hide/target:/home/j/test.debug
(No debugging symbols found in target:/home/j/test)
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Looking for separate debug info (debug link) for target:/lib64/ld-linux-x86-64.so.2
Trying target:/lib64/ld-2.27.so.debug
Reading /lib64/ld-2.27.so.debug from remote target...
Trying target:/lib64/.debug/ld-2.27.so.debug
Reading /lib64/.debug/ld-2.27.so.debug from remote target...
Trying /usr/lib/debug/target:/lib64/ld-2.27.so.debug
Trying /home/j/hide/target:/lib64/ld-2.27.so.debug
(No debugging symbols found in target:/lib64/ld-linux-x86-64.so.2)
Looking for separate debug info (build-id) for system-supplied DSO at 0x7ffff7ffa000
Trying /usr/lib/debug/.build-id/fd/03d584bc1a90ba28be457635a02662c9f9c1f2.debug
Trying /home/j/hide/.build-id/fd/03d584bc1a90ba28be457635a02662c9f9c1f2.debug
0x00007ffff7dd7000 in ?? () from target:/lib64/ld-linux-x86-64.so.2
Breakpoint 1 at 0x4005eb
Continuing.
Reading /lib64/libpthread.so.0 from remote target...
Reading /lib64/libc.so.6 from remote target...
Looking for separate debug info (debug link) for target:/lib64/libpthread.so.0
Trying target:/lib64/libpthread-2.27.so.debug
Reading /lib64/libpthread-2.27.so.debug from remote target...
Trying target:/lib64/.debug/libpthread-2.27.so.debug
Reading /lib64/.debug/libpthread-2.27.so.debug from remote target...
Trying /usr/lib/debug/target:/lib64/libpthread-2.27.so.debug
Trying /home/j/hide/target:/lib64/libpthread-2.27.so.debug
Looking for separate debug info (debug link) for target:/lib64/libc.so.6
Trying target:/lib64/libc-2.27.so.debug
Reading /lib64/libc-2.27.so.debug from remote target...
Trying target:/lib64/.debug/libc-2.27.so.debug
Reading /lib64/.debug/libc-2.27.so.debug from remote target...
Trying /usr/lib/debug/target:/lib64/libc-2.27.so.debug
Trying /home/j/hide/target:/lib64/libc-2.27.so.debug
Breakpoint 1, 0x00000000004005eb in main ()
#0 0x00000000004005eb in main ()
From To Syms Read Shared Object Library
0x00007ffff7dd6e80 0x00007ffff7df4650 Yes (*) target:/lib64/ld-linux-x86-64.so.2
0x00007ffff7bbbb70 0x00007ffff7bcbfee Yes (*) target:/lib64/libpthread.so.0
0x00007ffff780f200 0x00007ffff7962d7c Yes (*) target:/lib64/libc.so.6
(*): Shared library is missing debugging information.
With current fix, the paths used always have target: in the beginning
and this helps to find all debug files:
$ gdb -ex 'set debug separate-debug-file 1' -ex 'set sysroot target:/' -ex 'set debug-file-directory /usr/lib/debug:/home/j/hide' -ex 'target remote :3333' -ex 'break main' -ex 'continue' -ex 'bt' -ex 'info sharedlibrary' -ex 'set confirm off' -ex 'quit'
GNU gdb (Gentoo 9999 vanilla) 8.2.50.20181109-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using :3333
Reading /home/j/test from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /home/j/test from remote target...
Reading symbols from target:/home/j/test...
Looking for separate debug info (debug link) for target:/home/j/test
Trying target:/home/j/test.debug
Reading /home/j/test.debug from remote target...
Trying target:/home/j/.debug/test.debug
Reading /home/j/.debug/test.debug from remote target...
Trying target:/usr/lib/debug//home/j/test.debug
Reading /usr/lib/debug//home/j/test.debug from remote target...
Trying target:/home/j/hide//home/j/test.debug
Reading /home/j/hide//home/j/test.debug from remote target...
Reading /home/j/hide//home/j/test.debug from remote target...
Reading symbols from target:/home/j/hide//home/j/test.debug...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Looking for separate debug info (debug link) for target:/lib64/ld-linux-x86-64.so.2
Trying target:/lib64/ld-2.27.so.debug
Reading /lib64/ld-2.27.so.debug from remote target...
Trying target:/lib64/.debug/ld-2.27.so.debug
Reading /lib64/.debug/ld-2.27.so.debug from remote target...
Trying target:/usr/lib/debug//lib64/ld-2.27.so.debug
Reading /usr/lib/debug//lib64/ld-2.27.so.debug from remote target...
Reading /usr/lib/debug//lib64/ld-2.27.so.debug from remote target...
Reading symbols from target:/usr/lib/debug//lib64/ld-2.27.so.debug...
Looking for separate debug info (build-id) for system-supplied DSO at 0x7ffff7ffa000
Trying /usr/lib/debug/.build-id/fd/03d584bc1a90ba28be457635a02662c9f9c1f2.debug
Trying /home/j/hide/.build-id/fd/03d584bc1a90ba28be457635a02662c9f9c1f2.debug
0x00007ffff7dd7000 in _start () from target:/lib64/ld-linux-x86-64.so.2
Breakpoint 1 at 0x4005ef: file test/test16.c, line 13.
Continuing.
Reading /lib64/libpthread.so.0 from remote target...
Reading /lib64/libc.so.6 from remote target...
Looking for separate debug info (debug link) for target:/lib64/libpthread.so.0
Trying target:/lib64/libpthread-2.27.so.debug
Reading /lib64/libpthread-2.27.so.debug from remote target...
Trying target:/lib64/.debug/libpthread-2.27.so.debug
Reading /lib64/.debug/libpthread-2.27.so.debug from remote target...
Trying target:/usr/lib/debug//lib64/libpthread-2.27.so.debug
Reading /usr/lib/debug//lib64/libpthread-2.27.so.debug from remote target...
Reading /usr/lib/debug//lib64/libpthread-2.27.so.debug from remote target...
Looking for separate debug info (debug link) for target:/lib64/libc.so.6
Trying target:/lib64/libc-2.27.so.debug
Reading /lib64/libc-2.27.so.debug from remote target...
Trying target:/lib64/.debug/libc-2.27.so.debug
Reading /lib64/.debug/libc-2.27.so.debug from remote target...
Trying target:/usr/lib/debug//lib64/libc-2.27.so.debug
Reading /usr/lib/debug//lib64/libc-2.27.so.debug from remote target...
Reading /usr/lib/debug//lib64/libc-2.27.so.debug from remote target...
Breakpoint 1, main () at test/test16.c:13
13 for ( i=0; i<10; ++i)
#0 main () at test/test16.c:13
From To Syms Read Shared Object Library
0x00007ffff7dd6e80 0x00007ffff7df4650 Yes target:/lib64/ld-linux-x86-64.so.2
0x00007ffff7bbbb70 0x00007ffff7bcbfee Yes target:/lib64/libpthread.so.0
0x00007ffff780f200 0x00007ffff7962d7c Yes target:/lib64/libc.so.6
gdb/ChangeLog:
2018-11-09 Andrey Utkin <autkin@undo.io>
* symfile.c (find_separate_debug_file): Fix search of debug files for
remote debuggee.
Tom Tromey [Wed, 2 Jan 2019 16:30:49 +0000 (09:30 -0700)]
Style improvements in gdb/python
This fixes a few minor style issues I found in gdb/python: some
unnecessary casts, the removal of an unnecessary local variable, and
one instance of incorrect formatting.
Tested by rebuilding and re-running gdb.python.
gdb/ChangeLog
2019-01-02 Tom Tromey <tom@tromey.com>
Andrew Burgess [Thu, 13 Dec 2018 17:59:12 +0000 (17:59 +0000)]
gdb/riscv: Split ISA and ABI features
The goal of this commit is to allow RV64 binaries compiled for the 'F'
extension to run on a target that supports both the 'F' and 'D'
extensions.
The 'D' extension depends on the 'F' extension and chapter 9 of the
RISC-V ISA manual implies that running a program compiled for 'F' on
a 'D' target should be fine.
To support this the gdbarch now holds two feature sets, one represents
the features that are present on the target, and one represents the
features requested in the ELF flags.
The existing error checks are relaxed slightly to allow binaries
compiled for 32-bit 'F' extension to run on targets with the 64-bit
'D' extension.
A new set of functions called riscv_abi_{xlen,flen} are added to
compliment the existing riscv_isa_{xlen,flen}, and some callers to the
isa functions now call the abi functions when that is appropriate.
In riscv_call_arg_struct two asserts are removed, these asserts no
longer make sense. The asserts were both like this:
And were made in two cases, when passing structures like these:
struct {
integer field1;
float field2;
};
or,
struct {
float field1;
integer field2;
};
When running on an RV64 target which only has 32-bit float then the
integer field could be 64-bits, while if the float field is 32-bits
the overall size of the structure can be 128-bits (with 32-bits of
padding). In this case the assertion would fail, however, the code
isn't incorrect, so its safe to just remove the assertion.
This was tested by running on an RV64IMFDC target using a compiler
configured for RV64IMFC, and comparing the results with those obtained
when using a compiler configured for RV64IMFDC. The only regressions
I see (now) are in gdb.base/store.exp and are related too different
code generation choices GCC makes between the two targets.
Finally, this commit does not make any attempt to support running
binaries compiled for RV32 on an RV64 target, though nothing in here
should prevent that being supported in the future.
gdb/ChangeLog:
* arch/riscv.h (struct riscv_gdbarch_features) <hw_float_abi>:
Delete.
<operator==>: Update with for removed field.
<hash>: Likewise.
* riscv-tdep.h (struct gdbarch_tdep) <features>: Renamed to...
<isa_features>: ...this.
<abi_features>: New field.
(riscv_isa_flen): Update comment.
(riscv_abi_xlen): New declaration.
(riscv_abi_flen): New declaration.
* riscv-tdep.c (riscv_isa_xlen): Update to get answer from
isa_features.
(riscv_abi_xlen): New function.
(riscv_isa_flen): Update to get answer from isa_features.
(riscv_abi_flen): New function.
(riscv_has_fp_abi): Update to get answer from abi_features.
(riscv_call_info::riscv_call_info): Use abi xlen and flen, not isa
xlen and flen.
(riscv_call_info) <xlen, flen>: Update comment.
(riscv_call_arg_struct): Remove invalid assertions
(riscv_features_from_gdbarch_info): Update now hw_float_abi field
is removed.
(riscv_gdbarch_init): Gather isa features and abi features
separately, ensure both match on the gdbarch when reusing an old
gdbarch. Relax an error check to allow 32-bit abi float to run on
a target with 64-bit float hardware.
The last text produced was not freed, causing the below leak
(e.g. in gdb.base/catch-syscall.exp):
==24970== 56 bytes in 12 blocks are definitely lost in loss record 626 of 3,289
==24970== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==24970== by 0x66B9C3F: __vasprintf_chk (vasprintf_chk.c:80)
==24970== by 0x405181: vasprintf (stdio2.h:210)
==24970== by 0x405181: xstrvprintf(char const*, __va_list_tag*) (common-utils.c:122)
==24970== by 0x40524B: xstrprintf(char const*, ...) (common-utils.c:113)
==24970== by 0x3B49DB: print_one_catch_syscall(breakpoint*, bp_location**) (break-catch-syscall.c:275)
==24970== by 0x3C698F: print_one_breakpoint_location(breakpoint*, bp_location*, int, bp_location**, int) (breakpoint.c:6076)
==24970== by 0x3C75B1: print_one_breakpoint(breakpoint*, bp_location**, int) (breakpoint.c:6373)
==24970== by 0x3C7D0E: breakpoint_1(char const*, int, int (*)(breakpoint const*)) (breakpoint.c:6571)
==24970== by 0x3C822C: info_breakpoints_command(char const*, int) (breakpoint.c:6625)
2019-01-01 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* break-catch-syscall.c (print_one_catch_syscall): xfree
the last text.
Joel Brobecker [Tue, 1 Jan 2019 06:01:51 +0000 (10:01 +0400)]
Update copyright year range in all GDB files.
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
Use gdb::unique_xmalloc_ptr<char> in command_line_input to fix a leak
Following the change of logic where the input_handler gets a
gdb::unique_xmalloc_ptr<char>, a call to readline directly
followed by a call to handle_line_of_input is missing a free,
and causes the below leak.
Use gdb::unique_xmalloc_ptr<char> to solve the leak.
==16291== VALGRIND_GDB_ERROR_BEGIN
==16291== 64 bytes in 1 blocks are definitely lost in loss record 1,815 of 4,111
==16291== at 0x4C2E2B3: realloc (vg_replace_malloc.c:836)
==16291== by 0x41EB1C: xrealloc (common-utils.c:62)
==16291== by 0x41DBD3: buffer_grow(buffer*, char const*, unsigned long) [clone .part.1] (buffer.c:40)
==16291== by 0x66E8FF: buffer_grow_char (buffer.h:40)
==16291== by 0x66E8FF: gdb_readline_no_editing (top.c:798)
==16291== by 0x66E8FF: command_line_input(char const*, char const*) (top.c:1249)
==16291== by 0x66EBD8: read_command_file(_IO_FILE*) (top.c:421)
==16291== by 0x412C0C: script_from_file(_IO_FILE*, char const*) (cli-script.c:1547)
==16291== by 0x40BE90: source_script_from_stream (cli-cmds.c:569)
==16291== by 0x40BE90: source_script_with_search(char const*, int, int) (cli-cmds.c:606)
==16291== by 0x54D567: catch_command_errors(void (*)(char const*, int), char const*, int) (main.c:379)
==16291== by 0x54EA84: captured_main_1 (main.c:994)
==16291== by 0x54EA84: captured_main (main.c:1167)
==16291== by 0x54EA84: gdb_main(captured_main_args*) (main.c:1193)
==16291== by 0x29DA27: main (gdb.c:32)
==16291==
==16291== VALGRIND_GDB_ERROR_END
gdb/ChangeLog
2018-12-31 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* top.c (command_line_input): Use unique_xmalloc_ptr to
manage memory allocated by readline.
Alan Modra [Mon, 31 Dec 2018 06:36:25 +0000 (17:06 +1030)]
PR24042, Global-buffer-overflow problem in output_rel_find
place_orphan handled ELF SHT_REL/SHT_RELA specially, output_rel_find
didn't. This mismatch was a bug and also meant it was possible to
craft an object where ld accessed section->name out of bounds.
PR 24042
* emultempl/elf32.em (output_rel_find): Drop "sec" param. Add
"rela".
(gld${EMULATION_NAME}_place_orphan): Use sh_type to calculate
"rela" param of output_rel_find when ELF. Tidy uses of elfinput.
Alan Modra [Mon, 31 Dec 2018 01:41:42 +0000 (12:11 +1030)]
[PowerPC64] Nop out ld 2,24(1) after old-style __tls_get_addr
When optimising inline plt calls to __tls_get_addr without tls marker
relocs, ld should zap any toc restore insn after the bctrl, to stop a
load-hit-store stall.
* elf64-ppc.c (ppc64_elf_relocate_section <tls_ldgd_opt>): When
editing an old-style __tls_get_addr call, replace a toc restore
insn with a nop.
The layout for 'help set address|variable' is strange, e.g.:
(gdb) help set style address
style address
List of show Address display styling
Configure address colors and display intensity subcommands:
show Address display styling
Configure address colors and display intensity background -- Set the background color for this property
show Address display styling
Configure address colors and display intensity foreground -- Set the foreground color for this property
show Address display styling
Configure address colors and display intensity intensity -- Set the display intensity color for this property
Type "help show Address display styling
Configure address colors and display intensity" followed by show Address display styling
Configure address colors and display intensity subcommand name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb)
The help for 'set style function|filename' gives help for 'Show':
(gdb) help set style filename
Filename display styling
Configure filename colors and display intensity.
List of show style filename subcommands:
show style filename background -- Set the background color for this property
show style filename foreground -- Set the foreground color for this property
show style filename intensity -- Set the display intensity color for this property
The help for 'show style function|filename' is equally strange, as it speaks
about commands, instead of sub commands:
(gdb) help show style filename
Filename display styling
Configure filename colors and display intensity.
List of commands:
background -- Show the background color for this property
foreground -- Show the foreground color for this property
intensity -- Show the display intensity color for this property
Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb)
This patch fixes all this.
Note that the 'set style' and 'show style' have the same prefix_doc:
(gdb) help show style
Style-specific settings
Configure various style-related variables, such as colors
...
(gdb) help set style
Style-specific settings
Configure various style-related variables, such as colors
...
Other similar commands (such as set|show history) have typically
a more specific prefix:
(gdb) help show history
Generic command for showing command history parameters.
...
(gdb) help set history
Generic command for setting command history parameters.
...
This could be fixed by having set_prefix_doc and show_prefix_doc instead of
the single prefix_doc argument to cli_style_option::add_setshow_commands.
That could be improved if deemed better.
2018-12-29 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-style.c (cli_style_option::add_setshow_commands):
Initialize m_set_prefix with "set", instead of re-assigning
m_show_prefix. Use m_set_prefix for set_list and m_show_prefix
for show_list.
(_initialize_cli_style): Correct the order of arguments in
variable_name_style.add_setshow_commands and
address_style.add_setshow_commands calls.
Tom Tromey [Sat, 29 Dec 2018 04:07:24 +0000 (21:07 -0700)]
Fix the build when GNU Source Highlight is not available
The builder pointed out that, when GNU Source Highlight is not
available, get_language_name is not used. This patch makes it
conditional, fixing the build problem.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
Tom Tromey [Wed, 19 Dec 2018 18:44:28 +0000 (11:44 -0700)]
Fix a crash in jit.c
A user at Mozilla pointed out a crash in jit.c. In his situation, an
inferior using the JIT API exec'd an executable that did not use it.
This caused an assertion failure when jit.c:free_objfile_data called
delete_breakpoint with NULL.
This patch fixes the problem in the obvious way. New test case
included.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* jit.c (free_objfile_data): Only delete breakpoint if non-null.
gdb/testsuite/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
Simon Marchi <simark@simark.ca>
* gdb.base/jit-exec.exp: New file.
* gdb.base/jit-exec.c: New file.
* gdb.base/jit-execd.c: New file.
Tom Tromey [Mon, 3 Sep 2018 18:42:59 +0000 (12:42 -0600)]
Make ANSI terminal escape sequences work in TUI
PR tui/14126 notes that ANSI terminal escape sequences don't affect
the colors shown in the TUI. A simple way to see this is to try the
extended-prompt example from the gdb manual.
Curses does not pass escape sequences through to the terminal.
Instead, it replaces non-printable characters with a visible
representation, for example "^[" for the ESC character.
This patch fixes the problem by adding a simple ANSI terminal sequence
parser to gdb. These sequences are decoded and those that are
recognized are turned into the appropriate curses calls.
The curses approach to color handling is unusual and so there are some
oddities in the implementation.
Standard curses has no notion of the default colors of the terminal.
So, if you set the foreground color, it is not possible to reset it --
you have to pick some other color. ncurses provides an extension to
handle this, so this patch updates configure and uses it when
available.
Second, in curses, colors always come in pairs: you cannot set just
the foreground. This patch handles this by tracking actually-used
pairs of colors and keeping a table of these for reuse.
Third, there are a limited number of such pairs available. In this
patch, if you try to use too many color combinations, gdb will just
ignore some color changes.
Finally, in addition to limiting the number of color pairs, curses
also limits the number of colors. This means that, when using
extended 8- or 24-bit color sequences, it may be possible to exhaust
the curses color table.
I am very sour on the curses design now.
I do not know how to write a test for this, so I did not.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
PR tui/14126:
* tui/tui.c (tui_enable): Call start_color and
use_default_colors.
* tui/tui-io.c (struct color_pair): New.
(color_pair_map, last_color_pair, last_style): New globals.
(tui_setup_io): Clean up color map when shutting down.
(curses_colors): New constant.
(get_color_pair, apply_ansi_escape): New functions.
(tui_write): Rewrite.
(tui_puts_internal): New function, from tui_puts. Add "height"
parameter.
(tui_puts): Use tui_puts_internal.
(tui_redisplay_readline): Use tui_puts_internal.
(_initialize_tui_io): New function.
(color_map): New globals.
(get_color): New function.
* configure.ac: Check for use_default_colors.
* config.in, configure: Rebuild.
Tom Tromey [Thu, 6 Sep 2018 05:32:16 +0000 (23:32 -0600)]
Style locations when setting a breakpoint
say_where does not use ui-out, so function and file names printed by
it were not styled. This patch changes say_where to use the low-level
style code directly.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* breakpoint.c (say_where): Style file name.
gdb/testsuite/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Add test for breakpoint setting.
Tom Tromey [Wed, 5 Sep 2018 18:12:19 +0000 (12:12 -0600)]
Style variable names
This adds style support for variable names. For the time being, this
is only done in backtraces, not in ptype or print; those places do not
use ui-out and so would need ad hoc changes.
This also adds styling to the names printed for local variables in
"backtrace full". This code does not use ui-out, so the styling is
done using the low-level API.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
Tom Tromey [Tue, 4 Sep 2018 04:56:33 +0000 (22:56 -0600)]
Add output styles to gdb
This adds some output styling to the CLI.
A style is currently a foreground color, a background color, and an
intensity (dim or bold). (This list could be expanded depending on
terminal capabilities.)
A style can be applied while printing. For ui-out, this is done by
passing the style constant as an argument. For low-level cases,
fprintf_styled and fputs_styled are provided.
Users can control the style via a number of new set/show commands. In
the interest of not typing many nearly-identical documentation
strings, I automated this. On the down side, this is not very
i18n-friendly.
I've chose some default colors to use. I think it would be good to
enable this by default, so that when users start the new gdb, they
will see the new feature.
Stylizing is done if TERM is set and is not "dumb". This could be
improved when the TUI is available by using the curses has_colors
call. That is, the lowest layer could call this without committing to
using curses everywhere; see my other patch for TUI colorizing.
I considered adding a new "set_style" method to ui_file. However,
because the implementation had to interact with the pager code, I
didn't take this approach. But, one idea might be to put the isatty
check there and then have it defer to the lower layers.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
Tom Tromey [Tue, 13 Nov 2018 18:59:03 +0000 (11:59 -0700)]
Change gdb test suite's TERM setting
This changes the gdb test suite to set TERM to "dumb" by default.
This setting disables terminal styling, so that the existing tests do
not need to be updated.
gdb/testsuite/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* lib/gdb.exp (gdb_init): Set the TERM environment variable to
"dumb".
* gdb.base/readline.exp (operate_and_get_next): Save and restore
the TERM environment variable.
Tom Tromey [Sat, 10 Nov 2018 00:29:50 +0000 (17:29 -0700)]
Introduce ui_file_style
This introduces the new ui_file_style class and various helpers. This
class represents a terminal style and provides methods for parsing and
emitting the corresponding ANSI terminal escape sequences.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* unittests/style-selftests.c: New file.
* ui-style.c: New file.
* ui-style.h: New file.
* ui-file.h: Include ui-style.h.
* Makefile.in (COMMON_SFILES): Add ui-style.c.
(HFILES_NO_SRCDIR): Add ui-style.h.
(SUBDIR_UNITTESTS_SRCS): Add style-selftests.c.
Tom Tromey [Thu, 6 Sep 2018 20:03:38 +0000 (14:03 -0600)]
Add a "context" argument to add_setshow_enum_cmd
This adds a "context" argument to add_setshow_enum_cmd. Now
add_setshow_enum_cmd will call set_cmd_context on both of the new
commands. This is used in a later patch.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
Tom Tromey [Wed, 5 Sep 2018 17:25:28 +0000 (11:25 -0600)]
Change wrap buffering to use a std::string
Currently wrap buffering is implemented by allocating a string that is
the same width as the window, and then writing characters into it.
However, if gdb emits terminal escapes, then these could possibly
overflow the buffer.
To prevent this, change the wrap buffer to be a std::string and update
the various uses.
This also changes utils.c to always emit characters to the wrap
buffer. This simplifies future patches which emit terminal escape
sequences, and also makes it possible for the "echo" and "printf"
commands to be used to emit terminal escapes and have these work in
the TUI.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* utils.c (filter_initialized): New global.
(wrap_buffer): Now a std::string.
(wrap_pointer): Remove.
(flush_wrap_buffer): New function.
(filtered_printing_initialized, set_width, wrap_here)
(fputs_maybe_filtered): Update.
Fix leak of set/show verbose doc, avoid xfree of static string
In the tests
py-pp-registration/gdb.log
default/gdb.log
foll-fork/gdb.log
setshow/gdb.log
break-interp/gdb.log
Valgrind detects a leak of the doc strings for the set and show verbose cmd.
Here is the stacktrace of the leaked set doc:
==25548== 15 bytes in 1 blocks are definitely lost in loss record 101 of 3,120
==25548== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==25548== by 0x409C27: xmalloc (common-utils.c:44)
==25548== by 0x778AF9: xstrdup (xstrdup.c:34)
==25548== by 0x3F860F: add_setshow_cmd_full(char const*, command_class, var_types, void*, char const*, char const*, char const*, void (*)(char const*, int, cmd_list_element*), void (*)(ui_file*, int, cmd_list_element*, char const*), cmd_list_element**, cmd_list_element**, cmd_list_element**, cmd_list_element**) [clone .constprop.10] (cli-decode.c:495)
==25548== by 0x3F8ADB: add_setshow_boolean_cmd(char const*, command_class, int*, char const*, char const*, char const*, void (*)(char const*, int, cmd_list_element*), void (*)(ui_file*, int, cmd_list_element*, char const*), cmd_list_element**, cmd_list_element**) (cli-decode.c:593)
==25548== by 0x3F7442: _initialize_cli_cmds() (cli-cmds.c:1768)
==25548== by 0x69EED3: initialize_all_files() (init.c:365)
==25548== by 0x658A84: gdb_init(char*) (top.c:2163)
==25548== by 0x5403E1: captured_main_1 (main.c:863)
==25548== by 0x5403E1: captured_main (main.c:1167)
==25548== by 0x5403E1: gdb_main(captured_main_args*) (main.c:1193)
==25548== by 0x289CA7: main (gdb.c:32)
The leak is created by top.c set_verbose 'elaborate joke':
the doc string is changed according to the verbosity:
(gdb) help set verbose
Set verbosity.
(gdb) set verbose on
(gdb) help set verbose
Set verbose printing of informational messages.
(gdb)
set_verbose creates the leak as it replaces the string allocated in
the above stacktrace by a static (non translated) string:
...
if (info_verbose)
{
c->doc = "Set verbose printing of informational messages.";
...
Also, this can possibly trigger a call to 'free' of a static string,
as c->doc_allocated is kept true, while the string is not allocated anymore.
This patch:
* fixes the leak by freeing the previous docs if doc_allocated.
* internationalize the messages.
* properly sets doc_allocated to 0 once doc strings are static.
gdb/ChangeLog
2018-12-28 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* top.c (set_verbose): Free previous docs if doc_allocated.
Internationalize messages. Set doc_allocated to 0.
Eli Zaretskii [Fri, 28 Dec 2018 07:02:04 +0000 (09:02 +0200)]
Avoid internal errors when stepping outside 'main' on MinGW
When one steps with "next" past the 'main's 'return' statement
in MinGW programs built by mingw.org's tools, PC lands in a
function whose symbol is not in any symtab. GDB then looks
up the nearest symbol, and should find none, because all those
with addresses below PC are not real functions. Having
unresolved symbols, whose address is zero, in minsyms tricked
GDB into using these bogus symbols, which then caused
assertion violation and internal_error. See the discussion at
https://sourceware.org/ml/gdb-patches/2018-12/msg00176.html
for more details.
gdb/ChangeLog
2018-12-28 Eli Zaretskii <eliz@gnu.org>
* coffread.c (coff_symtab_read): Don't record in minsyms symbols
that are unresolved. This avoids triggering an internal error
when stepping outside of 'main' in MinGW programs.
Alan Modra [Thu, 27 Dec 2018 23:11:44 +0000 (09:41 +1030)]
PR24015, glibc-2.28 on little-endian mips32 broken
Commit 2bf2bf23da exposed a bug on targets that create common sections
other than the standard ELF SHN_COMMON. If these are output by ld -r,
then their type becomes SHT_PROGBITS unless the target handles them
specially (eg. by elf_backend_special_sections), and if they are
merged into .bss/.sbss by ld -r then that section becomes SHT_PROGBITS.
Worse, if they are output by ld -r, then their size is increased by
bfd_generic_define_common_symbol during final link, which leads to
bogus file contents being copied to output.
For mips, it seems to me that the .scommon section should not be
output for ld -r, but I haven't made that change in this patch.
PR 24015
* elf.c (bfd_elf_get_default_section_type): Make common sections
SHT_NOBITS.
* linker.c (bfd_generic_define_common_symbol): Clear
SEC_HAS_CONTENTS.
Alan Modra [Thu, 27 Dec 2018 23:04:28 +0000 (09:34 +1030)]
PR23966, mingw failure due to 32-bit long
PR 23966
* libbfd.c (SSIZE_MAX): Define.
(bfd_malloc, bfd_realloc): Don't cast size to long to check for
"negative" values, compare against SSIZE_MAX instead.
Alan Modra [Thu, 27 Dec 2018 23:01:42 +0000 (09:31 +1030)]
PR24028, PPC_INT_FMT
PPC_INT_FMT is redundant now that bfd.h pulls in inttypes.h if
available. Apparently MacOS Mojave defines int64_t as long long even
though long is also 64 bits, which confuses the logic selecting
PPC_INT_FMT (and BFD_PRI64 too). Hopefully inttypes.h is available on
Mojave.
Tom Tromey [Tue, 25 Dec 2018 19:38:01 +0000 (12:38 -0700)]
Translate PyExc_KeyboardInterrupt to gdb "quit"
A while back I typed "info pretty-printers" with a large number of
printers installed, and I typed "q" to stop the pagination. I noticed
that gdb printed a Python exception in this case.
It seems to me that, instead, quitting pagination (or control-c'ing a
Python command generally) should be handled the same way that gdb
normally handles a quit.
This patch implements this idea by changing gdbpy_handle_exception to
treat PyExc_KeyboardInterrupt specially.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* python/py-utils.c (gdbpy_handle_exception): Translate
PyExc_KeyboardInterrupt to quit.
gdb/testsuite/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
Tom Tromey [Tue, 25 Dec 2018 18:44:58 +0000 (11:44 -0700)]
Consolidate some Python exception-printing functions
A few places in the Python code would either call gdbpy_print_stack,
or throw a gdb "quit", depending on the pending exception. This patch
consolidates these into a helper function.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* python/python-internal.h (gdbpy_print_stack_or_quit): Declare.
* python/py-unwind.c (pyuw_sniffer): Use
gdbpy_print_stack_or_quit.
* python/py-framefilter.c (throw_quit_or_print_exception):
Remove.
(gdbpy_apply_frame_filter): Use gdbpy_print_stack_or_quit.
* python/python.c (gdbpy_print_stack_or_quit): New function.
Tom Tromey [Tue, 25 Dec 2018 18:00:21 +0000 (11:00 -0700)]
Use gdbpy_convert_exception in a few more spots
I noticed a few places were converting a gdb exception to a Python
exception "by hand". It's better to use the existing
gdbpy_convert_exception helper function, as this handles memory errors
correctly, and in the future may be enhanced in other ways.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* python/py-value.c (convert_value_from_python): Use
gdbpy_convert_exception.
* python/py-param.c (parmpy_init): Use gdbpy_convert_exception.
* python/py-cmd.c (cmdpy_init): Use gdbpy_convert_exception.
* python/py-breakpoint.c (bppy_init): Use
gdbpy_convert_exception.
Tom Tromey [Mon, 24 Dec 2018 19:01:34 +0000 (12:01 -0700)]
Build gdb "nat" files in subdirectory
This moves the various "nat" object files into the nat/ subdirectory.
This allows for the removal of a pattern rule from the gdb Makefile,
which is a small cleanup.
I made the configure.nat change in a (semi-) automated way, hopefully
meaning that it is more likely to be correct than had I done it by
hand.
Eventually I would like for the various configure scripts to only
mention source files, and let the Makefile compute the object file
names.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* configure.nat (NATDEPFILES): Use nat/ prefix.
* Makefile.in (CONFIG_SRC_SUBDIR): Add nat.
(%.o: ${srcdir}/nat/%.c): Remove rule.
(INIT_FILES): Do not filter out NATDEPFILES.
Tom Tromey [Mon, 24 Dec 2018 18:44:10 +0000 (11:44 -0700)]
Make init.c depend on source files
I noticed that init.c depends on the object files that go into gdb.
Because init.c actually only requires the contents of the
corresponding source files, this unnecessarily serializes the step
that builds init.c.
This patch changes gdb's Makefile to make init.c depend on the source
files. This also simplifies the rule to build init.c.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* Makefile.in (INIT_FILES): Redefine.
(stamp-init): Remove sed, tr invocations. Use for loop. Don't
set LANG or LC_ALL.
Tom Tromey [Mon, 24 Dec 2018 17:07:51 +0000 (10:07 -0700)]
Remove gdbtypes special case from init.c rule
The rule to make init.c has a special case for gdbtypes, with a long
explanatory comment. All of this is obsolete, as the globals referred
to by the comment no longer exist. This patch simplifies the rule.
gdb/ChangeLog
2018-12-27 Tom Tromey <tom@tromey.com>
* Makefile.in (stamp-init): Remove gdbtypes special case.
projects / thirdparty / binutils-gdb.git / log
