Declarations for functions in source.c are split between source.h and
symtab.h. This commit moves the small number that are in symtab.h
into source.h. There's just one file that needs to add an include of
source.h in order to build.
I've moved the function header comments from source.c to source.h
inline with the recommended GDB style.
gdb/ChangeLog:
* source.c (select_source_symtab): Move header comment to
declaration in source.h.
(forget_cached_source_info_for_objfile): Likewise.
(forget_cached_source_info): Likewise.
(identify_source_line): Likewise.
* source.h (identify_source_line): Move declaration from symtab.h
and add comment from source.c
(print_source_lines): Likewise.
(forget_cached_source_info_for_objfile): Likewise.
(forget_cached_source_info): Likewise.
(select_source_symtab): Likewise.
(enum print_source_lines_flag): Move definition from symtab.h.
* symtab.h (identify_source_line): Move declaration to source.h.
(print_source_lines): Likewise.
(forget_cached_source_info_for_objfile): Likewise.
(forget_cached_source_info): Likewise.
(select_source_symtab): Likewise.
(enum print_source_lines_flag): Move definition to source.h.
* tui/tui-hooks.c: Add 'source.h' include.
...by which I mean from high line number to low, not, actually
backward character by character!
Commit:
commit 62f29fda90
Date: Tue Oct 9 22:21:05 2018 -0600
Highlight source code using GNU Source Highlight
introduced a regression in the test gdb.linespec/explicit.exp, in
which a request is made to GDB to print a reverse sequence of lines,
from +10 to -10 from the current line number. The expected behaviour
is that GDB prints nothing. The above commit changed this so that GDB
now prints:
Line number 32 out of range; /path/to/gdb/testsuite/gdb.linespec/explicit.c has 71 lines.
which is a little confusing.
This commit fixes the regression, and restores the behaviour that GDB
prints nothing.
While I was passing I noticed a call to `back` on a std::string that I
was concerned could be empty if the request for source lines returns
an empty string. I don't know if it would be possible for a request
for lines to return an empty string, I guess it should be impossible,
in which case, maybe this should be an assertion, but adding a `empty`
check, seems like an easy and cheap safety net.
gdb/ChangeLog:
* source.c (print_source_lines_base): Handle requests to print
reverse line number sequences, and guard against empty lines
string.
In this commit:
commit 62f29fda90
Date: Tue Oct 9 22:21:05 2018 -0600
Highlight source code using GNU Source Highlight
A bug was introduced such that when displaying source code from a file
with lines `\r\n` GDB would print `^M` at the end of each line.
This caused a regression on the test gdb.fortran/nested-funcs.exp,
which happens to have `\r\n` line endings.
gdb/ChangeLog:
* source.c (print_source_lines_base): Fix skip of '\r' if next
character is '\n'.
The previous commit breaks the GDB build, which is still using functions
cplus_demangle_opname & co. Since removing these usages is not an
obvious fix, let's revert this patch until we get rid of them.
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.
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.
* config/tc-arm.c (arm_cpus): Add ares.
* doc/c-arm.texi (-mcpu): Document ares value.
This removes the remaining cleanups from c-exp.y by moving some
globals into c_parse_state, and changing expansion_obstack to be an
auto_obstack.
gdb/ChangeLog
2019-01-06 Tom Tromey <tom@tromey.com>
* c-exp.y (struct c_parse_state) <macro_original_text,
expansion_obstack>: New member.
(macro_original_text, expansion_obstack): Remove globals.
(scan_macro_expansion, scanning_macro_expansion)
(finished_macro_expansion): Update.
(scan_macro_cleanup): Remove.
(yylex, c_parse): Update.
This removes a string-related cleanup from c-exp.y, by adding a new
member to c_parse_state to store the strings.
gdb/ChangeLog
2019-01-06 Tom Tromey <tom@tromey.com>
* c-exp.y (struct c_parse_state) <strings>: New member.
(operator_stoken): Update.
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.
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.
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>
* contrib/cleanup_check.py: Remove.
* contrib/gcc-with-excheck: Remove.
* contrib/exsummary.py: Remove.
* contrib/excheck.py: Remove.
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 0803633106
| 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:
| - for (tp = thread_list; tp; tpprev = tp, tp = tp->next)
| + for (tp = thr->inf->thread_list; tp; tpprev = tp, tp = tp->next)
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 87a45c9606
| 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.
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.
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.
Mode field should be read in octal, all the rest in decimal. Do so.
PR 24061
PR 21786
* coff-rs6000.c (GET_VALUE_IN_FIELD): Add base parameter and
adjust all callers.
(EQ_VALUE_IN_FIELD): Likewise.
* coff64-rs6000.c (GET_VALUE_IN_FIELD): Likewise.
valgrind pointed out that the string copy in tui_set_source_content
was not allocating space for the trailing \0:
==3941== Invalid write of size 1
==3941== at 0x4C3239F: strcpy (vg_replace_strmem.c:512)
==3941== by 0x72036B: strcpy (string_fortified.h:90)
==3941== by 0x72036B: tui_set_source_content(symtab*, int, int) (tui-source.c:203)
Looking closer, I don't think there's a need to check the line width
here, so this patch changes it to use xstrdup.
Tested by re-running the TUI under valgrind. There are still other
valgrind reports from TUI code, but this one is gone.
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* tui/tui-source.c (tui_set_source_content): Use xstrdup.
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.
This improves the reference counting in py-type.c by using gdbpy_ref
and gdbpy_ref::new_reference in more places.
gdb/ChangeLog
2019-01-03 Tom Tromey <tom@tromey.com>
* python/py-type.c (convert_field): Use new_reference. Return
gdbpy_ref.
(make_fielditem): Return gdbpy_ref.
(typy_fields): Update.
(typy_getitem): Update.
(field_name): Return gdbpy_ref. Use new_reference.
(typy_iterator_iternext): Update.
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.
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.
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.
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.
Replace cleanup in linux-fork.c:inferior_call_waitpid with a RAII
object.
gdb/ChangeLog:
* linux-fork.c (class scoped_switch_fork_info): New class.
(inferior_call_waitpid): Update to use scoped_switch_fork_info.
This patch removes the setup of a null_cleanup in
valops.c:find_overload_match, and all the calls to do_cleanups.
gdb/ChangeLog:
* valops.c (find_overload_match): Remove use of null_cleanup, and
calls to do_cleanups.
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.
Convert one of the variables that requires a cleanup from a 'char *'
to a 'gdb::char_vector' in remote_target::remote_check_symbols.
Tested on x86-64/Linux with target_board native-gdbserver and
native-extended-gdbserver.
gdb/ChangeLog:
* remote.c (remote_target::remote_check_symbols): Convert `msg` to
gdb::char_vector, remove cleanup, and update uses of `msg`.
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.
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.
https://sourceware.org/bugzilla/show_bug.cgi?id=18632
The bundled libreadline is always built, even if the system is
./configure'd --with-system-readline and the build libreadline.a is not
used.
Proposed patch:
Fix ./configure.ac not to proceed readline/, when --with-system-
readline is provided
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.
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>
* linespec.c (struct linespec_parser): Rename from ls_parser. Add
constructor, destructor.
(linespec_parser): Remove typedef.
(~linespec_parser): Rename from linespec_parser_delete.
(linespec_lex_to_end, linespec_complete_label)
(linespec_complete): Update.
(decode_line_full): Remove cleanups.
(decode_line_1): Update.
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>
* python/python-internal.h (inferior_to_inferior_object): Change
return type.
* python/py-exitedevent.c (create_exited_event_object): Update.
* python/py-inferior.c (inferior_to_inferior_object): Return
gdbpy_ref.
(python_new_inferior, python_inferior_deleted)
(thread_to_thread_object, delete_thread_object)
(build_inferior_list, gdbpy_selected_inferior): Update.
* python/py-infthread.c (create_thread_object): Update. Also fail
if inferior_to_inferior_object fails.