| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When calling gdb_start_cmd, it's the caller's responsibility to wait for gdb
to return to the prompt. In target_supports_scheduler_locking, that's not the
case, and consequently, target_supports_scheduler_locking fails spuriously.
Fix by using runto_main instead.
Build and reg-tested on x86_64-linux.
2018-10-09 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (target_supports_scheduler_locking): Replace gdb_start_cmd
with runto_main.
|
|
This commit fixes a buffer overrun found by Coverity, where
36 bytes are written into a 24 byte buffer.
gdb/ChangeLog:
* dwarf2read.c (create_dwp_hash_table): Fix buffer overrun
found by Coverity.
|
|
This removes a couple of unused variables from riscv-fbsd-tdep.c.
This allows a --enable-targets=all build to complete on
x86-64 Fedora 28.
gdb/ChangeLog
2018-10-08 Tom Tromey <tom@tromey.com>
* riscv-fbsd-tdep.c (riscv_fbsd_sigframe_init): Remove unused
variable.
(riscv_fbsd_init_abi): Likewise.
|
|
Rename local variable in value_struct_elt_for_reference()
to work around the shadowing a previous local warning.
|
|
gdb/ChangeLog:
* Makefile.in (ALLDEPFILES): Add riscv-fbsd-nat.c.
* NEWS: Mention new FreeBSD/riscv native configuration.
* configure.host: Add riscv*-*-freebsd*.
* configure.nat: Likewise.
* riscv-fbsd-nat.c: New file.
gdb/doc/ChangeLog:
* gdb.texinfo (Contributors): Add SRI International and University
of Cambridge for FreeBSD/riscv.
|
|
Support for collecting and supplying general purpose and floating
point register sets is provided along with signal frame unwinding.
FreeBSD only supports RV64 currently, so while some provision is made
for RV32 in the general-purpose register set, the changes have only
been tested on RV64.
gdb/ChangeLog:
* Makefile.in (ALL_TARGET_OBS): Add riscv-fbsd-tdep.o.
(HFILES_NO_SRCDIR): Add riscv-fbsd-tdep.h.
(ALLDEPFILES): Add riscv-fbsd-tdep.c.
* NEWS: Mention new FreeBSD/riscv target.
* configure.tgt: Add riscv*-*-freebsd*.
* riscv-fbsd-tdep.c: New file.
* riscv-fbsd-tdep.h: New file.
|
|
Currently, signal frame handlers require explicitly coded calls to
trad_frame_set_reg_addr() to describe the location of saved registers
within a signal frame. This change permits the regcache_map_entry
arrays used with regcache::supply_regset and regcache::collect_regset
to be used to describe a block of saved registers given an initial
address for the register block.
Some systems use the same layout for registers in core dump notes,
native register sets with ptrace(), and the register contexts saved in
signal frames. On these systems, a single register map can now be
used to describe the layout of registers in all three places.
If a register map entry's size does not match the native size of a
register, try to match the semantics used by
regcache::transfer_regset. If a register slot is too large, assume
that the register's value is stored in the first N bytes and ignore
the remaning bytes. If the register slot is smaller than the
register, assume the slot holds the low N bytes of the register's
value. Read these low N bytes from the target and zero-extend them to
generate a register value.
While here, document the semantics for both regcache::transfer_regset
and trad_frame with respect to register slot's whose size does not
match the register's size.
gdb/ChangeLog:
* regcache.h (struct regcache_map_entry): Note that this type can
be used with traditional frame caches.
* trad-frame.c (trad_frame_set_reg_regmap): New.
* trad-frame.h (trad_frame_set_reg_regmap): New.
|
|
This patch fixes the original problem - printing member in a virtual base,
using various expressions, do not yield the same value. Simple test case
below demonstrates the problem:
% cat t.cc
struct base { int i; };
typedef base tbase;
struct derived: virtual tbase { void func() { } };
int main() { derived().func(); }
% g++ -g t.cc
% gdb a.out
(gdb) break derived::func
(gdb) run
(gdb) p i
$1 = 0
(gdb) p base::i
$3 = 0
(gdb) p derived::i
$4 = 4196392
To fix the problem, add function get_baseclass_offset() which searches
recursively for the base class along the class hierarchy. If the base
is virtual, it uses "vptr" in virtual class object, which indexes to
its derived class's vtable, to get and returns the baseclass offset.
If the base is non-virtual, it returns the accumulated offset of its
parent classes. The offset is then added to the address of the class
object to access its member in value_struct_elt_for_reference().
|
|
Version 5.0.40 (build 15175).
gdb/ChangeLog:
* dwarf2read.c (dwarf2_cu) <producer_is_codewarrior>: New field.
(check_producer): Check if the producer is codewarrior.
(producer_is_codewarrior): New function.
(lnp_state_machine::record_line): Ignore is_stmt flag for records
produced by codewarrior.
(dwarf2_cu::dwarf2_cu): Initialize producer_is_codewarrior.
|
|
gdb/doc/ChangeLog:
2018-10-08 Andreas Krebbel <krebbel@linux.ibm.com>
* python.texi (Inferior.Architecture): Add "@end defun". Rename
ref target to "Unwinding Frames in Python".
|
|
I've written a couple of gdb unwinders in Python, and while doing so,
I wanted to find the architecture of the inferior. (In an unwinder in
particular, one can't use the frame's architecture, because there is
no frame.)
This patch adds Inferior.architecture to allow this. Normally I think
I would have chosen an attribute and not a method here, but seeing
that Frame.architecture is a method, I chose a method as well, for
consistency.
gdb/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
PR python/19399:
* python/py-inferior.c: Add "architecture" entry.
(infpy_architecture): New function.
gdb/doc/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
PR python/19399:
* python.texi (Inferiors In Python): Document
Inferior.Architecture.
gdb/testsuite/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
PR python/19399:
* gdb.python/py-inferior.exp: Add architecture test.
|
|
In the distant past, there was no distinction between domain_enum and
search_domain. At that point, there were two sets of enumerators in a
single enum -- which is why these were eventually split. This
confusion leaked out to the Python API as well, as noted in
PR python/21765.
This patch deprecates the constants that aren't useful to the Python
API. They are left in place for now, but removed from the
documentation. Also, their values are changed so that, if used, they
might work. Finally, missing domains and location constants are
added.
gdb/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
PR python/21765:
* python/py-symbol.c (gdbpy_initialize_symbols): Redefine
SYMBOL_VARIABLES_DOMAIN, SYMBOL_FUNCTIONS_DOMAIN,
SYMBOL_TYPES_DOMAIN. Define SYMBOL_MODULE_DOMAIN,
SYMBOL_COMMON_BLOCK_DOMAIN, SYMBOL_LOC_COMMON_BLOCK.
gdb/doc/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
PR python/21765:
* python.texi (Symbols In Python): Document the module and
common-block domains. Remove documentation for incorrect
domains.
|
|
I noticed a few files left over in the testsuite/ directory in the
build tree after running tests. Normally output files should not wind
up there, but instead should end up in the test's subdirectory. This
isn't always crucial, but in the past there were problems with tests
clashing, preventing parallel runs, and so it is better to be clean
here.
This patch changes a couple of tests to use standard_output_file to
fix this problem.
Tested by re-running the tests in question and examining the
directory.
gdb/testsuite/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
* gdb.base/gnu-ifunc.exp (build): Use standard_output_file.
* gdb.trace/unavailable-dwarf-piece.exp: Use standard_output_file.
|
|
PR build/17077 points out that when --with-system-readline is given,
gdb will still pick up the in-tree readline headers. Normally this is
not a big problem, because readline is very stable and so the ABI does
not change much; but it is clearly a bug to do this, and could bite at
some point.
The basic problem is that OPCODES_CFLAGS uses -I$(OPCODES_SRC)/.. so
that #include "opcodes/..." works. However, this also makes it so the
This patch fixes the problem in a mildly hacky way: remove the
offending -I option, and change gdb to use #include "../opcodes/..."
instead. This continues to make it clear where the header comes from,
without allowing incorrect behavior.
Tested by rebuilding and then looking at the *.Po files.
gdb/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
PR build/17077:
* Makefile.in (OPCODES_CFLAGS): Remove "-I$(OPCODES_SRC)/..".
* arc-tdep.c, frv-tdep.c, lm32-tdep.c, mep-tdep.c,
microblaze-tdep.c, or1k-tdep.h: Use ../opcodes, not opcodes, in
#include.
|
|
I noticed today that gdb.Breakpoint.location will crash when applied
to a catchpoint made with "catch throw".
The bug is that "catch throw" makes a breakpoint that is of type
bp_breakpoint, but which does not have a location.
Regression tested on x86-64 Fedora 28.
gdb/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
* python/py-breakpoint.c (bppy_get_location): Handle a
bp_breakpoint without a location.
gdb/testsuite/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
* gdb.python/py-breakpoint.exp (check_last_event): Check location
of a "throw" catchpoint.
|
|
Philippe pointed out that the "enable frame-filter" help text looked
funny.
While fixing this I noticed a few more problems in the help text of
commands written in Python:
* Trailing newlines
* Wrong style for metasyntactic variables
* Indentation of the text
* ... and finally, I thought the function usage lines didn't need
that extra newline -- someday I'd like to be able to write a
"usage" command that just greps for the Usage line, so ideally it
would be tighter than what was done here
This patch fixes all the problems I noticed.
gdb/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
* python/lib/gdb/function/strfns.py (_MemEq, _StrLen, _StrEq)
(_RegEx): Reformat help text.
* python/lib/gdb/function/caller_is.py (CallerIs, CallerMatches)
(AnyCallerIs, AnyCallerMatches): Reformat help text.
* python/lib/gdb/function/as_string.py (_AsString): Reformat help
text.
* python/lib/gdb/command/xmethods.py (InfoXMethod)
(EnableXMethod, DisableXMethod): Remove help indentation.
Capitalize meta-syntactic variables.
* python/lib/gdb/command/unwinders.py (InfoUnwinder)
(EnableUnwinder, DisableUnwinder): Remove help indentation.
Capitalize meta-syntactic variables.
* python/lib/gdb/command/explore.py (ExploreCommand)
(ExploreValueCommand, ExploreTypeCommand): Reformat help text.
* python/lib/gdb/command/type_printers.py (InfoTypePrinter)
(EnableTypePrinter, DisableTypePrinter): Remove help indentation.
* python/lib/gdb/command/pretty_printers.py (InfoPrettyPrinter):
Remove help indentation.
(EnablePrettyPrinter, DisablePrettyPrinter): Likewise.
* python/lib/gdb/command/frame_filters.py (EnableFrameFilter)
(DisableFrameFilter, SetFrameFilterPriority)
(ShowFrameFilterPriority, InfoFrameFilter): Reword help text.
|
|
PR tui/28819 points out that, in the TUI, the C-j and C-m keys cannot
be bound differently in one's ~/.inputrc. However, this works in
other readline applications.
The bug is that the TUI uses curses' "nl" mode, which causes wgetch to
return the same value for both keys. There is a "nonl" mode, but it
also affects output.
This patch fixes the bug by arranging to call nonl before reading a
key and then nl afterward. This avoids any potential problem with
changing the output if gdb was to use nonl globally.
gdb/ChangeLog
2018-10-06 Tom Tromey <tom@tromey.com>
PR tui/28819:
* tui/tui-io.c (gdb_wgetch): New function.
(tui_mld_getc, tui_getc): Use it.
|
|
Commit 73f1bd769a5 ("Make the "info proc" documentation more
consistent.") updated the output from "help info proc", but forgot to
update the test on gdb.base/info-proc.exp. This obvious patch does
that.
Checked-in as obvious.
gdb/testsuite/ChangeLog:
2018-10-06 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/info-proc.exp: Update string expected from "help info
proc".
|
|
Rainer pointed out that -Wshadow=local broke the Solaris build.
This fixes it.
gdb/ChangeLog
2018-10-05 Tom Tromey <tom@tromey.com>
* sol-thread.c (sol_thread_target::wait): Rename inner
"save_ptid".
|
|
This adds -Wshadow=local to configure.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* warning.m4 (AM_GDB_WARNINGS): Add -Wshadow=local.
gdb/gdbserver/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
|
|
-Wshadow=local pointed out that the shadowing in gdbscm_frame_read_var
means that the ultimate call to read_var_value will always be passed
block==NULL. The fix is to remove the inner declaration.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* guile/scm-frame.c (gdbscm_frame_read_var): Remove inner
declaration of "block".
|
|
-Wshadow=local caught this buglet. fdwalk redeclares "result" in the
inner scope, meaning that this function will always return 0, even on
error.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* common/filestuff.c (fdwalk): Remove inner declaration of
"result".
|
|
-Wshadow=local found this latent bug. msp430-tdep.c does:
const gdb_byte *arg_bits;
{
/* Aggregates of any size are passed by reference. */
gdb_byte struct_addr[4];
[...
arg_bits = struct_addr;
}
... use arg_bits
Here, arg_bits can point to an object that's gone out of scope.
The fix is to hoist the inner "struct_addr" buffer to an outer scope,
and rename it to avoid shadowing.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* msp430-tdep.c (msp430_push_dummy_call): Rename inner
"structs_addr" and hoist declaration.
|
|
This is one of the uglier changes to avoid local shadowing. Because
obstack.h uses statement expressions, in some cases a nested obstack
call will result in shadowing. Rather than try to fix obstack.h, this
patch simply works around the one instance of this problem.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* linux-tdep.c (linux_make_mappings_corefile_notes): Introduce new
variable "size".
|
|
This changes a couple of spots in mdebugread to use std::string rather
than manual management. This is simpler, and also avoids shadowing by
renaming the variable in question.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* mdebugread.c (parse_partial_symbols): Use std::string.
|
|
This fixes a few instances of shadowing in gdbserver. These are all
simple fixes.
gdb/gdbserver/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* server.c (handle_status): Rename inner "thread".
(process_serial_event): Declare "res" in 'm' case.
* linux-low.c (last_thread_of_process_p, find_lwp_pid)
(iterate_over_lwps): Rename inner "thread".
(linux_qxfer_libraries_svr4): Rename inner "len".
* gdbthread.h (find_thread_in_random): Rename inner "thread".
|
|
This fixes all the straightforward -Wshadow=local warnings in gdb. A
few standard approaches are used here:
* Renaming an inner (or outer, but more commonly inner) variable;
* Lowering a declaration to avoid a clash;
* Moving a declaration into a more inner scope to avoid a clash,
including the special case of moving a declaration into a loop header.
I did not consider any of the changes in this patch to be particularly
noteworthy, though of course they should all still be examined.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* ctf.c (SET_ARRAY_FIELD): Rename "u32".
* p-valprint.c (pascal_val_print): Split inner "i" variable.
* xtensa-tdep.c (xtensa_push_dummy_call): Declare "i" in loop
header.
* xstormy16-tdep.c (xstormy16_push_dummy_call): Declare "val" in
more inner scope.
* xcoffread.c (read_xcoff_symtab): Rename inner "symbol".
* varobj.c (varobj_update): Rename inner "newobj",
"type_changed".
* valprint.c (generic_emit_char): Rename inner "buf".
* valops.c (find_overload_match): Rename inner "temp".
(value_struct_elt_for_reference): Declare "v" in more inner
scope.
* v850-tdep.c (v850_push_dummy_call): Rename "len".
* unittests/array-view-selftests.c (run_tests): Rename inner
"vec".
* tui/tui-stack.c (tui_show_frame_info): Declare "i" in loop
header.
* tracepoint.c (merge_uploaded_trace_state_variables): Declare
"tsv" in more inner scope.
(print_one_static_tracepoint_marker): Rename inner
"tuple_emitter".
* tic6x-tdep.c (tic6x_analyze_prologue): Declare "inst" lower.
(tic6x_push_dummy_call): Don't redeclare "addr".
* target-float.c: Declare "dto" lower.
* symtab.c (lookup_local_symbol): Rename inner "sym".
(find_pc_sect_line): Rename inner "pc".
* stack.c (print_frame): Don't redeclare "gdbarch".
(return_command): Rename inner "gdbarch".
* s390-tdep.c (s390_prologue_frame_unwind_cache): Renam inner
"sp".
* rust-lang.c (rust_internal_print_type): Declare "i" in loop
header.
* rs6000-tdep.c (ppc_process_record): Rename inner "addr".
* riscv-tdep.c (riscv_push_dummy_call): Declare "info" in inner
scope.
* remote.c (remote_target::update_thread_list): Don't redeclare
"tp".
(remote_target::process_initial_stop_replies): Rename inner
"thread".
(remote_target::remote_parse_stop_reply): Don't redeclare "p".
(remote_target::wait_as): Don't redeclare "stop_reply".
(remote_target::get_thread_local_address): Rename inner
"result".
(remote_target::get_tib_address): Likewise.
|
|
If a vector that we try to write using file_write is empty, we may end
up passing NULL to fwrite, which triggers UBSan:
.../gdb/dwarf-index-write.c:73:14: runtime error: null pointer passed as argument 1, which is declared to never be null
Avoid it by skipping the write if the vector is empty.
gdb/ChangeLog:
* dwarf-index-write.c (file_write): Don't write if the vector is
empty.
|
|
When using cpychecker, we run into:
...
gdb/python/py-progspace.c: \
In function ‘PyObject* pspy_solib_name(PyObject*, PyObject*)’:
gdb/python/py-progspace.c:370:25: error: Mismatching type in call to \
PyArg_ParseTuple with format code "K" [-Werror]
if (!PyArg_ParseTuple (args, GDB_PY_LLU_ARG, &pc))
argument 3 ("&pc") had type
"gdb_py_longest *" (pointing to 64 bits)
but was expecting
"long long unsigned int *" (pointing to 64 bits)
for format code "K"
...
Fix this fixing the type of the variable.
Build and reg-tested on x86_64-linux.
2018-10-05 Tom de Vries <tdevries@suse.de>
* python/py-progspace.c (pspy_solib_name): Fix type mismatch in
PyArg_ParseTuple call.
|
|
When using cpychecker, we run into this error:
...
gdb/python/py-record-btrace.c: \
In function ‘PyObject* recpy_bt_goto(PyObject*, PyObject*)’:
gdb/python/py-record-btrace.c:783:25: error: Mismatching type in call to \
PyArg_ParseTuple with format code "O" [-Werror]
if (!PyArg_ParseTuple (args, "O", &obj))
argument 3 ("&obj") had type
"const struct recpy_element_object * *"
but was expecting
"struct PyObject * *"
for format code "O"
...
Fix this by using a new variable of the expected type instead.
Build and reg-tested on x86_64-linux.
2018-10-05 Tom de Vries <tdevries@suse.de>
* python/py-record-btrace.c (recpy_bt_goto): Fix type mismatch in
PyArg_ParseTuple call.
|
|
This is just to make sure one of the parameters doesn't end past
the 80 characters limit. And while at it, since all parameters were
on their own line except the first two that were listed on the same
line, it felf more consistent to just split them to have each and
every parameter on their own line.
gdb/ChangeLog:
* psymtab.c (recursively_search_psymtabs): Reformat parameters
to avoid exceeding 80 characters per line limit.
Tested by rebuilding GDB on x86_64-linux.
|
|
This removes the SHORT_FIRST_MESSAGE case from complaints, leaving
only a single case. This allows for the removal of the last argument
to clear_complaints, and also simplifies complaint_internal, removing
an extra allocation in the process.
After this, the "./gdb -iex 'set complaint 1' -nx ./gdb" example will
show:
Reading symbols from ./gdb...
During symbol reading: .debug_ranges entry has start address of zero [in module /home/tromey/gdb/build/gdb/gdb]
During symbol reading: DW_AT_low_pc 0x0 is zero for DIE at 0x17116c1 [in module /home/tromey/gdb/build/gdb/gdb]
During symbol reading: .debug_line address at offset 0xa22f5 is 0 [in module /home/tromey/gdb/build/gdb/gdb]
During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'
During symbol reading: const value length mismatch for 'std::ratio<1, 1000000000>::num', got 8, expected 0
This is a bit wordier but, I think, a bit more clear, as the form of
the message no longer depends on precisely when it was emitted. In
particular if you compare to the output from the 'Clean up "Reading
symbols" output' patch, you can see that earlier gdb would switch from
the prefix-less form to the "During symbol reading" form at a point
that is meaningless to the user (specifically, after psymtab reading
is done and gdb tries to expand a CU).
2018-10-04 Tom Tromey <tom@tromey.com>
* symfile.c (syms_from_objfile_1, finish_new_objfile)
(reread_symbols): Update.
* complaints.h (clear_complaints): Remove argument.
* complaints.c (enum complaint_series): Remove.
(series): Remove global.
(complaint_internal): Update.
(clear_complaints): Remove argument.
gdb/testsuite/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* gdb.cp/maint.exp (test_invalid_name): Update expected output.
* gdb.gdb/complaints.exp (test_short_complaints): Remove.
(test_initial_complaints, test_empty_complaints): Update.
* gdb.dwarf2/dw2-stack-boundary.exp: Update.
|
|
The "no debugging symbols" message can be confusing in some cases, for
example when gdb finds separate debug info for an objfile, but the
separate debug info does not contain symbols.
For example:
(gdb) file /bin/ls
Reading symbols from /bin/ls...
Reading symbols from .gnu_debugdata for /usr/bin/ls...
(No debugging symbols found in .gnu_debugdata for /usr/bin/ls)
(No debugging symbols found in /bin/ls)
Here, I think the second "no debugging symbols" message is redundant
and confusing.
This patch changes gdb to only emit this message when the objfile in
question does not have a separate debug file. So, in the example
above, the output would now read:
(gdb) file /bin/ls
Reading symbols from /bin/ls...
Reading symbols from .gnu_debugdata for /usr/bin/ls...
(No debugging symbols found in .gnu_debugdata for /usr/bin/ls)
2018-10-04 Tom Tromey <tom@tromey.com>
* symfile.c (symbol_file_add_with_addrs): Do not print "no
debugging symbols" message if there is a separate debug objfile.
|
|
This patch is another attempt to fix PR cli/19551. Unlike my previous
attempt, it doesn't print progress. Instead, it just changes some
messages and adds newlines to make the output a bit nicer.
It also removes the "done." text that was previously emitted. The
idea here is that it is obvious when gdb is done reading debug info,
as it starts then doing something else; and that while this message
did not provide much benefit to users, it did make it harder to make
the output clean.
After this change the output from "./gdb -iex 'set complaint 1' -nx ./gdb"
reads:
Reading symbols from ./gdb...
.debug_ranges entry has start address of zero [in module /home/tromey/gdb/build/gdb/gdb]
DW_AT_low_pc 0x0 is zero for DIE at 0x17116c1 [in module /home/tromey/gdb/build/gdb/gdb]
.debug_line address at offset 0xa22f5 is 0 [in module /home/tromey/gdb/build/gdb/gdb]
During symbol reading, unsupported tag: 'DW_TAG_unspecified_type'.
During symbol reading, const value length mismatch for 'std::ratio<1, 1000000000>::num', got 8, expected 0.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
PR cli/19551:
* symfile.c (symbol_file_add_with_addrs): Update output.
* psymtab.c (require_partial_symbols): Update output.
gdb/testsuite/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
PR cli/19551:
* lib/mi-support.exp (mi_gdb_file_cmd): Update.
* lib/gdb.exp (gdb_file_cmd): Update.
* gdb.stabs/weird.exp (print_weird_var): Update.
* gdb.server/solib-list.exp: Update.
* gdb.multi/remove-inferiors.exp (test_remove_inferiors): Update.
* gdb.mi/mi-cli.exp: Update.
* gdb.linespec/linespec.exp: Update.
* gdb.dwarf2/dw2-stack-boundary.exp: Update.
* gdb.dwarf2/dw2-objfile-overlap.exp: Update.
* gdb.cp/cp-relocate.exp: Update.
* gdb.base/sym-file.exp: Update.
* gdb.base/relocate.exp: Update.
* gdb.base/readnever.exp: Update.
* gdb.base/print-symbol-loading.exp (test_load_core): Update.
* gdb.base/kill-detach-inferiors-cmd.exp: Update.
* gdb.base/dbx.exp (gdb_file_cmd): Update.
* gdb.base/code_elim.exp: Update.
* gdb.base/break-unload-file.exp (test_break): Update.
* gdb.base/break-interp.exp (test_attach_gdb): Update.
* gdb.base/break-idempotent.exp (force_breakpoint_re_set):
Update.
* gdb.base/attach.exp (do_attach_tests): Update.
* gdb.base/sepdebug.exp: Update.
* gdb.python/py-section-script.exp: Update.
|
|
Currently complaints are not always printed with a newline. For
example, when I run gdb on itself, I see output like:
(gdb) set complaints 5
(gdb) file ./gdb/gdb
Reading symbols from ./gdb/gdb...DW_AT_low_pc 0x0 is zero for DIE at 0x437dd4 [in module /home/tromey/gdb/build/gdb/gdb]....debug_line address at offset 0x21bf9 is 0 [in module /home/tromey/gdb/build/gdb/gdb]...DW_AT_low_pc 0x0 is zero for DIE at 0x5a85dd [in module /home/tromey/gdb/build/gdb/gdb]....debug_line address at offset 0x2dc2d is 0 [in module /home/tromey/gdb/build/gdb/gdb]...DW_AT_low_pc 0x0 is zero for DIE at 0xab6033 [in module /home/tromey/gdb/build/gdb/gdb]....debug_line address at offset 0x4f683 is 0 [in module /home/tromey/gdb/build/gdb/gdb]...DW_AT_low_pc 0x0 is zero for DIE at 0x10028f0 [in module /home/tromey/gdb/build/gdb/gdb]....debug_line address at offset 0x75edf is 0 [in module /home/tromey/gdb/build/gdb/gdb]...DW_AT_low_pc 0x0 is zero for DIE at 0x1021364 [in module /home/tromey/gdb/build/gdb/gdb]....debug_line address at offset 0x76f62 is 0 [in module /home/tromey/gdb/build/gdb/gdb]...done.
That's one very long line. I find it quite difficult to read that,
and I thought it would be better with some newlines, which is what
this patch does. Now the output looks like:
(gdb) file ./gdb
Reading symbols from ./gdb...
DW_AT_low_pc 0x0 is zero for DIE at 0x437dd4 [in module /home/tromey/gdb/build/gdb/gdb]
.debug_line address at offset 0x21bf9 is 0 [in module /home/tromey/gdb/build/gdb/gdb]
DW_AT_low_pc 0x0 is zero for DIE at 0x5a85dd [in module /home/tromey/gdb/build/gdb/gdb]
.debug_line address at offset 0x2dc2d is 0 [in module /home/tromey/gdb/build/gdb/gdb]
done.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
PR cli/22234:
* complaints.c: Emit \n.
gdb/testsuite/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
PR cli/22234:
* gdb.dwarf2/dw2-stack-boundary.exp: Update expected output.
* gdb.gdb/complaints.exp (test_short_complaints): Update expected
output.
|
|
While working on this series, I found some unfiltered prints that
didn't make sense -- many things, like complaints, are filtered, while
their context (in this case the "Reading symbols ..." messages) may
not be.
This patch changes some spots in symbol reading to use filtered
prints. I think this is preferable overall; in fact I'd go farther
and say that unfiltered printing should just be removed.
One of these spots was not strictly related (the change to
dump_psymtab), but I left it in partly because it makes psymtab.c
"unfiltered-clean", and partly because it is an example of filtered
and unfiltered printing being mixed in the same function.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* symfile.c (symbol_file_add_with_addrs, symbol_file_clear)
(separate_debug_file_exists, find_separate_debug_file)
(add_symbol_file_command, reread_symbols, allocate_symtab)
(allocate_compunit_symtab): Use filtered printing, not
unfiltered.
* psymtab.c (require_partial_symbols, dump_psymtab)
(allocate_psymtab): Use filtered printing, not unfiltered.
|
|
complaint_internal had an off-by-one error, where it would allow one
extra complaint to be issued.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* complaints.c (complaint_internal): Correctly check complaint
count.
|
|
There were a couple of leftovers from earlier patches in
complaints.[ch]. This removes them.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* complaints.h (struct complaints): Remove declaration.
* complaints.c (clear_complaints): Remove an unused variable.
|
|
While re-testing the complaint series, I saw some unresolved tests in
attach.exp. In particular, the tests were failing because the pager
was active.
This is partly a new problem, introduced because that series changes
some prints from unfiltered to filtered. However, it is also a latent
bug, which you can see by shrinking your window very small and then
running the test.
This patch avoids the problem by passing -quiet to gdb and arranging
to set the window height and width in one other test.
Arguably instead of -quiet we should disable the pager during gdb's
welcome message. I can do that if it seems desirable; but meanwhile
this patch is safe.
gdb/testsuite/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* gdb.base/attach.exp (test_command_line_attach_run): Use -quiet;
set width and height to 0.
(test_command_line_attach_run): Use -quiet.
|
|
Joel asked me to add myself to gdb/MAINTAINERS. Done as follows, fixing two
incorrectly indented lines on the way. Installed on master.
* MAINTAINERS (Write After Approval): Add self.
|
|
This avoids a couple of uninitialized warnings from gcc by
initializing the object in question. The one in coffread.c seems like
it could be a latent bug. The one in scm-value.c is harmless, but GCC
can't see that.
gdb/ChangeLog
2018-10-03 Tom Tromey <tom@tromey.com>
* guile/scm-value.c (gdbscm_value_to_string): Initialize
"buffer_contents".
* coffread.c (coff_symtab_read): Initialize "newobj".
|
|
I get the following error with gcc 6.3.0:
/home/simark/src/binutils-gdb/gdb/dwarf2read.c: In function 'void read_func_scope(die_info*, dwarf2_cu*)':
/home/simark/src/binutils-gdb/gdb/dwarf2read.c:13838:12: error: types may not be defined in a for-range-declaration [-Werror]
for (struct symbol *sym : template_args)
^~~~~~
Removing the struct keyword fixes it.
gdb/ChangeLog:
* dwarf2read.c (read_func_scope): Remove struct keyword in
range-based for.
|
|
This adds --enable-ubsan to gdb's configure. By default it is enabled
in development mode, and disabled otherwise. This passes both
-fsanitize=undefined and -fno-sanitize-recover=undefined to
compilations, so that undefined behavior violations will be sure to
cause test failures.
gdb/ChangeLog
2018-10-03 Tom Tromey <tom@tromey.com>
* README: Mention --enable-ubsan.
* NEWS: Mention --enable-ubsan.
* acinclude.m4: Include sanitize.m4.
* configure: Rebuild.
* configure.ac: Call AM_GDB_UBSAN.
* sanitize.m4: New file.
gdb/doc/ChangeLog
2018-10-03 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Configure Options): Document --enable-ubsan.
|
|
-fsanitize=undefined pointed out undefined behavior in
dump_raw_expression like:
runtime error: load of value 2887952, which is not a valid value for type 'exp_opcode'
dump_raw_expression will try to print the opcode for each element of
the expression, even when it is not valid. To allow this, but have it
avoid undefined behavior, this patch sets the underlying type of enum
exp_opcode, and arranges for op_name to handle invalid opcodes more
nicely.
Before this patch, debug-expr.exp shows:
Dump of expression @ 0x60f000007750, before conversion to prefix form:
Language c, 8 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_TYPE 89 Y...............
<unknown 3851920> 107820862850704 ..:..b..........
2 OP_TYPE 89 Y...............
3 OP_VAR_VALUE 40 (...............
4 <unknown 2807568> 107820861806352 ..*..b..........
5 <unknown 2806368> 107820861805152 `.*..b..........
6 OP_VAR_VALUE 40 (...............
7 UNOP_MEMVAL_TYPE 57 9...............
Afterward, the output is:
Dump of expression @ 0x4820f90, before conversion to prefix form:
Language c, 8 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_TYPE 89 Y...............
1 unknown opcode: 176 75444400 .0..............
2 OP_TYPE 89 Y...............
3 OP_VAR_VALUE 40 (...............
4 OP_BOOL 74616912 P.r.............
5 unknown opcode: 128 74615680 ..r.............
6 OP_VAR_VALUE 40 (...............
7 UNOP_MEMVAL_TYPE 57 9...............
gdb/ChangeLog
2018-10-03 Tom Tromey <tom@tromey.com>
* expression.h (enum exp_opcode): Use uint8_t as base type.
* expprint.c (op_name): Handle invalid opcodes.
|
|
-fsanitize=undefined pointed out this error:
runtime error: load of value 2887952, which is not a valid value for type 'exp_opcode'
This happens in gdb.ada/complete.exp when processing "complete p
my_glob". This does not parse, so the Ada parser throws an exception;
but then the code in parse_exp_in_context_1 accepts the expression
anyway. However, as no elements have been written to the expression,
undefined behavior results.
The fix is to notice this case in parse_exp_in_context_1. This patch
also adds an assertion to prefixify_expression to enforce this
pre-existing constraint.
gdb/ChangeLog
2018-10-03 Tom Tromey <tom@tromey.com>
* parse.c (prefixify_expression): Add assert.
(parse_exp_in_context_1): Throw exception if the expression is
empty.
|
|
-fsanitize=undefined pointed out that read_signed_leb128 had an
undefined left-shift when processing the final byte of a 64-bit leb:
runtime error: left shift of 127 by 63 places cannot be represented in type 'long int'
and an undefined negation:
runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself
Both of these problems are readily avoided by havinng
read_signed_leb128 work in an unsigned type, and then casting to the
signed type at the return.
gdb/ChangeLog
2018-10-03 Tom Tromey <tom@tromey.com>
* dwarf2read.c (read_signed_leb128): Work in ULONGEST.
|
|
-fsanitize=undefined pointed out that c-exp.y relied on undefined
behavior here:
if (c != 'l' && c != 'u')
n *= base;
...when a large hex constant "just fit" into a LONGEST, causing the
high bit to be set.
This fixes the problem by having the function work in an unsigned
type.
gdb/ChangeLog
2018-10-03 Tom Tromey <tom@tromey.com>
* c-exp.y (parse_number): Work in unsigned. Remove casts.
|
|
-fsanitize=undefined pointed out an undefined shift of a negative
value in read_subrange_type. The fix is to do the work in an unsigned
type, where this is defined.
gdb/ChangeLog
2018-10-03 Tom Tromey <tom@tromey.com>
* dwarf2read.c (read_subrange_type): Make "negative_mask"
unsigned.
|
|
-fsanitize=undefined showed that extract_integer could left-shift a
negative value, which is undefined. This patch fixes the problem by
doing all the work in an unsigned type. This relies on
implementation-defined behavior, but I tend to think we are on safe
ground there. (Also, if need be, violations of this could probably be
detected, either by configure or by a static_assert.)
gdb/ChangeLog
2018-10-03 Tom Tromey <tom@tromey.com>
* findvar.c (extract_integer): Do work in an unsigned type.
|
|
-fsanitize=undefined complains about using operator~ on various enum
types that are used with DEF_ENUM_FLAGS_TYPE. This patch fixes these
problems by explicitly setting the base type for these enums to
unsigned. It also adds a static assert to enum_flags to ensure that
future enums used this way have an unsigned underlying type.
gdb/ChangeLog
2018-10-03 Tom Tromey <tom@tromey.com>
* common/enum-flags.h (enum_flags::operator~): Add static assert.
* symfile-add-flags.h (enum symfile_add_flag): Use unsigned as
base type.
* objfile-flags.h (enum objfile_flag): Use unsigned as base type.
* gdbtypes.h (enum type_instance_flag_value): Use unsigned as base
type.
* c-lang.h (enum c_string_type_values): Use unsigned as base
type.
* btrace.h (enum btrace_thread_flag): Use unsigned as base type.
|
