Here, in dwarfread.c:process_full_comp_unit:
/* Set symtab language to language from DW_AT_language. If the
compilation is from a C file generated by language preprocessors, do
not set the language if it was already deduced by start_subfile. */
if (!(cu->language == language_c
&& COMPUNIT_FILETABS (cust)->language != language_c))
COMPUNIT_FILETABS (cust)->language = cu->language;
in case start_subfile doesn't manage to deduce a language
COMPUNIT_FILETABS(cust)->language ends up as language_unknown, not
language_c. So the condition above evals false and we never set the
language from the cu's language.
gdb/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* dwarf2read.c (process_full_comp_unit): To tell whether
start_subfile managed to deduce a language, test for
language_unknown instead of language_c.
gdb/testsuite/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* gdb.dwarf2/comp-unit-lang.exp: New file.
* gdb.dwarf2/comp-unit-lang.c: New file.
Before this change, trying to evaluate the following Ada expression
yielded a syntax error, even though it's completely legal:
(gdb) p s'first = 'a'
Error in expression, near `'.
The problem lies in the lexer (gdb/ada-lex.l): at the point we reach "'a'",
we're still in the BEFORE_QUAL_QUOTE start condition (the mechanism to
distinguish character literals from other "tick" usages: qualified
expressions and attributes), so we consider that this quote is actually a
separate "tick".
This changes resets the start condition to INITIAL in the
{TICK}[a-zA-Z][a-zA-Z]+ rule (for attributes): attributes activate this
BEFORE_QUAL_QUOTE condition and in this case the above rule is always
executed rather than the <BEFORE_QUAL_QUOTE>"'" one (in flex, it's
always the longest match that is chosen). We now have instead:
(gdb) p s'first = 'a'
$1 = true
gdb/ChangeLog:
* ada-lex.l: Reset the start condition to INITIAL in the rule
that matches attributes.
gdb/testsuite/ChangeLog:
* gdb.ada/attr_ref_and_charlit.exp: New testcase.
* gdb.ada/attr_ref_and_charlit/foo.adb: New file.
Tested on x86_64-linux, no regression.
This change introduces a new function, dwarf2_string_attr(), which is
a wrapper for dwarf2_attr(). dwarf2read.c has been updated to
call dwarf2_string_attr in most instances where a string-valued
attribute is decoded to produce a string value. In most cases, it
simplifies the code; in some instances, the complexity of the code
remains unchanged.
I performed this change by looking for instances where the
result of DW_STRING was used in an assignment. Many of these
had a pattern which (roughly) looks something like this:
struct attribute *attr = NULL;
attr = dwarf2_attr (die, name, cu);
if (attr != NULL && DW_STRING (attr))
{
const char *str;
...
str = DW_STRING (attr);
... /* Use str in some fashion. */
}
Code of this form is transformed to look like this instead:
const char *str;
str = dwarf2_string_attr (die, name, cu)
if (str != NULL)
{
...
/* Use str in some fashion. */
...
}
In addition to invoking dwarf2_attr() and DW_STRING(),
dwarf2_string_attr() checks to make sure that the attribute's
`form' field matches one of DW_FORM_strp, DW_FORM_string, or
DW_FORM_GNU_strp_alt. If it does not match one of these forms,
it will return a NULL value in addition to calling complaint().
An earlier version of this patch did this type checking for one
particular instance where a string attribute was being decoded.
The situation that I was attempting to handle in that earlier patch is
this:
The Texas Instruments compiler uses the encoding for
DW_AT_MIPS_linkage_name for other purposes. TI uses the encoding,
0x2007, for TI_AT_TI_end_line which, unlike DW_AT_MIPS_linkage_name,
does not have a string-typed value. In this instance, GDB was attempting
to use an integer value as a string pointer, with predictable results.
(GDB would die with a segmentation fault.)
I've added a test which reproduces the problem that I was orignally
wanting to fix. It uses DW_AT_MIPS_linkage name with an associate
value which is a string, and again, where the value is a small
integer.
My test case causes GDB to segfault in an unpatched GDB. There
will be two PASSes in a patched GDB.
Unpatched GDB:
(gdb) ptype f
ERROR: Process no longer exists
UNRESOLVED: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f
ERROR: Couldn't send ptype g to GDB.
UNRESOLVED: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g
Patched GDB:
(gdb) ptype f
type = bool ()
(gdb) PASS: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f
ptype g
type = bool ()
(gdb) PASS: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g
I see no regressions on an x86_64 native target.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_string_attr): New function.
(lookup_dwo_unit, process_psymtab_comp_unit_reader)
(dwarf2_compute_name, dwarf2_physname, find_file_and_directory)
(read_call_site_scope, namespace_name, guess_full_die_structure_name)
(anonymous_struct_prefix, prepare_one_comp_unit): Use
dwarf2_string_attr in place of dwarf2_attr and DW_STRING.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-bad-mips-linkage-name.c: New file.
* gdb.dwarf2/dw2-bad-mips-linkage-name.exp: New file.
While handling "vFile:pread:" packets, gdbserver would read the
number of bytes requested regardless of whether this would fit
into the reply packet. gdbserver would then return a packet's
worth of data and discard the remainder. When accessing large
binaries GDB (via BFD) routinely makes large "vFile:pread:"
requests, resulting in gdbserver allocating large unnecessary
buffers and reading some portions of the file many times over.
This commit causes gdbserver to limit the number of bytes to be
read to a sensible maximum prior to allocating buffers and reading
data.
gdb/gdbserver/ChangeLog:
* hostio.c (handle_pread): Do not attempt to read more data
than hostio_reply_with_data can fit in a packet.
On some older versions of GNU/Linux, gdbserver now fails to build
due to an undefined reference to NT_ARM_VFP. Same issue on Android,
where this macros is undefined until Android API level 21 (Android
5.0 "Lollipop").
This patch modifies linux-aarch32-low.c to define that macros when
not already defined.
gdb/gdbserver/ChangeLog:
* linux-aarch32-low.c (NT_ARM_VFP): Define if not already defined.
2015-08-18 Sandra Loosemore <sandra@codesourcery.com>
gdb/
* remote.c (strprefix): New.
(remote_parse_stop_reply): Use strprefix instead of strncmp
to ensure exact match of keyword.
In commit 18989b3c56 I broke the creation
of gdb's info manual; I added a new section without adding a suitable
menu entry.
This commit adds the missing menu entry and fixes the build of gdb's
info manual.
gdb/doc/ChangeLog:
* gdb.texinfo (GDB Files): Add 'File Caching' menu entry.
This patch adds a new debug flag bfd-cache, which when set to non-zero
produces debugging log messages relating to gdb's bfd cache.
gdb/ChangeLog:
* gdb_bfd.c (debug_bfd_cache): New variable.
(show_bfd_cache_debug): New function.
(gdb_bfd_open): Add debug logging.
(gdb_bfd_ref): Likewise.
(gdb_bfd_unref): Likewise.
(_initialize_gdb_bfd): Add new set/show command.
* NEWS: Mention new command.
gdb/doc/ChangeLog:
* gdb.texinfo (File Caching): Document "set/show debug bfd-cache".
In some rare maintainer cases it is desirable to be able to disable bfd
sharing. This patch adds new commands maintenance set/show commands for
bfd-sharing, allowing gdb's bfd cache to be turned off.
gdb/ChangeLog:
* gdb_bfd.c (bfd_sharing): New variable.
(show_bfd_sharing): New function.
(gdb_bfd_open): Check bfd_sharing variable.
(_initialize_gdb_bfd): Add new set/show command.
* NEWS: Mention new command.
gdb/doc/ChangeLog:
* gdb.texinfo (Maintenance Commands): Move documentation of "main
info bfds" to...
(File Caching): A New section. Outline bfd caching, and add new
description for "main set/show bfd-sharing".
Within gdb open bfd objects are reused where possible if an attempt is
made to reopen a file that is already being debugged. To spot if the on
disc file has changed gdb currently examines the mtime of the file and
compares it to the mtime of the open bfd in the cache.
A problem exists when the on disc file is being rapidly regenerated, as
happens, for example, with automated testing. In some cases the file is
generated so quickly that the mtime appears not to change, while the on
disc file has changed.
This patch extends the bfd cache to also hold the file size of the file,
the inode of the file, and the device id of the file; gdb can then
compare filename, file size, mtime, inode, and device id to determine if
an existing bfd object can be reused.
gdb/ChangeLog:
* gdb_bfd.c (struct gdb_bfd_data): Add size, inode, and device id
field.
(struct gdb_bfd_cache_search): Likewise.
(eq_bfd): Compare the size, inode, and device id fields.
(gdb_bfd_open): Initialise the size, inode, and device id fields.
(gdb_bfd_ref): Likewise.
(gdb_bfd_unref): Likewise.
Markus reported that ASNS breaks target record-btrace. In particular,
the gdb.btrace/multi-thread-step.exp test fails (both with BTS and PT
tracing) with a crash in py-inferior.c:
Program received signal SIGSEGV, Segmentation fault.
0x00000000006aa40d in add_thread_object (tp=0x27d32d0)
at /users/mmetzger/team/gdb/git/gdb/python/py-inferior.c:337
337 entry->next = inf_obj->threads;
My machine doesn't support BTS nor PT, so I missed this...
Disabling ASNS temporarily on x86 until this is addressed.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-08-18 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_nat_always_non_stop_p): If the linux_ops
target implements to_always_non_stop_p, call it.
* x86-linux-nat.c (x86_linux_always_non_stop_p): New function.
(x86_linux_create_target): Install it as to_always_non_stop_p
method.
In D, all named enums are explicitly scoped (the C++ equivalent of enum class)
so they should be handled as such in the language-specific symbol lookup
routines. However so as to support D compilers that don't emit enums as
DW_AT_enum_class, need to make sure that appropriate checks for
TYPE_DECLARED_CLASS are done.
gdb/ChangeLog
* d-exp.y (type_aggregate_p): New function.
(PrimaryExpression : TypeExp '.' IdentifierExp): Use it.
(classify_inner_name): Likewise.
* d-namespace.c (d_lookup_nested_symbol): Handle TYPE_CODE_ENUM.
One of the build slaves shows this error running explicit.exp:
(gdb) strace -m gdbfoobarbaz
Remote failure reply: E.In-process agent library not loaded in process.
Fast and static tracepoints unavailable.
(gdb) FAIL: gdb.linespec/explicit.exp: strace -m gdbfoobarbaz
There are two big problems with this test:
1) The expected output is actually not what the test is meant to test for.
2) This test should really only run where it is supported.
This is most easily fixed by moving the test to gdb.trace/strace.exp.
gdb/testsuite/ChangeLog
* gdb.linespec/explicit.exp: Move strace test from here ...
* gdb.trace/strace.exp: ... to here.
Invoking either of the above commands on an inferior that's not running
triggers the following assert failure:
.../binutils-gdb/gdb/thread.c:514: internal-error: any_thread_of_process: Assertion `pid != 0' failed.
The fix is straightforward. This patch also adds a test to check the
basic functionality of these commands, along with testing this fix in
particular. Tested on x86_64 Linux.
gdb/ChangeLog:
* inferior.c (detach_inferior_command): Don't call
any_thread_of_process when pid is 0.
(kill_inferior_command): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/kill-detach-inferiors-cmd.exp: New test file.
* gdb.base/kill-detach-inferiors-cmd.c: New test file.
The "source centric" /m option to the disassemble command is often
unhelpful, e.g., in the presence of optimized code.
This patch adds a /s modifier that is better.
For one, /m only prints instructions from the originating source file,
leaving out instructions from e.g., inlined functions from other files.
gdb/ChangeLog:
PR gdb/11833
* NEWS: Document new /s modifier for the disassemble command.
* cli/cli-cmds.c (disassemble_command): Add support for /s.
(_initialize_cli_cmds): Update online docs of disassemble command.
* disasm.c: #include "source.h".
(struct deprecated_dis_line_entry): Renamed from dis_line_entry.
All uses updated.
(dis_line_entry): New struct.
(hash_dis_line_entry, eq_dis_line_entry): New functions.
(allocate_dis_line_table): New functions.
(maybe_add_dis_line_entry, line_has_code_p): New functions.
(dump_insns): New arg end_pc. All callers updated.
(do_mixed_source_and_assembly_deprecated): Renamed from
do_mixed_source_and_assembly. All callers updated.
(do_mixed_source_and_assembly): New function.
(gdb_disassembly): Handle /s (DISASSEMBLY_SOURCE).
* disasm.h (DISASSEMBLY_SOURCE_DEPRECATED): Renamed from
DISASSEMBLY_SOURCE. All uses updated.
(DISASSEMBLY_SOURCE): New macro.
* mi/mi-cmd-disas.c (mi_cmd_disassemble): New modes 4,5.
gdb/doc/ChangeLog:
* gdb.texinfo (Machine Code): Update docs for mixed source/assembly
disassembly.
(GDB/MI Data Manipulation): Update docs for new disassembly modes.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-disassemble.exp: Update.
* gdb.base/disasm-optim.S: New file.
* gdb.base/disasm-optim.c: New file.
* gdb.base/disasm-optim.h: New file.
* gdb.base/disasm-optim.exp: New file.
A recent patch introduced a variable named `typename' into d-exp.y,
and one of the --enable-with-cxx build slaves consequently failed to compile
this. This patch simply adds an underscore into the name to avoid the
reserved word.
gdb/ChangeLog
* d-exp.y (PrimaryExpression : TypeExp '.' IdentifierExp): Rename
`typename' to `type_name' to avoid C++ reserved word.
The locations patch I recently committed contains macro definitions
such as:
This causes an ARI error to be emitted by the server ("Do not use PTR, ISO C
90 implies `void *'"). While this ARI error is bogus in this context,
it is just easiest to squash the error completely by renaming the macro
parameters.
gdb/ChangeLog
* location.c (EL_TYPE, EL_LINESPEC, EL_PROBE, EL_ADDRESS)
(EL_EXPLICIT, EL_STRING): Change macro parameter to "P" to
silence ARI errors.
For some time now, GDB has permitted target-side evaluation of
breakpoint conditions. On targets that support this feature, GDB
may output an "evaluated-by" field into the breakpoint reply.
This patch adds handling for this option, and outputs a default
pattern to optionally recognize (and ignore) this pattern in the
reply.
gdb/testsuite/ChangeLog
* lib/mi-support.exp (mi_make_breakpoint): Add option/handling for
"evaluated-by".
This fixes four ARI warnings found in d-exp.y.
This is comprised of three uses of the && or || at the end of a line, and one
use of sprintf.
gdb/ChangeLog
* d-exp.y (PrimaryExpression : TypeExp '.' IdentifierExp): Use
xstrprintf instead of malloc and sprintf.
(PrimaryExpression : IdentifierExp): Avoid operator at end of line.
(lex_one_token): Likewise.
This tag allows debugging of MIPS position independent executables
and provides access to shared library information.
gdb/gdbserver/
* linux-low.c (get_r_debug): Handle DT_MIPS_RLD_MAP_REL.
gdb/
* solib-svr4.c (read_program_header): Add base_addr argument to
report the runtime address of the segment.
(find_program_interpreter): Update read_program_header call to pass
a NULL pointer for the new argument.
(scan_dyntag): Add ptr_addr argument to report the runtime address
of the tag payload.
(scan_dyntag_auxv): Likewise and use thew new base_addr argument of
read_program_header to get the base address of the dynamic segment.
(elf_locate_base): Update uses of scan_dyntag, scan_dyntag_auxv and
read_program_header.
(elf_locate_base): Scan for and handle DT_MIPS_RLD_MAP_REL.
This makes it so that alternating '.' and identifier tokens are resolved to
symbols as early as possible, which should all the addition of D properties -
such as EXP.sizeof and EXP.typeof - without the shift/reduce conflicts that
would occur in the current parsing strategy.
gdb/ChangeLog
* d-exp.y (%union): Add voidval.
(%token): Add UNKNOWN_NAME as a token to represent an unclassified
name in the lexing stage.
(PostfixExpression): Move symbol completion handling in grammar here
from PrimaryExpression.
(PrimaryExpression): Move routines to handle resolving identifier
tokens in the grammar here from push_expression_name.
(IdentifierExp): Remove the handling of alternating '.' and identifier
tokens.
(TypeExp): Allow TypeExp to be wrapped in parenthesis in the grammar.
(BasicType): Remove C-style typename rules.
(d_type_from_name, d_module_from_name, push_variable)
(push_fieldnames, push_type_name, push_module_name)
(push_expression_name): Remove.
(lex_one_token): Rename from yylex. Replace pstate with par_state.
(token_and_value): New type.
(token_fifo, popping, name_obstack): New globals.
(classify_name): New function.
(classify_inner_name): Likewise.
(yylex): Likewise.
(d_parse): Initialize token_fifo, popping and name_obstack.
In D, there is the notion of modules, and importing from one to the other,
whether it is a basic, selective or renamed import declaration.
module A;
import X;
void foo() {
import Y : bar;
}
If the compiler emits DW_TAG_imported_declaration at the appropriate locations,
then we can make use of what gdb stores in using_direct when performing
nonlocal symbol lookups.
gdb/ChangeLog
* Makefile.in (SFILES): Add d-namespace.c.
(COMMON_OBS): Add d-namespace.o.
* d-lang.c (d_language_defn): Use d_lookup_symbol_nonlocal as the
la_lookup_symbol_nonlocal callback function pointer.
* d-lang.h (d_lookup_symbol_nonlocal): New declaration.
(d_lookup_nested_symbol): New declaration.
* d-namespace.c: New file.
Valgrind shows:
==17026== Invalid write of size 8
==17026== at 0x54AA80: pending_frame_invalidate (py-unwind.c:477)
==17026== by 0x5AB934: do_my_cleanups (cleanups.c:155)
==17026== by 0x5AB9AF: do_cleanups (cleanups.c:177)
==17026== by 0x54B009: pyuw_sniffer (py-unwind.c:606)
==17026== by 0x755DAC: frame_unwind_try_unwinder (frame-unwind.c:105)
==17026== by 0x755EEE: frame_unwind_find_by_frame (frame-unwind.c:160)
==17026== by 0x750FFA: compute_frame_id (frame.c:454)
==17026== by 0x753BD6: get_prev_frame_if_no_cycle (frame.c:1781)
==17026== by 0x754292: get_prev_frame_always_1 (frame.c:1955)
==17026== by 0x7542DA: get_prev_frame_always (frame.c:1971)
==17026== by 0x7547BE: get_prev_frame (frame.c:2213)
==17026== by 0x7532BD: unwind_to_current_frame (frame.c:1450)
==17026== Address 0xd27b570 is 16 bytes inside a block of size 32 free'd
==17026== at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==17026== by 0x54B276: gdb_Py_DECREF (python-internal.h:185)
==17026== by 0x54B298: py_decref (py-utils.c:34)
==17026== by 0x5AB934: do_my_cleanups (cleanups.c:155)
==17026== by 0x5AB9AF: do_cleanups (cleanups.c:177)
==17026== by 0x54B009: pyuw_sniffer (py-unwind.c:606)
==17026== by 0x755DAC: frame_unwind_try_unwinder (frame-unwind.c:105)
==17026== by 0x755EEE: frame_unwind_find_by_frame (frame-unwind.c:160)
==17026== by 0x750FFA: compute_frame_id (frame.c:454)
==17026== by 0x753BD6: get_prev_frame_if_no_cycle (frame.c:1781)
==17026== by 0x754292: get_prev_frame_always_1 (frame.c:1955)
==17026== by 0x7542DA: get_prev_frame_always (frame.c:1971)
==17026==
Simply invalidate the object before releasing it.
gdb/ChangeLog:
2015-08-13 Pedro Alves <palves@redhat.com>
* python/py-unwind.c (pyuw_sniffer): Install the invalidate
cleanup after the decref cleanup, not before.
BuildBot reminded me that "explicit" is a reserved keyword in C++.
This patch simply renames all the (illegal) uses of "explicit". This should
fix the build errors with --enable-build-with-cxx bots.
gdb/ChangeLog
* break-catch-throw.c (re_set_exception_catchpoint) Rename
reserved C++ keyword "explicit" to "explicit_loc".
* breakpoint.c (create_overlay_event_breakpoint)
(create_longjmp_master_breakpoint)
(create_std_terminate_master_breakpoint)
(create_exception_master_breakpoint, update_static_tracepoint):
Rename reserved C++ keyword "explicit" to "explicit_loc".
* completer.c (collect_explicit_location_matches)
(explicit_location_completer): Rename reserved C++ keyword
"explicit" to "explicit_loc".
* linespec.c (struct linespec) <explicit>: Rename to "explicit_loc".
(canonicalize_linespec, create_sals_line_offset)
(convert_linespec_to_sals, convert_explicit_location_to_sals)
(event_location_to_sals, decode_objc): Rename reserved C++ keyword
"explicit" to "explicit_loc".
* location.c (struct event_location) <explicit>: Rename to
"explicit_loc".
(initialize_explicit_location, new_explicit_location)
(explicit_location_to_string_internal, explicit_location_to_linespec):
Rename reserved C++ keyword "explicit" to "explicit_loc".
* location.h (explicit_location_to_string)
(explicit_location_to_linespec, initialize_explicit_location)
(new_explicit_location): Rename reserved C++ keyword "explicit"
to "explicit_loc".
* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Rename reserved C++
keyword "explicit" to "explicit_loc".
Consider the following declaration:
function Foo (I : Integer) return Integer renames Pack.Bar;
As Foo is not materialized as a routine whose name is derived from Foo,
GDB currently cannot use it:
(gdb) print foo(0)
No definition of "foo" in current context.
However, compilers can emit DW_TAG_imported_declaration in order to
materialize the fact that Foo is actually another name for Pack.Bar.
This commit enhances the DWARF reader to record global renamings (it
used to put global ones in a static block) and enhances the Ada engine
to leverage this information during symbol lookup.
gdb/ChangeLog:
* ada-lang.c: Include namespace.h
(aux_add_nonlocal_symbols): Fix a function name in comment.
(ada_add_block_renamings): New.
(add_nonlocal_symbols): Add global renamings handling.
(ada_lookup_symbol_list_worker): Move the symbol lookup part
to...
(ada_add_all_symbols): ... this new function.
(ada_add_block_symbols): Try to match the input name against the
"using directives list", perform a recursive symbol lookup on
the matched declarations.
* block.h (struct block): Move the_namespace to top-level as
namespace_info. Remove the language_specific field.
(BLOCK_NAMESPACE): Update access to the namespace_info field.
* buildsym.h (using_directives): Rename into...
(local_using_directives): ... this.
(global_using_directives): New.
(struct context_stack): Rename the using_directives field into
local_using_directives.
* buildsym.c (finish_block_internal): Deal with the proper
using directives repository (local or global).
(prepare_for_building): Reset local_using_directives. Assert
that there is no pending global using directive.
(reset_symtab_globals): Reset global_using_directives and
local_using_directives.
(end_symtab_get_static_block): Don't ignore symtabs that have
only using directives.
(push_context): Update references to local_using_directives.
(buildsym_init): Do not reset using_directives.
* cp-support.c: Include namespace.h.
* cp-support.h (struct using_direct): Move to namespace.h.
(cp_add_using_directives): Move to namespace.h.
* cp-namespace.c: Include namespace.h
(cp_add_using_directive): Move to namespace.c, rename it to
add_using_directive, add a "using_directives" argument and use
it as the pending using directives repository. All callers
updated.
* dwarf2read.c (using_directives): New.
(read_import_statement): Call using_directives.
(read_func_scope): Update references to local_using_directives.
(read_lexical_block_scope): Likewise.
(read_namespace): Update the heading comment, call
using_directives.
* namespace.h: New file.
* namespace.c: New file.
* Makefile.in (SFILES): Add namespace.c.
(COMMON_OBS): Add namespace.o
gdb/testsuite/ChangeLog:
* gdb.ada/fun_renaming.exp: New testcase.
* gdb.ada/fun_renaming/fun_renaming.adb: New file.
* gdb.ada/fun_renaming/pack.adb: New file.
* gdb.ada/fun_renaming/pack.ads: New file.
Tested on x86_64-linux. Support for this in GCC is in the pipeline: see
<https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02166.html>.
Keith reported that gdb.base/dso2dso.exp is broken, with the following
error:
| $ make check RUNTESTFLAGS=dso2dso.exp
| [snip]
| Running ../../../src/gdb/testsuite/gdb.base/dso2dso.exp ...
| ERROR: tcl error sourcing ../../../src/gdb/testsuite/gdb.base/dso2dso.exp.
| ERROR: couldn't open
| "../../../src/gdb/testsuite/gdb.base/../../../src/gdb/testsuite/gdb.base/dso2dso-dso1.c":
| no such file or directory
| while executing
| "error "$message""
| (procedure "gdb_get_line_number" line 14)
| invoked from within
| "gdb_get_line_number "STOP HERE" $srcfile_libdso1"
| (file "../../../src/gdb/testsuite/gdb.base/dso2dso.exp" line 60)
| invoked from within
| "source ../../../src/gdb/testsuite/gdb.base/dso2dso.exp"
| ("uplevel" body line 1)
| invoked from within
| "uplevel #0 source ../../../src/gdb/testsuite/gdb.base/dso2dso.exp"
| invoked from within
| "catch "uplevel #0 source $test_file_name""
This happens because gdb_get_line_number will prepend $srcdir/$subdir
if the given filename does not start with "/", and this happens when
GDB was configured using a relative path to the configure script.
When using an absolute path like I do, we avoid the pre-pending that
Keith is seeing.
gdb/testsuite/ChangeLog:
Keith Seitz <keiths@redhat.com>:
* gdb.base/dso2dso.exp: Pass basename of source file in call
to gdb_get_line_number.
Tested on x86_64-linux with both scenarios.
Making all-stop run on top of non-stop caused a small regression
in behavior. This was observed on x86_64-linux. The attached testcase
is in C whereas the investigation was done with an Ada program,
but it's the same scenario, and using a C testcase allows wider testing.
Basically: I am debugging a single-threaded program, and currently
stopped inside a function provided by a shared-library, at a line
calling a subprogram provided by a second shared library, and trying
to "next" over that function call.
Before we changed the default all-stop behavior, we had:
7 Impl_Initialize; -- Stop here and try "next" over this line
(gdb) n
8 return 5; <<-- OK
But now, "next" just stops much earlier:
(gdb) n
0x00007ffff7bd8560 in impl.initialize@plt () from /[...]/lib/libpck.so
What happens is that next stops at a call instruction, which calls
the function's PLT, and GDB fails to notice that the inferior stepped
into a subroutine, and so decides that we're done. We can see another
symptom of the same issue by looking at the backtrace at the point
GDB stopped:
(gdb) bt
#0 0x00007ffff7bd8560 in impl.initialize@plt ()
from /[...]/lib/libpck.so
#1 0x00000000f7bd86f9 in ?? ()
#2 0x00007fffffffdf50 in ?? ()
#3 0x0000000000401893 in a () at /[...]/a.adb:7
Backtrace stopped: frame did not save the PC
With a functioning GDB, the backtrace looks like the following instead:
#0 0x00007ffff7bd8560 in impl.initialize@plt ()
from /[...]/lib/libpck.so
#1 0x00007ffff7bd86f9 in sub () at /[...]/pck.adb:7
#2 0x0000000000401893 in a () at /[...]/a.adb:7
Note how, for frame #1, the address looks quite similar, except
for the high-order bits not being set:
#1 0x00007ffff7bd86f9 in sub () at /[...]/pck.adb:7 <<<-- OK
#1 0x00000000f7bd86f9 in ?? () <<<-- WRONG
^^^^
||||
Wrong
Investigating this further led me to displaced stepping.
As we are "next"-ing from a location where a breakpoint is inserted,
we need to step out of it, and since we're on non-stop mode, we need
to do it using displaced stepping. And looking at
amd64-tdep.c:amd64_displaced_step_fixup, I found the code that handles
the return address:
regcache_cooked_read_unsigned (regs, AMD64_RSP_REGNUM, &rsp);
retaddr = read_memory_unsigned_integer (rsp, retaddr_len, byte_order);
retaddr = (retaddr - insn_offset) & 0xffffffffUL;
The mask used to compute retaddr looks wrong to me, keeping only
4 bytes instead of 8, and explains why the high order bits of
the backtrace are unset. What happens is that, after the displaced
stepping has completed, GDB restores that return address at the location
where the program expects it. But because the top half bits of
the address have been masked out, the return address is now invalid.
The incorrect behavior of the "next" command and the backtrace at
that location are the first symptoms of that. Another symptom is
that this actually alters the behavior of the program, where a "cont"
from there soon leads to a SEGV when the inferior tries to jump back
to that incorrect return address:
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x00000000f7bd86f9 in ?? ()
^^^^^^^^^^^^^^^^^^
This patch fixes the issue by using a mask that seems more appropriate
for this architecture.
gdb/ChangeLog:
* amd64-tdep.c (amd64_displaced_step_fixup): Fix the mask used to
compute RETADDR.
gdb/testsuite/ChangeLog:
* gdb.base/dso2dso-dso2.c, gdb.base/dso2dso-dso2.h,
gdb.base/dso2dso-dso1.c, gdb.base/dso2dso-dso1.h, gdb.base/dso2dso.c,
gdb.base/dso2dso.exp: New files.
Tested on x86_64-linux, no regression.
Keith found out that several tests were failing when testing the
native-gdbserver board on Fedora (x86_64). Strangely, these failures
had not been reported by our BuildBot. Later, he found that the reason
for this was because the failures only happened when running the
testsuite without FORCE_PARALLEL (i.e., on serial mode; maybe it would
be worth having a builder testing things on serial...). Then, he
decided to start bisecting the changes to see which one introduced the
failure (it was not trivial to know this only by looking at gdb.log).
After a lot of time, he found that Pedro's commit
e1316e60d4 was the culprit. There was
nothing wrong in the code, but the new gdb.base/checkpoint-ns.exp
testcase did something that left the GDBFLAGS variable in an
inconsistent state. This test works by modifying this variable to set
non-stop on, sourcing gdb.base/checkpoint.exp (which does the hard
work), and then restoring the old value on GDBFLAGS. However, this was
not working because gdb.base/checkpoint.exp bails out if it is being
tested on gdbserver, and when it calls "continue" the control goes back
to the function calling the tests, and not to
gdb.base/checkpoint-ns.exp.
The fix is simple: just wrap the "source" call, and make
gdb.base/checkpoint-ns.exp aware of the "continue"/"return" calls made
by gdb.base/checkpoint.exp.
gdb/testsuite/ChangeLog:
2015-08-12 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
Keith Seitz <keiths@redhat.com>
* gdb.base/checkpoint-ns.exp: Use save_vars to save and restore
GDBFLAGS.
gdb/testsuite/ChangeLog:
* gdb.base/gdbhistsize-history.exp
(test_histsize_history_setting): Use save_vars.
* gdb.base/gdbinit-history.exp (test_gdbinit_history_setting):
Use save_vars.
(test_no_truncation_of_unlimited_history_file): Use save_vars.
* gdb.base/readline.exp: Use save_vars.
While running bare-metal tests with GDB i noticed some failures in
gdb.base/break.exp, related to the use of the catch commands.
It turns out GDB tries to access memory address 0x0 whenever one tries
to insert a catchpoint, which should obviously not happen.
This was introduced with the changes for permanent breakpoints. In special,
bp_loc_is_permanent tries to check if there is a breakpoint inserted at
the same address as the current breakpoint's location's address. In the
case of catchpoints, this is 0x0.
(top-gdb) catch fork
Sending packet: $m0,1#fa...Packet received: E01
Catchpoint 4 (fork)
(top-gdb) catch vfork
Sending packet: $m0,1#fa...Packet received: E01
Catchpoint 5 (vfork)
It is not obvious to detect because this fails silently for Linux. For our
bare-metal testing, though, this fails with a clear error message from the
target about not being able to read such address.
The attached patch addresses this by bailing out of bp_loc_is_permanent (...)
if the location address is not meaningful. I also took the opportunity to
update the comment for breakpoint_address_is_meaningful, which mentioned
breakpoint addresses as opposed to their locations' addresses.
gdb/ChangeLog:
2015-08-11 Luis Machado <lgustavo@codesourcery.com>
* breakpoint.c (bp_loc_is_permanent): Return 0 when breakpoint
location address is not meaningful.
(breakpoint_address_is_meaningful): Update comment.
This patch adds documentation for explicit locations to both the
User Manual and gdb's online help system.
gdb/ChangeLog:
* NEWS: Mention explicit locations.
* breakpoint.c [LOCATION_HELP_STRING]: New macro.
[BREAK_ARGS_HELP]: Use LOCATION_HELP_STRING.
(_initialize_breakpoint): Update documentation for
"clear", "break", "trace", "strace", "ftrace", and "dprintf".
gdb/doc/ChangeLog:
* gdb.texinfo (Thread-Specific Breakpoints, Printing Source Lines):
Use "location(s)"instead of "linespec(s)".
(Specifying a Location): Rewrite.
Add subsections describing linespec, address, and explicit locations.
Add node/menu for each subsection.
(Source and Machine Code, C Preprocessor Macros)
(Create and Delete Trace points)
(Extensions for Ada Tasks): Use "location(s)" instead of "linespec(s)".
(Continuing at a Different Address): Remove "linespec" examples.
Add reference to "Specify a Location"
(The -break-insert Command): Rewrite. Add anchor.
Add reference to appropriate manual section discussing locations.
(The -dprintf-insert Command): Refer to -break-insert for
specification of 'location'.
gdb/testsuite/ChangeLog:
* gdb.base/help.exp: Update help_breakpoint_text.
This patch adds support for explicit locations to MI's -break-insert
command. The new options, documented in the User Manual, are
--source, --line, --function, and --label.
gdb/ChangeLog:
* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Add support for
explicit locations, options "--source", "--function",
"--label", and "--line".
gdb/testsuite/ChangeLog:
* gdb.mi/mi-break.exp (test_explicit_breakpoints): New proc.
(at toplevel): Call test_explicit_breakpoints.
* gdb.mi/mi-dprintf.exp: Add tests for explicit dprintf
breakpoints.
* lib/mi-support.exp (mi_make_breakpoint): Add support for
breakpoint conditions, "-cond".
This patch exposes explicit locations to the CLI user. This enables
users to "explicitly" specify attributes of the breakpoint location
to avoid any ambiguity that might otherwise exist with linespecs.
The general syntax of explicit locations is:
-source SOURCE_FILENAME -line {+-}LINE -function FUNCTION_NAME
-label LABEL_NAME
Option names may be abbreviated, e.g., "-s SOURCE_FILENAME -li 3" and users
may use the completer with either options or values.
gdb/ChangeLog:
* completer.c: Include location.h.
(enum match_type): New enum.
(location_completer): Rename to ...
(linespec_completer): ... this.
(collect_explicit_location_matches, backup_text_ptr)
(explicit_location_completer): New functions.
(location_completer): "New" function; handle linespec
and explicit location completions.
(complete_line_internal): Remove all location completer-specific
handling.
* linespec.c (linespec_lexer_lex_keyword, is_ada_operator)
(find_toplevel_char): Export.
(linespec_parse_line_offset): Export.
Issue error if STRING is not numerical.
(gdb_get_linespec_parser_quote_characters): New function.
* linespec.h (linespec_parse_line_offset): Declare.
(get_gdb_linespec_parser_quote_characters): Declare.
(is_ada_operator): Declare.
(find_toplevel_char): Declare.
(linespec_lexer_lex_keyword): Declare.
* location.c (explicit_to_event_location): New function.
(explicit_location_lex_one): New function.
(string_to_explicit_location): New function.
(string_to_event_location): Handle explicit locations.
* location.h (explicit_to_event_location): Declare.
(string_to_explicit_location): Declare.
gdb/testsuite/ChangeLog:
* gdb.linespec/3explicit.c: New file.
* gdb.linespec/cpexplicit.cc: New file.
* gdb.linespec/cpexplicit.exp: New file.
* gdb.linespec/explicit.c: New file.
* gdb.linespec/explicit.exp: New file.
* gdb.linespec/explicit2.c: New file.
* gdb.linespec/ls-errs.exp: Add explicit location tests.
* lib/gdb.exp (capture_command_output): Regexp-escape `command'
before using in the matching pattern.
Clarify that `prefix' is a regular expression.
This patch add support for explicit locations and switches many linespec
locations to this new location type. This patch also converts all
linespec locations entered by the user to an explicit representation
internally (thus bypassing the linespec parser when resetting the
breakpoint).
This patch does not introduce any user-visible changes.
gdb/ChangeLog:
* break-catch-throw.c (re_set_exception_catchpoint): Convert
linespec into explicit location.
* breakpoint.c (create_overlay_breakpoint)
(create_longjmp_master_breakpoint)
(create_std_terminate_master_breakpoint)
(create_exception_master_breakpoint): Convert linespec into explicit
location.
(update_static_tracepoint): Convert linespec into explicit location.
* linespec.c (enum offset_relative_sign, struct line_offset): Move
location.h.
(struct linespec) <expression, expr_pc, source_filename>
<function_name, label_name, line_offset>: Replace with ...
<explicit>: ... this.
<is_linespec>: New member.
(PARSER_EXPLICIT): New accessor macro.
(undefined_label_error): New function.
(source_file_not_found_error): New function.
(linespec_parse_basic): The parser result is now an explicit location.
Use PARSER_EXPLICIT to access it.
Use undefined_label_error.
(canonicalize_linespec): Convert canonical linespec into explicit
location.
Move string representation of location to explicit_location_to_linespec
and use it and explicit_location_to_string to save string
representations of the canonical location.
(create_sals_line_offset, convert_linespec_to_sals): `ls' contains an
explicit location. Update all references.
(convert_explicit_location_to_sals): New function.
(parse_linespec): Use PARSER_EXPLICIT to access the parser
result's explicit location.
(linespec_state_constructor): Initialize is_linespec.
Use PARSER_EXPLICIT.
(linespec_parser_delete): Use PARSER_EXPLICIT to access the parser's
result.
(event_location_to_sals): For linespec locations, set is_linespec.
Handle explicit locations.
(decode_objc): 'ls' contains an explicit location now. Update all
references.
(symtabs_from_filename): Use source_file_not_found_error.
* location.c (struct event_location.u) <explicit>: New member.
(initialize_explicit_location): New function.
(initialize_event_location): Initialize explicit locations.
(new_explicit_location, get_explicit_location)
(get_explicit_location_const): New functions.
(explicit_to_string_internal): New function; most of contents moved
from canonicalize_linespec.
(explicit_location_to_string): New function.
(explicit_location_to_linespec): New function.
(copy_event_location, delete_event_location)
(event_location_to_string_const, event_location_empty_p): Handle
explicit locations.
* location.h (enum offset_relative_sign, struct line_offset): Move
here from linespec.h.
(enum event_location_type): Add EXPLICIT_LOCATION.
(struct explicit_location): New structure.
(explicit_location_to_string): Declare.
(explicit_location_to_linespec): Declare.
(new_explicit_location, get_explicit_locationp
(get_explicit_location_const, initialize_explicit_location): Declare.
This patch adds support for address locations, of the form "*ADDR".
[Support for address linespecs has been removed/replaced by this "new"
location type.] This patch also converts any existing address locations
from its previous linespec type.
gdb/ChangeLog:
* breakpoint.c (create_thread_event_breakpoint, init_breakpoint_sal):
Convert linespec to address location.
* linespec.c (canonicalize_linespec): Do not handle address
locations here.
(convert_address_location_to_sals): New function; contents moved
from ...
(convert_linespc_to_sals): ... here.
(parse_linespec): Remove address locations from linespec grammar.
Remove handling of address locations.
(linespec_lex_to_end): Remove handling of address linespecs.
(event_location_to_sals): Handle ADDRESS_LOCATION.
(linespec_expression_to_pc): Export.
* linespec.h (linespec_expression_to_pc): Add declaration.
* location.c (struct event_location.u) <address>: New member.
(new_address_location, get_address_location): New functions.
(copy_event_location, delete_event_location, event_location_to_string)
(string_to_event_location, event_location_empty_p): Handle address
locations.
* location.h (enum event_location_type): Add ADDRESS_LOCATION.
(new_address_location, get_address_location): Declare.
* python/py-finishbreakpoint.c (bpfinishpy_init): Convert linespec
to address location.
* spu-tdep.c (spu_catch_start): Likewise.
This patch converts the code base to use the new struct event_location
API being introduced. This patch preserves the current functionality and
adds no new features.
The "big picture" API usage introduced by this patch may be illustrated
with a simple exmaple. Where previously developers would write:
void
my_command (char *arg, int from_tty)
{
create_breakpoint (..., arg, ...);
...
}
one now uses:
void
my_command (char *arg, int from_tty)
{
struct event_locaiton *location;
struct cleanup *back_to;
location = string_to_event_locaiton (&arg, ...);
back_to = make_cleanup_delete_event_location (location);
create_breakpoint (..., location, ...);
do_cleanups (back_to);
}
Linespec-decoding functions (now called location-decoding) such as
decode_line_full no longer skip argument pointers over processed input.
That functionality has been moved into string_to_event_location as
demonstrated above.
gdb/ChangeLog
* ax-gdb.c: Include location.h.
(agent_command_1) Use linespec location instead of address
string.
* break-catch-throw.c: Include location.h.
(re_set_exception_catchpoint): Use linespec locations instead
of address strings.
* breakpoint.c: Include location.h.
(create_overlay_event_breakpoint, create_longjmp_master_breakpoint)
(create_std_terminate_master_breakpoint)
(create_exception_master_breakpoint, update_breakpoints_after_exec):
Use linespec location instead of address string.
(print_breakpoint_location): Use locations and
event_location_to_string.
Print extra_string for pending locations for non-MI streams.
(print_one_breakpoint_location): Use locations and
event_location_to_string.
(init_raw_breakpoint_without_location): Initialize b->location.
(create_thread_event_breakpoint): Use linespec location instead of
address string.
(init_breakpoint_sal): Likewise.
Only save extra_string if it is non-NULL and not the empty string.
Use event_location_to_string instead of `addr_string'.
Constify `p' and `endp'.
Use skip_spaces_const/skip_space_const instead of non-const versions.
Copy the location into the breakpoint.
If LOCATION is NULL, save the breakpoint address as a linespec location
instead of an address string.
(create_breakpoint_sal): Change `addr_string' parameter to a struct
event_location. All uses updated.
(create_breakpoints_sal): Likewise for local variable `addr_string'.
(parse_breakpoint_sals): Use locations instead of address strings.
Remove check for empty linespec with conditional.
Refactor.
(decode_static_tracepoint_spec): Make argument const and update
function.
(create_breakpoint): Change `arg' to a struct event_location and
rename.
Remove `copy_arg' and `addr_start'.
If EXTRA_STRING is empty, set it to NULL.
Don't populate `canonical' for pending breakpoints.
Pass `extra_string' to find_condition_and_thread.
Clear `extra_string' if `rest' was NULL.
Do not error with "garbage after location" if setting a dprintf
breakpoint.
Copy the location into the breakpoint instead of an address string.
(break_command_1): Use string_to_event_location and pass this to
create_breakpoint instead of an address string.
Check against `arg_cp' for a probe linespec.
(dprintf_command): Use string_to_event_location and pass this to
create_breakpoint instead of an address string.
Throw an exception if no format string was specified.
(print_recreate_ranged_breakpoint): Use event_location_to_string
instead of address strings.
(break_range_command, until_break_command)
(init_ada_exception_breakpoint): Use locations instead
of address strings.
(say_where): Print out extra_string for pending locations.
(base_breakpoint_dtor): Delete `location' and `location_range_end' of
the breakpoint.
(base_breakpoint_create_sals_from_location): Use struct event_location
instead of address string.
Remove `addr_start' and `copy_arg' parameters.
(base_breakpoint_decode_location): Use struct event_location instead of
address string.
(bkpt_re_set): Use locations instead of address strings.
Use event_location_empty_p to check for unset location.
(bkpt_print_recreate): Use event_location_to_string instead of
an address string.
Print out extra_string for pending locations.
(bkpt_create_sals_from_location, bkpt_decode_location)
(bkpt_probe_create_sals_from_location): Use struct event_location
instead of address string.
(bkpt_probe_decode_location): Use struct event_location instead of
address string.
(tracepoint_print_recreate): Use event_location_to_string to
recreate the tracepoint.
(tracepoint_create_sals_from_location, tracepoint_decode_location)
(tracepoint_probe_create_sals_from_location)
(tracepoint_probe_decode_location): Use struct event_location
instead of address string.
(dprintf_print_recreate): Use event_location_to_string to recreate
the dprintf.
(dprintf_re_set): Remove check for valid/missing format string.
(strace_marker_create_sals_from_location)
(strace_marker_create_breakpoints_sal, strace_marker_decode_location)
(update_static_tracepoint): Use struct event_location instead of
address string.
(location_to_sals): Likewise.
Pass `extra_string' to find_condition_and_thread.
For newly resolved pending breakpoint locations, clear the location's
string representation.
Assert that the breakpoint's condition string is NULL when
condition_not_parsed.
(breakpoint_re_set_default, create_sals_from_location_default)
(decode_location_default, trace_command, ftrace_command)
(strace_command, create_tracepoint_from_upload): Use locations
instead of address strings.
* breakpoint.h (struct breakpoint_ops) <create_sals_from_location>:
Use struct event_location instead of address string.
Update all uses.
<decode_location>: Likewise.
(struct breakpoint) <addr_string>: Change to struct event_location
and rename `location'.
<addr_string_range_end>: Change to struct event_location and rename
`location_range_end'.
(create_breakpoint): Use struct event_location instead of address
string.
* cli/cli-cmds.c: Include location.h.
(edit_command, list_command): Use locations instead of address strings.
* elfread.c: Include location.h.
(elf_gnu_ifunc_resolver_return_stop): Use event_location_to_string.
* guile/scm-breakpoint.c: Include location.h.
(bpscm_print_breakpoint_smob): Use event_location_to_string.
(gdbscm_register_breakpoint): Use locations instead of address
strings.
* linespec.c: Include location.h.
(struct ls_parser) <stream>: Change to const char *.
(PARSER_STREAM): Update.
(lionespec_lexer_lex_keyword): According to find_condition_and_thread,
keywords must be followed by whitespace.
(canonicalize_linespec): Save a linespec location into `canonical'.
Save a canonical linespec into `canonical'.
(parse_linespec): Change `argptr' to const char * and rename `arg'.
All uses updated.
Update function description.
(linespec_parser_new): Initialize `parser'.
Update initialization of parsing stream.
(event_location_to_sals): New function.
(decode_line_full): Change `argptr' to a struct event_location and
rename it `location'.
Use locations instead of address strings.
Call event_location_to_sals instead of parse_linespec.
(decode_line_1): Likewise.
(decode_line_with_current_source, decode_line_with_last_displayed)
Use locations instead of address strings.
(decode_objc): Likewise.
Change `argptr' to const char * and rename `arg'.
(destroy_linespec_result): Delete the linespec result's location
instead of freeing the address string.
* linespec.h (struct linespec_result) <addr_string>: Change to
struct event_location and rename to ...
<location>: ... this.
(decode_line_1, decode_line_full): Change `argptr' to struct
event_location. All callers updated.
* mi/mi-cmd-break.c: Include language.h, location.h, and linespec.h.
(mi_cmd_break_insert_1): Use locations instead of address strings.
Throw an error if there was "garbage" at the end of the specified
linespec.
* probe.c: Include location.h.
(parse_probes): Change `argptr' to struct event_location.
Use event locations instead of address strings.
* probe.h (parse_probes): Change `argptr' to struct event_location.
* python/py-breakpoint.c: Include location.h.
(bppy_get_location): Constify local variable `str'.
Use event_location_to_string.
(bppy_init): Use locations instead of address strings.
* python/py-finishbreakpoint.c: Include location.h.
(bpfinishpy_init): Remove local variable `addr_str'.
Use locations instead of address strings.
* python/python.c: Include location.h.
(gdbpy_decode_line): Use locations instead of address strings.
* remote.c: Include location.h.
(remote_download_tracepoint): Use locations instead of address
strings.
* spu-tdep.c: Include location.h.
(spu_catch_start): Remove local variable `buf'.
Use locations instead of address strings.
* tracepoint.c: Include location.h.
(scope_info): Use locations instead of address strings.
(encode_source_string): Constify parameter `src'.
* tracepoint.h (encode_source_string): Likewise.
gdb/testsuite/ChangeLog
* gdb.base/dprintf-pending.exp: Update dprintf "without format"
test.
Add tests for missing ",FMT" and ",".
This patch introduces the new breakpoint/"linespec" API based on
a new struct event_location. This API currently only supports
traditional linespecs, maintaining the status quo of the code base.
Future patches will add additional functionality for other location
types such as address locations.
gdb/ChangeLog:
* Makefile.in (SFILES): Add location.c.
(HFILES_NO_SRCDIR): Add location.h.
(COMMON_OBS): Add location.o.
* linespec.c (linespec_lex_to_end): New function.
* linespec.h (linespec_lex_to_end): Declare.
* location.c: New file.
* location.h: New file.
This patch renames all occurrances of "addr_string" and "address
string" in the breakpoint/linespec APIs. This will emphasize the
change from address strings used in setting breakpoints (et al) to the
new locations-based API introduced in subsequent patches.
gdb/ChangeLog:
* breakpoint.h (struct breakpoint_ops) <create_sals_from_address>:
Renamed to create_sals_from_location.
<decode_linespec>: Renamed to decode_location.
Update all callers.
* breakpoint.c (create_sals_from_address_default): Renamed to ...
(create_sals_from_location_default): ... this.
(addr_string_to_sals): Renamed to ...
(location_to_sals): ... this.
(decode_linespec_default): Renamed to ...
(decode_location_default): ... this.
(base_breakpoint_create_sals_from_address): Renamed to ...
(base_breakpoint_create_sals_from_location): ... this.
(bkpt_create_sals_from_address): Renamed to ...
(bkpt_create_sals_from_location): ... this.
(bkpt_decode_linespec): Renamed to ...
(bkpt_decode_location): ... this.
(bkpt_probe_create_sals_from_address): Renamed to ...
(bkpt_probe_create_sals_from_location): ... this.
(tracepoint_create_sals_from_address): Renamed to ...
(tracepoint_create_sals_from_location): ... this.
(tracepoint_decode_linespec): Renamed to ...
(tracepoint_decode_location): ... this.
(tracepoint_probe_create_sals_from_address): Renamed to ...
(tracepoint_probe_create_sals_from_location): ... this.
(tracepoint_probe_decode_linespec): Renamed to ...
(tracepoint_probe_decode_location): ... this.
(strace_marker_create_sals_from_address): Renamed to ...
(strace_marker_create_sals_from_location): ... this.
(decode_linespec_default): Renamed to ...
(decode_location_default): ... this.
gdb/ChangeLog:
* symtab.c (make_file_symbol_completion_list_1): Renamed from
make_file_symbol_completion_list and made static.
(make_file_symbol_completion_list): New function.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Add location completer tests.
The testsuite shows no regressions with this forced on, on:
- Native x86_64 Fedora 20, with and output "set displaced off".
- Native x86_64 Fedora 20, on top of x86 software single-step series.
- PPC64 Fedora 18.
- S/390 RHEL 7.1.
Let's try making it the default.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_nat_always_non_stop_p): Return 1.
This adds displaced stepping support for the General-Instruction
Extension Facility instructions, which have a PC-relative displacement
(RIL-b/RIL-c). We already handle RIL branches, but not others.
Currently, displaced stepping a breakpoint put on any of these
instructions results in the inferior crashing when or after the
instruction is executed out-of-line in the scratch pad.
This patch takes the easy route of patching the displacement in the
copy of the instruction in the scratch pad. As the displacement is a
signed 32-bit field, it's possible that the stratch pad ends too far
that the needed displacement doesn't fit in the adjusted instruction,
as e.g., if stepping over a breakpoint in a shared library (the
scratch pad is around the main program's entry point). That case is
detected and GDB falls back to stepping over the breakpoint in-line
(which involves pausing all threads momentarily).
(We could probably do something smarter, but I don't plan on doing it
myself. This was already sufficient to get "maint set target-non-stop
on" working regression free on S/390.)
Tested on S/390 RHEL 7.1, where it fixes a few hundred FAILs when
testing with displaced stepping force-enabled, with the end result
being no regressions compared to a test run that doesn't force
displaced stepping. Fixes the non-stop tests compared to mainline
too; most are crashing due to this on the machine I run tests on.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* s390-linux-tdep.c (is_non_branch_ril)
(s390_displaced_step_copy_insn): New functions.
(s390_displaced_step_fixup): Update comment.
(s390_gdbarch_init): Install s390_displaced_step_copy_insn as
gdbarch_displaced_step_copy_insn hook.
The ppc64 displaced step code can't handle atomic sequences. Fallback
to stepping over the breakpoint in-line if we detect one.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* infrun.c (displaced_step_prepare_throw): Return -1 if
gdbarch_displaced_step_copy_insn returns NULL. Update intro
comment.
* rs6000-tdep.c (LWARX_MASK, LWARX_INSTRUCTION, LDARX_INSTRUCTION)
(STWCX_MASK, STWCX_INSTRUCTION, STDCX_INSTRUCTION): Move higher up
in file.
(ppc_displaced_step_copy_insn): New function.
(ppc_displaced_step_fixup): Update comment.
(rs6000_gdbarch_init): Install ppc_displaced_step_copy_insn as
gdbarch_displaced_step_copy_insn hook.
* gdbarch.sh (displaced_step_copy_insn): Document what happens on
NULL return.
* gdbarch.h: Regenerate.
gdb/testsuite/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* gdb.arch/ppc64-atomic-inst.exp (do_test): New procedure, move
tests here.
(top level): Run do_test with and without displaced stepping.
Running the testsuite with "maint set target-non-stop on" shows:
(gdb) PASS: gdb.base/valgrind-infcall.exp: continue #98 (false warning)
continue
Continuing.
dl_main (phdr=<optimized out>..., auxv=<optimized out>) at rtld.c:2302
2302 LIBC_PROBE (init_complete, 2, LM_ID_BASE, r);
Cannot access memory at address 0x400532
(gdb) PASS: gdb.base/valgrind-infcall.exp: continue #99 (false warning)
p gdb_test_infcall ()
$1 = 1
(gdb) FAIL: gdb.base/valgrind-infcall.exp: p gdb_test_infcall ()
Even though that was a native GNU/Linux test run, this test spawns
Valgrind and connects to it with "target remote". The error above is
actually orthogonal to target-non-stop. The real issue is that that
enables displaced stepping, and displaced stepping doesn't work with
Valgrind, because we can't write to the inferior memory (thus can't
copy the instruction to the scratch pad area).
I'm sure there will be other targets with the same issue, so trying to
identify Valgrind wouldn't be sufficient. The fix is to try setting
up the displaced step anyway. If we get a MEMORY_ERROR, we disable
displaced stepping for that inferior, and fall back to doing an
in-line step-over. If "set displaced-stepping" is "on" (as opposed to
"auto), GDB warns displaced stepping failed ("on" is mainly useful for
the testsuite, not for users).
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* inferior.h (struct inferior) <displaced_stepping_failed>: New
field.
* infrun.c (use_displaced_stepping_now_p): New parameter 'inf'.
Return false if dispaced stepping failed before.
(resume): Pass the current inferior to
use_displaced_stepping_now_p. Wrap displaced_step_prepare in
TRY/CATCH. If we get a MEMORY_ERROR, set the inferior's
displaced_stepping_failed flag, and fall back to an in-line
step-over.
gdb/testsuite/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* gdb.base/valgrind-disp-step.c: New file.
* gdb.base/valgrind-disp-step.exp: New file.
On a target that is both always in non-stop mode and can do displaced
stepping (such as native x86_64 GNU/Linux, with "maint set
target-non-stop on"), the step-over-trips-on-watchpoint.exp test
sometimes fails like this:
(gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: thread 1
set scheduler-locking off
(gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: set scheduler-locking off
step
-[Switching to Thread 0x7ffff7fc0700 (LWP 11782)]
-Hardware watchpoint 4: watch_me
-
-Old value = 0
-New value = 1
-child_function (arg=0x0) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:39
-39 other = 1; /* set thread-specific breakpoint here */
-(gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step
+wait_threads () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:49
+49 return 1; /* in wait_threads */
+(gdb) FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step
Note "scheduler-locking" was set off. The problem is that on such
targets, the step-over of thread 2 and the "step" of thread 1 can be
set to run simultaneously (since with displaced stepping the
breakpoint isn't ever removed from the target), and sometimes, the
"step" of thread 1 finishes first, so it'd take another resume to see
the watchpoint trigger. Fix this by replacing the wait_threads
function with a one-line infinite loop that doesn't call any function,
so that the "step" of thread 1 never finishes.
gdb/testsuite/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-lands-on-breakpoint.c (wait_threads):
Delete function.
(main): Add alarm. Run an infinite loop instead of calling
wait_threads.
* gdb.threads/step-over-lands-on-breakpoint.exp (do_test): Change
comment.
* gdb.threads/step-over-trips-on-watchpoint.c (wait_threads):
Delete function.
(main): Add alarm. Run an infinite loop instead of calling
wait_threads.
* gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Change
comment.
With "maint set target-non-stop on" we get:
@@ -66,13 +66,16 @@ Continuing.
interrupt
(gdb) PASS: gdb.base/interrupt-noterm.exp: interrupt
-Program received signal SIGINT, Interrupt.
-PASS: gdb.base/interrupt-noterm.exp: inferior received SIGINT
-testcase src/gdb/testsuite/gdb.base/interrupt-noterm.exp completed in 0 seconds
+[process 12119] #1 stopped.
+0x0000003615ebc6d0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
+81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
+FAIL: gdb.base/interrupt-noterm.exp: inferior received SIGINT (timeout)
+testcase src/gdb/testsuite/gdb.base/interrupt-noterm.exp completed in 10 seconds
That is, we get "[$thread] #1 stopped" instead of SIGINT.
The issue is that we don't currently distinguish send
"interrupt/ctrl-c" to target terminal vs "stop/pause" thread well;
both cases go through "target_stop".
And then, the native Linux backend (linux-nat.c) implements
target_stop with SIGSTOP in non-stop mode, and SIGINT in all-stop
mode. Since "maint set target-non-stop on" forces the backend to be
always running in non-stop mode, even though the user-visible behavior
is "set non-stop" is "off", "interrupt" causes a SIGSTOP instead of
the SIGINT the test expects.
Fix this by introducing a target_interrupt method to use in the
"interrupt/ctrl-c" case, so "set non-stop off" can always work the
same irrespective of "maint set target-non-stop on/off". I'm
explictly considering changing the "set non-stop on" behavior as out
of scope here.
Most of the patch is an across-the-board rename of to_stop hook
implementations to to_interrupt. The only targets where something
more than a rename is being done are linux-nat.c and remote.c, which
are the only targets that support async, and thus are the only ones
the core side calls target_stop on.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* darwin-nat.c (darwin_stop): Rename to ...
(darwin_interrupt): ... this.
(_initialize_darwin_inferior): Adjust.
* gnu-nat.c (gnu_stop): Delete.
(gnu_target): Don't install gnu_stop.
* inf-ptrace.c (inf_ptrace_stop): Rename to ...
(inf_ptrace_interrupt): ... this.
(inf_ptrace_target): Adjust.
* infcmd.c (interrupt_target_1): Use target_interrupt instead of
target_stop.
* linux-nat (linux_nat_stop): Rename to ...
(linux_nat_interrupt): ... this.
(linux_nat_stop): Reimplement.
(linux_nat_add_target): Install linux_nat_interrupt.
* nto-procfs.c (nto_interrupt_twice): Rename to ...
(nto_handle_sigint_twice): ... this.
(nto_interrupt): Rename to ...
(nto_handle_sigint): ... this. Call target_interrupt instead of
target_stop.
(procfs_wait): Adjust.
(procfs_stop): Rename to ...
(procfs_interrupt): ... this.
(init_procfs_targets): Adjust.
* procfs.c (procfs_stop): Rename to ...
(procfs_interrupt): ... this.
(procfs_target): Adjust.
* remote-m32r-sdi.c (m32r_stop): Rename to ...
(m32r_interrupt): ... this.
(init_m32r_ops): Adjust.
* remote-sim.c (gdbsim_stop_inferior): Rename to ...
(gdbsim_interrupt_inferior): ... this.
(gdbsim_stop): Rename to ...
(gdbsim_interrupt): ... this.
(gdbsim_cntrl_c): Adjust.
(init_gdbsim_ops): Adjust.
* remote.c (sync_remote_interrupt): Adjust comments.
(remote_stop_as): Rename to ...
(remote_interrupt_as): ... this.
(remote_stop): Adjust comment.
(remote_interrupt): New function.
(init_remote_ops): Install remote_interrupt.
* target.c (target_interrupt): New function.
* target.h (struct target_ops) <to_interrupt>: New field.
(target_interrupt): New declaration.
* windows-nat.c (windows_stop): Rename to ...
(windows_interrupt): ... this.
* target-delegates.c: Regenerate.
With "maint set target-non-stop on" we get:
-PASS: gdb.threads/signal-while-stepping-over-bp-other-thread.exp: step
+FAIL: gdb.threads/signal-while-stepping-over-bp-other-thread.exp: step
The issue is simply that switch_back_to_stepped_thread is not used in
non-stop mode, thus infrun doesn't output the expected "switching back
to stepped thread" log.
gdb/testsuite/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* signal-while-stepping-over-bp-other-thread.exp: Expect "restart
threads" as alternative to "switching back to stepped thread".
This finally implements user-visible all-stop mode running with the
target_ops backend always in non-stop mode. This is a stepping stone
towards finer-grained control of threads, being able to do interesting
things like thread groups, associating groups with breakpoints, etc.
From the user's perspective, all-stop mode is really just a special
case of being able to stop and resume specific sets of threads, so it
makes sense to do this step first.
With this, even in all-stop, the target is no longer in charge of
stopping all threads before reporting an event to the core -- the core
takes care of it when it sees fit. For example, when "next"- or
"step"-ing, we can avoid stopping and resuming all threads at each
internal single-step, and instead only stop all threads when we're
about to present the stop to the user.
The implementation is almost straight forward, as the heavy lifting
has been done already in previous patches. Basically, we replace
checks for "set non-stop on/off" (the non_stop global), with calls to
a new target_is_non_stop_p function. In a few places, if "set
non-stop off", we stop all threads explicitly, and in a few other
places we resume all threads explicitly, making use of existing
methods that were added for teaching non-stop to step over breakpoints
without displaced stepping.
This adds a new "maint set target-non-stop on/off/auto" knob that
allows both disabling the feature if we find problems, and
force-enable it for development (useful when teaching a target about
this. The default is "auto", which means the feature is enabled if a
new target method says it should be enabled. The patch implements the
method in linux-nat.c, just for illustration, because it still returns
false. We'll need a few follow up fixes before turning it on by
default. This is a separate target method from indicating regular
non-stop support, because e.g., while e.g., native linux-nat.c is
close to regression free with all-stop-non-stop (with following
patches will fixing the remaining regressions), remote.c+gdbserver
will still need more fixing, even though it supports "set non-stop
on".
Tested on x86_64 Fedora 20, native, with and without "set displaced
off", and with and without "maint set target-non-stop on"; and also
against gdbserver.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* NEWS: Mention "maint set/show target-non-stop".
* breakpoint.c (update_global_location_list): Check
target_is_non_stop_p instead of non_stop.
* infcmd.c (attach_command_post_wait, attach_command): Likewise.
* infrun.c (show_can_use_displaced_stepping)
(can_use_displaced_stepping_p, start_step_over_inferior):
Likewise.
(internal_resume_ptid): New function.
(resume): Use it.
(proceed): Check target_is_non_stop_p instead of non_stop. If in
all-stop mode but the target is always in non-stop mode, start all
the other threads that are implicitly resumed too.
(for_each_just_stopped_thread, fetch_inferior_event)
(adjust_pc_after_break, stop_all_threads): Check
target_is_non_stop_p instead of non_stop.
(handle_inferior_event): Likewise. Handle detach-fork in all-stop
with the target always in non-stop mode.
(handle_signal_stop) <random signal>: Check target_is_non_stop_p
instead of non_stop.
(switch_back_to_stepped_thread): Check target_is_non_stop_p
instead of non_stop.
(keep_going_stepped_thread): Use internal_resume_ptid.
(stop_waiting): If in all-stop mode, and the target is in non-stop
mode, stop all threads.
(keep_going_pass): Likewise, when starting a new in-line step-over
sequence.
* linux-nat.c (get_pending_status, select_event_lwp)
(linux_nat_filter_event, linux_nat_wait_1, linux_nat_wait): Check
target_is_non_stop_p instead of non_stop.
(linux_nat_always_non_stop_p): New function.
(linux_nat_stop): Check target_is_non_stop_p instead of non_stop.
(linux_nat_add_target): Install linux_nat_always_non_stop_p.
* target-delegates.c: Regenerate.
* target.c (target_is_non_stop_p): New function.
(target_non_stop_enabled, target_non_stop_enabled_1): New globals.
(maint_set_target_non_stop_command)
(maint_show_target_non_stop_command): New functions.
(_initilize_target): Install "maint set/show target-non-stop"
commands.
* target.h (struct target_ops) <to_always_non_stop_p>: New field.
(target_non_stop_enabled): New declaration.
(target_is_non_stop_p): New declaration.
gdb/doc/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Maintenance Commands): Document "maint set/show
target-non-stop".
That is, step past breakpoints by:
- pausing all threads
- removing breakpoint at PC
- single-step
- reinsert breakpoint
- restart threads
similarly to all-stop (with displaced stepping disabled). This allows
non-stop to work on targets/architectures without displaced stepping
support. That is, it makes displaced stepping an optimization instead
of a requirement. For example, in principle, all GNU/Linux ports
support non-stop mode at the target_ops level, but not all
corresponding gdbarch's implement displaced stepping. This should
make non-stop work for all (albeit, not as efficiently). And then
there are scenarios where even if the architecture supports displaced
stepping, we can't use it, because we e.g., don't find a usable
address to use as displaced step scratch pad. It should also fix
stepping past watchpoints on targets that have non-continuable
watchpoints in non-stop mode (e.g., PPC, untested). Running the
instruction out of line in the displaced stepping scratch pad doesn't
help that case, as the copied instruction reads/writes the same
watched memory... We can fix that too by teaching GDB to only remove
the watchpoint from the thread that we want to move past the
watchpoint (currently, removing a watchpoint always removes it from
all threads), but again, that can be considered an optimization; not
all targets would support it.
For those familiar with the gdb and gdbserver Linux target_ops
backends, the implementation should look similar, except it is done on
the core side. When we pause threads, we may find they stop with an
interesting event that should be handled later when the thread is
re-resumed, thus we store such events in the thread object, and mark
the event as pending. We should only consume pending events if the
thread is indeed resumed, thus we add a new "resumed" flag to the
thread object. At a later stage, we might add new target methods to
accelerate some of this, like "pause all threads", with corresponding
RSP packets, but we'd still need a fallback method for remote targets
that don't support such packets, so, again, that can be deferred as
optimization.
My _real_ motivation here is making it possible to reimplement
all-stop mode on top of the target always working on non-stop mode, so
that e.g., we can send RSP packets to a remote target even while the
target is running -- can't do that in the all-stop RSP variant, by
design).
Tested on x86_64 Fedora 20, with and without "set displaced off"
forced. The latter forces the new code paths whenever GDB needs to
step past a breakpoint.
gdb/ChangeLog:
2015-08-07 Pedro Alves <pedro@codesourcery.com>
* breakpoint.c (breakpoints_should_be_inserted_now): If any thread
has a pending status, return true.
* gdbthread.h: Include target/waitstatus.h.
(struct thread_suspend_state) <stop_reason, waitstatus_pending_p,
stop_pc>: New fields.
(struct thread_info) <resumed>: New field.
(set_resumed): Declare.
* infrun.c: Include "event-loop.h".
(infrun_async_inferior_event_token, infrun_is_async): New globals.
(infrun_async): New function.
(clear_step_over_info): Add debug output.
(displaced_step_in_progress_any_inferior): New function.
(displaced_step_fixup): New returns int.
(start_step_over): Handle in-line step-overs too. Assert the
thread is marked resumed.
(resume_cleanups): Clear the thread's resumed flag.
(resume): Set the thread's resumed flag. Return early if the
thread has a pending status. Allow stepping a breakpoint with no
signal.
(proceed): Adjust to check 'resumed' instead of 'executing'.
(clear_proceed_status_thread): If the thread has a pending status,
and that status is a finished step, discard the pending status.
(clear_proceed_status): Don't clear step_over_info here.
(random_pending_event_thread, do_target_wait): New functions.
(prepare_for_detach, wait_for_inferior, fetch_inferior_event): Use
do_target_wait.
(wait_one): New function.
(THREAD_STOPPED_BY): New macro.
(thread_stopped_by_watchpoint, thread_stopped_by_sw_breakpoint)
(thread_stopped_by_hw_breakpoint): New functions.
(switch_to_thread_cleanup, save_waitstatus, stop_all_threads): New
functions.
(handle_inferior_event): Also call set_resumed(false) on all
threads implicitly stopped by the event.
(restart_threads, resumed_thread_with_pending_status): New
functions.
(finish_step_over): If we were doing an in-line step-over before,
and no longer are after trying to start a new step-over, restart
all threads. If we have multiple threads with pending events,
save the current event and go through the event loop again.
(handle_signal_stop): Return early if finish_step_over returns
false.
<random signal>: If we get a signal while stepping over a
breakpoint in-line in non-stop mode, restart all threads. Clear
step_over_info before delivering the signal.
(keep_going_stepped_thread): Use internal_error instead of
gdb_assert. Mark the thread as resumed.
(keep_going_pass_signal): Assert the thread isn't already resumed.
If some other thread is doing an in-line step-over, defer the
resume. If we just started a new in-line step-over, stop all
threads. Don't clear step_over_info.
(infrun_async_inferior_event_handler): New function.
(_initialize_infrun): Create async event handler with
infrun_async_inferior_event_handler as callback.
(infrun_async): New declaration.
* target.c (target_async): New function.
* target.h (target_async): Declare macro and readd as function
declaration.
* target/waitstatus.h (enum target_stop_reason)
<TARGET_STOPPED_BY_SINGLE_STEP>: New value.
* thread.c (new_thread): Clear the new waitstatus field.
(set_resumed): New function.
Just a code refactor, no funcionality change intended.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* infrun.c (keep_going_stepped_thread): New function, factored out
from ...
(switch_back_to_stepped_thread): ... here.
Clarify that currently_stepping works at a higher level than
target_resume.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* infrun.c (currently_stepping): Extend intro comment.
* target.h (target_resume): Extend intro comment.
Several misc cleanups that prepare the tail end of this function, the
part that actually re-resumes the stepped thread.
The most non-obvious would be the currently_stepping change, I guess.
That's because it isn't ever correct to pass step=1 to target_resume
on software single-step targets, and currently_stepping works at a
conceptual higher level, it returns step=true even on software step
targets. It doesn't really matter on hardware step targets, as the
breakpoint will be hit immediately, but it's just wrong on software
step targets. I tested it against my x86 software single-step branch,
and it indeed fixes failed assertions (that catch spurious
PTRACE_SINGLESTEP requests) there.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* infrun.c (switch_back_to_stepped_thread): Use ecs->ptid instead
of inferior_ptid. If the stepped thread vanished, return 0
instead of resuming here. Use reset_ecs. Print the prev_pc and
the current stop_pc in log message. Clear trap_expected if the
thread advanced. Don't pass currently_stepping to
do_target_resume.
The main motivation of this patch is sharing more code between the
proceed (starting the inferior for the first time) and keep_going
(restarting the inferior after handling an event) paths and using the
step_over_chain queue now embedded in the thread_info object for
pending in-line step-overs too (instead of just for displaced
stepping).
So this commit:
- splits out a new keep_going_pass_signal function out of keep_going
that is just like keep_going except for the bits that clear the
signal to pass if the signal is set to "handle nopass".
- makes proceed use keep_going too.
- Makes start_step_over use keep_going_pass_signal instead of lower
level displaced stepping things.
One user visible change: if inserting breakpoints while trying to
proceed fails, we now get:
(gdb) si
Warning:
Could not insert hardware watchpoint 7.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
Command aborted.
(gdb)
while before we only saw warnings with no indication that the command
was cancelled:
(gdb) si
Warning:
Could not insert hardware watchpoint 7.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
(gdb)
Tested on x86_64-linux-gnu, ppc64-linux-gnu and s390-linux-gnu.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* gdbthread.h (struct thread_info) <prev_pc>: Extend comment.
* infrun.c (struct execution_control_state): Move higher up in the
file.
(reset_ecs): New function.
(start_step_over): Now returns int. Rewrite to use
keep_going_pass_signal instead of manually starting a displaced step.
(resume): Don't call set_running here. If displaced stepping
can't start now, clear trap_expected.
(find_thread_needs_step_over): Delete function.
(proceed): Set up finish_thread_state_cleanup. Call set_running.
If the current thread needs a step over, push it in the step-over
chain. Don't set insert breakpoints nor call resume directly
here. Instead rewrite to use start_step_over and
keep_going_pass_signal.
(finish_step_over): New function.
(handle_signal_stop): Call finish_step_over instead of
start_step_over.
(switch_back_to_stepped_thread): If the event thread needs another
step-over do that first. Use start_step_over.
(keep_going_pass_signal): New function, factored out from ...
(keep_going): ... here.
(_initialize_infrun): Comment moved here.
* thread.c (set_running_thread): New function.
(set_running, finish_thread_state): Use set_running_thread.
In order to teach non-stop mode to do in-line step-overs (pause all
threads, remove breakpoint, single-step, reinsert breakpoint, restart
threads), we'll need to be able to queue in-line step over requests,
much like we queue displaced stepping (out-of-line) requests.
Actually, the queue should be the same -- threads wait for their turn
to step past something (breakpoint, watchpoint), doesn't matter what
technique we end up using when the step over actually starts.
I found that the queue management ends up simpler and more efficient
if embedded in the thread objects themselves. This commit converts
the existing displaced stepping queue to that. Later patches will
make the in-line step-overs code paths use it too.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* gdbthread.h (struct thread_info) <step_over_prev,
step_over_next>: New fields.
(thread_step_over_chain_enqueue, thread_step_over_chain_remove)
(thread_step_over_chain_next, thread_is_in_step_over_chain): New
declarations.
* infrun.c (struct displaced_step_request): Delete.
(struct displaced_step_inferior_state) <step_request_queue>:
Delete field.
(displaced_step_prepare): Assert that trap_expected is set. Use
thread_step_over_chain_enqueue. Split starting a new displaced
step to ...
(start_step_over): ... this new function.
(resume): Assert the thread isn't waiting for a step over already.
(proceed): Assert the thread isn't waiting for a step over
already.
(infrun_thread_stop_requested): Adjust to remove threads from the
embedded step-over chain.
(handle_inferior_event) <fork/vfork>: Call start_step_over after
displaced_step_fixup.
(handle_signal_stop): Call start_step_over after
displaced_step_fixup.
* infrun.h (step_over_queue_head): New declaration.
* thread.c (step_over_chain_enqueue, step_over_chain_remove)
(thread_step_over_chain_next, thread_is_in_step_over_chain)
(thread_step_over_chain_enqueue)
(thread_step_over_chain_remove): New functions.
(delete_thread_1): Remove thread from the step-over chain.
I noticed that even though keep_going knows to start a step over for a
watchpoint, thread_still_needs_step_over forgets it.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* infrun.c (thread_still_needs_step_over): Rename to ...
(thread_still_needs_step_over_bp): ... this.
(enum step_over_what): New.
(thread_still_needs_step_over): Reimplement.
Even though "target remote" supports target-async, the all-stop
target_wait implementation ignores TARGET_WNOHANG. If the core
happens to poll for events and we've already read the stop reply out
of the serial/socket, remote_wait_as hangs forever instead of
returning an indication that there are no events to process. This
can't happen currently, but later changes will trigger this.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* remote.c (remote_wait_as): If not waiting for a stop reply,
return TARGET_WAITKIND_NO_RESUMED. If TARGET_WNOHANG is
requested, don't block waiting forever.
Prepare to use it in contexts without an ecs handy. Follow up patches
will make use of this.
gdb/ChangeLog:
2015-08-07 Pedro Alves <pedro@codesourcery.com>
* infrun.c (adjust_pc_after_break): Now takes thread_info and
waitstatus pointers instead of an ecs. Adjust.
(handle_inferior_event): Adjust caller.
Letting a "checkpoint" run to exit with "set non-stop on" behaves
differently compared to the default all-stop mode ("set non-stop
off").
Currently, in non-stop mode:
(gdb) start
Temporary breakpoint 1 at 0x40086b: file src/gdb/testsuite/gdb.base/checkpoint.c, line 28.
Starting program: build/gdb/testsuite/gdb.base/checkpoint
Temporary breakpoint 1, main () at src/gdb/testsuite/gdb.base/checkpoint.c:28
28 char *tmp = &linebuf[0];
(gdb) checkpoint
checkpoint 1: fork returned pid 24948.
(gdb) c
Continuing.
Copy complete.
Deleting copy.
[Inferior 1 (process 24944) exited normally]
[Switching to process 24948]
(gdb) info threads
Id Target Id Frame
1 process 24948 "checkpoint" (running)
No selected thread. See `help thread'.
(gdb) c
The program is not being run.
(gdb)
Two issues above:
1. Thread 1 got stuck in "(running)" state (it isn't really running)
2. While checkpoints try to preserve the illusion that the thread is
still the same when the process exits, GDB switched to "No thread
selected." instead of staying with thread 1 selected.
Problem #1 is caused by handle_inferior_event and normal_stop not
considering that when a
TARGET_WAITKIND_SIGNALLED/TARGET_WAITKIND_EXITED event is reported,
and the inferior is mourned, the target may still have execution.
Problem #2 is caused by the make_cleanup_restore_current_thread
cleanup installed by fetch_inferior_event not being able to find the
original thread 1's ptid in the thread list, thus not being able to
restore thread 1 as selected thread. The fix is to make the cleanup
installed by make_cleanup_restore_current_thread aware of thread ptid
changes, by installing a thread_ptid_changed observer that adjusts the
cleanup's data.
After the patch, we get the same in all-stop and non-stop modes:
(gdb) c
Continuing.
Copy complete.
Deleting copy.
[Inferior 1 (process 25109) exited normally]
[Switching to process 25113]
(gdb) info threads
Id Target Id Frame
* 1 process 25113 "checkpoint" main () at src/gdb/testsuite/gdb.base/checkpoint.c:28
(gdb)
Turns out the whole checkpoints.exp file can run in non-stop mode
unmodified. I thought of moving most of the test file's contents to a
procedure that can be called twice, once in non-stop mode and another
in all-stop mode. But then, the test already takes close to 30
seconds to run on my machine, so I thought it'd be nicer to run
all-stop and non-stop mode in parallel. Thus I added a new
checkpoint-ns.exp file that just appends "set non-stop on" to GDBFLAGS
and sources checkpoint.exp.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* infrun.c (handle_inferior_event): If we get
TARGET_WAITKIND_SIGNALLED or TARGET_WAITKIND_EXITED in non-stop
mode, mark all threads of the exiting process as not-executing.
(normal_stop): If we get TARGET_WAITKIND_SIGNALLED or
TARGET_WAITKIND_EXITED in non-stop mode, finish all threads of the
exiting process, if inferior_ptid still points at a process.
* thread.c (struct current_thread_cleanup) <next>: New field.
(current_thread_cleanup_chain): New global.
(restore_current_thread_ptid_changed): New function.
(restore_current_thread_cleanup_dtor): Remove the cleanup from the
current_thread_cleanup_chain list.
(make_cleanup_restore_current_thread): Add the cleanup data to the
current_thread_cleanup_chain list.
(_initialize_thread): Install restore_current_thread_ptid_changed
as thread_ptid_changed observer.
gdb/testsuite/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* gdb.base/checkpoint-ns.exp: New file.
* gdb.base/checkpoint.exp: Pass explicit "checkpoint.c" to
standard_testfile.
On x86-solaris 10, we noticed that starting a program would sometimes
cause the debugger to crash. For instance:
% gdb a
(gdb) break adainit
Breakpoint 1 at 0x8051f03
(gdb) run
Starting program: /[...]/a
[Thread debugging using libthread_db enabled]
zsh: 24398 segmentation fault (core dumped) /[...]/gdb a
The exception occurs in dtrace_process_dof_probe, while trying
to process each probe referenced by a DTRACE_DOF_SECT_TYPE_PROVIDER
DOF section from /lib/libc.so.1. For reference, the ELF section
in that shared library providing the DOF data has the following
characteristics:
Idx Name Size VMA LMA File off Algn
14 .SUNW_dof 0000109d 000b4398 000b4398 000b4398 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
The function dtrace_process_dof gets passed the contents of that
ELF section, which allows it to determine the location of the table
where all DOF sections are described. I dumped the contents of
each DOF section as seen by GDB, and it seemed to be plausible,
because the offset of each DOF section was pretty much equal to
the sum of the offset and size of the previous DOF section. Also,
the offset + sum of the last section corresponds to the size of
the .SUNW_dof section.
Things start to break down when processing one of the DOF sections
that has a type of DTRACE_DOF_SECT_TYPE_PROVIDER. It gets the contents
of this DOF section via:
struct dtrace_dof_provider *provider = (struct dtrace_dof_provider *)
DTRACE_DOF_PTR (dof, DOF_UINT (dof, section->dofs_offset));
Said more simply, the struct dtrace_dof_provider data is at
section->dofs_offset of the entire DOF contents. Given that
the contents of SECTION seemed to make sense, so far so good.
However, what SECTION tells us is that our DOF provider section
is 40 bytes long:
(gdb) print *section
$36 = {dofs_type = 15, dofs_align = 4, dofs_flags = 1,
dofs_entsize = 0, dofs_offset = 3264, dofs_size = 40}
^^^^^^^^^^^^^^
But on the other hand:
(gdb) p sizeof (struct dtrace_dof_provider)
$54 = 44
In other words GDB expected a bigger DOF section and when we try to
fetch the value of the last field of that DOF section (dofpv_prenoffs)...
eoffsets_s = DTRACE_DOF_SECT (dof,
DOF_UINT (dof, provider->dofpv_prenoffs));
... we end up reading data that actually belongs to another DOF
section, and therefore irrelevant. This in turn means that the value
of eofftab gets incorrectly set, since it depends on eoffsets_s:
eofftab = DTRACE_DOF_PTR (dof, DOF_UINT (dof, eoffsets_s->dofs_offset));
This invalid address quickly catches up to us when we pass it to
dtrace_process_dof_probe shortly after, where we crash because
we try to subscript it:
Program received signal SIGSEGV, Segmentation fault.
0x08155bba in dtrace_process_dof_probe ([...]) at [...]/dtrace-probe.c:378
378 = ((uint32_t *) eofftab)[...];
This patch fixes the issue by detecting provider DOF sections
that are smaller than expected, and discarding the DOF data.
gdb/ChangeLog:
* dtrace-probe.c (dtrace_process_dof): Ignore the objfile's DOF
data if a DTRACE_DOF_SECT_TYPE_PROVIDER section is found to be
smaller than expected.
The get_frame_language feels like it would be more at home in frame.c
rather than in stack.c, while the declaration, that is currently in
language.h can be moved into frame.h to match.
A couple of new includes are added, but otherwise no substantial change
here.
gdb/ChangeLog:
* stack.c (get_frame_language): Moved ...
* frame.c (get_frame_language): ... to here.
* language.h (get_frame_language): Declaration moved to frame.h.
* frame.h: Add language.h include, for language enum.
(get_frame_language): Declaration moved from language.h.
* language.c: Add frame.h include.
* top.c: Add frame.h include.
* symtab.h (struct obj_section): Declare.
(struct cmd_list_element): Declare.
As part of a drive to remove deprecated_safe_get_selected_frame, make
the get_frame_language function take a frame parameter. Given the name
of the function this actually seems to make a lot of sense.
The task of fetching a suitable frame is then passed to the calling
functions. For get_frame_language there are not many callers, these are
updated to get the selected frame in a suitable way.
gdb/ChangeLog:
* language.c (show_language_command): Find selected frame before
asking for the language of that frame.
(set_language_command): Likewise.
* language.h (get_frame_language): Add frame parameter.
* stack.c (get_frame_language): Add frame parameter, assert
parameter is not NULL, update comment and reindent.
* top.c (check_frame_language_change): Pass the selected frame
into get_frame_language.
Indicate speculatively executed instructions with a leading '?'. We use the
space that is normally used for the PC prefix. In the case where the
instruction at the current PC had been executed speculatively before, the PC
prefix will be partially overwritten resulting in "?> ".
As a side-effect, the /p modifier to omit the PC prefix in the "record
instruction-history" command now uses a 3-space PC prefix " " in order to
have enough space for the speculative execution indication.
gdb/
* btrace.c (btrace_compute_ftrace_bts): Clear insn flags.
(pt_btrace_insn_flags): New.
(ftrace_add_pt): Call pt_btrace_insn_flags.
* btrace.h (btrace_insn_flag): New.
(btrace_insn) <flags>: New.
* record-btrace.c (btrace_insn_history): Print insn prefix.
* NEWS: Announce it.
doc/
* gdb.texinfo (Process Record and Replay): Document prefixing of
speculatively executed instructions in the "record instruction-history"
command.
testsuite/
* gdb.btrace/instruction_history.exp: Update.
* gdb.btrace/tsx.exp: New.
* gdb.btrace/tsx.c: New.
* lib/gdb.exp (skip_tsx_tests, skip_btrace_pt_tests): New.
Intel(R) Processor Trace support requires a recent linux/perf_event.h header.
When GDB is built on an older system, Intel(R) Processor Trace will not be
available and there is no indication in the configure and build log as to
what went wrong.
Check for a compatible linux/perf_event.h at configure-time.
gdb/
* configure.ac: Check for PERF_ATTR_SIZE_VER5 in linux/perf_event.h
* configure: Regenerate.
The buildbot shows that PPC64 and x86_64 builders, both native and
extended-remote gdbserver frequently timeout these tests.
until-precsave.exp times out on my x86_64 occasionally as well.
Inspecting the logs, we see that if we waited some more, the tests
would pass.
Simply bump until-precsave.exp timeouts further, and apply the same
treatment to step-precsave.exp.
gdb/testsuite/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* gdb.reverse/step-precsave.exp: Use with_timeout_factor to
increase timeout.
* gdb.reverse/until-precsave.exp: Bump timeouts.
This test fails with --target_board=native-extended-gdbserver because
it misses the usual "disconnect":
(gdb) target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=30454
Already connected to a remote target. Disconnect? (y or n) n
Still connected.
(gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb (got interactive prompt)
gdb/testsuite/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* gdb.base/valgrind-infcall.exp: Issue a "disconnect".
This patch is mostly extracted from Pedro's C++ branch. It adds explicit
casts from integer to enum types, where it is really the intention to do
so. This could be because we are ...
* iterating on enum values (we need to iterate on an equivalent integer)
* converting from a value read from bytes (dwarf attribute, agent
expression opcode) to the equivalent enum
* reading the equivalent integer value from another language (Python/Guile)
An exception to that is the casts in regcache.c. It seems to me like
struct regcache's register_status field could be a pointer to an array of
enum register_status. Doing so would waste a bit of memory (4 bytes
used by the enum vs 1 byte used by the current signed char, for each
register). If we switch to C++11 one day, we can define the underlying
type of an enum type, so we could have the best of both worlds.
gdb/ChangeLog:
* arm-tdep.c (set_fp_model_sfunc): Add cast from integer to enum.
(arm_set_abi): Likewise.
* ax-general.c (ax_print): Likewise.
* c-exp.y (exp : string_exp): Likewise.
* compile/compile-loc2c.c (compute_stack_depth_worker): Likewise.
(do_compile_dwarf_expr_to_c): Likewise.
* cp-name-parser.y (demangler_special : DEMANGLER_SPECIAL start):
Likewise.
* dwarf2expr.c (execute_stack_op): Likewise.
* dwarf2loc.c (dwarf2_compile_expr_to_ax): Likewise.
(disassemble_dwarf_expression): Likewise.
* dwarf2read.c (dwarf2_add_member_fn): Likewise.
(read_array_order): Likewise.
(abbrev_table_read_table): Likewise.
(read_attribute_value): Likewise.
(skip_unknown_opcode): Likewise.
(dwarf_decode_macro_bytes): Likewise.
(dwarf_decode_macros): Likewise.
* eval.c (value_f90_subarray): Likewise.
* guile/scm-param.c (gdbscm_make_parameter): Likewise.
* i386-linux-tdep.c (i386_canonicalize_syscall): Likewise.
* infrun.c (handle_command): Likewise.
* memory-map.c (memory_map_start_memory): Likewise.
* osabi.c (set_osabi): Likewise.
* parse.c (operator_length_standard): Likewise.
* ppc-linux-tdep.c (ppc_canonicalize_syscall): Likewise, and use
single return point.
* python/py-frame.c (gdbpy_frame_stop_reason_string): Likewise.
* python/py-symbol.c (gdbpy_lookup_symbol): Likewise.
(gdbpy_lookup_global_symbol): Likewise.
* record-full.c (record_full_restore): Likewise.
* regcache.c (regcache_register_status): Likewise.
(regcache_raw_read): Likewise.
(regcache_cooked_read): Likewise.
* rs6000-tdep.c (powerpc_set_vector_abi): Likewise.
* symtab.c (initialize_ordinary_address_classes): Likewise.
* target-debug.h (target_debug_print_signals): Likewise.
* utils.c (do_restore_current_language): Likewise.
Fixes another C++ -fpermissive error:
src/gdb/gdbserver/tracepoint.c:4535:21: error: invalid conversion from ‘int’ to ‘eval_result_type’ [-fpermissive]
expr_eval_result = ipa_expr_eval_result;
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* tracepoint.c (expr_eval_result): Now an int.
The regcache used to be hidden inside inferiors.c, but since the
tracepoints support that it's a first class object. This also fixes a
few implicit pointer conversion errors in C++ mode, caused by a few
places missing the explicit cast.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* gdbthread.h (struct regcache): Forward declare.
(struct thread_info) <regcache_data>: Now a struct regcache
pointer.
* inferiors.c (inferior_regcache_data)
(set_inferior_regcache_data): Now work with struct regcache
pointers.
* inferiors.h (struct regcache): Forward declare.
(inferior_regcache_data, set_inferior_regcache_data): Now work
with struct regcache pointers.
* regcache.c (get_thread_regcache, regcache_invalidate_thread)
(free_register_cache_thread): Remove struct regcache pointer
casts.
Running gdb.threads/process-dies-while-handling-bp.exp against
gdbserver sometimes FAILs because GDBserver drops the connection, but
the logs leave no clue on what the reason could be. Running manually
a few times, I saw the same:
$ ./gdbserver/gdbserver --multi :9999 testsuite/gdb.threads/process-dies-while-handling-bp
Process testsuite/gdb.threads/process-dies-while-handling-bp created; pid = 12766
Listening on port 9999
Remote debugging from host 127.0.0.1
Listening on port 9999
Child exited with status 0
Child exited with status 0
What happened is that an exception escaped and gdbserver reopened the
connection, which led to that second "Listening on port 9999" output.
The error was a failure to access registers from a now-dead thread.
The exception probably shouldn't have escaped here, but meanwhile,
this at least makes the issue less mysterious.
Tested on x86_64 Fedora 20.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* server.c (captured_main): On error, print the exception message
to stderr, and if run_once is set, throw a quit.
Found while processing the C++ enum changes. It seems like series
should be of type enum complaint_series, instead of adding a cast.
Redundant and out of date comments are also removed.
gdb/ChangeLog:
* complaints.c (enum complaint_series): Add newlines and remove
out of date comment.
(struct complaints) <series>: Change type to enum
complaint_series and remove out of date comment.
(symfile_complaint_hook): Use equivalent enum value
ISOLATED_MESSAGE instead of 0.
While hacking on the fix for PR threads/18600 (Threads left stopped
after fork+thread spawn), I once saw its test (fork-plus-threads.exp)
FAIL against gdbserver because move_out_of_jump_pad_callback has a
gdb_breakpoint_here call, and the caller isn't making sure the current
thread points to the right thread. In the case I saw, the current
thread pointed to the wrong process, so gdb_breakpoint_here returned
the wrong answer. Unfortunately I didn't save logs. Still, seems
obvious enough and it should fix a potential occasional racy FAIL.
Tested on x86_64 Fedora 20.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (move_out_of_jump_pad_callback): Temporarily switch
the current thread.
Running gdbserver --debug under Valgrind shows:
==4803== Invalid read of size 4
==4803== at 0x432B62: linux_write_memory (linux-low.c:5320)
==4803== by 0x4143F7: write_inferior_memory (target.c:83)
==4803== by 0x415895: remove_memory_breakpoint (mem-break.c:362)
==4803== by 0x432EF5: linux_remove_point (linux-low.c:5460)
==4803== by 0x416319: delete_raw_breakpoint (mem-break.c:802)
==4803== by 0x4163F3: release_breakpoint (mem-break.c:842)
==4803== by 0x416477: delete_breakpoint_1 (mem-break.c:869)
==4803== by 0x4164EF: delete_breakpoint (mem-break.c:891)
==4803== by 0x416843: delete_gdb_breakpoint_1 (mem-break.c:1069)
==4803== by 0x4168D8: delete_gdb_breakpoint (mem-break.c:1098)
==4803== by 0x4134E3: process_serial_event (server.c:4051)
==4803== by 0x4138E4: handle_serial_event (server.c:4196)
==4803== Address 0x4c6b930 is 0 bytes inside a block of size 1 alloc'd
==4803== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4803== by 0x4240C6: xmalloc (common-utils.c:43)
==4803== by 0x41439C: write_inferior_memory (target.c:80)
==4803== by 0x415895: remove_memory_breakpoint (mem-break.c:362)
==4803== by 0x432EF5: linux_remove_point (linux-low.c:5460)
==4803== by 0x416319: delete_raw_breakpoint (mem-break.c:802)
==4803== by 0x4163F3: release_breakpoint (mem-break.c:842)
==4803== by 0x416477: delete_breakpoint_1 (mem-break.c:869)
==4803== by 0x4164EF: delete_breakpoint (mem-break.c:891)
==4803== by 0x416843: delete_gdb_breakpoint_1 (mem-break.c:1069)
==4803== by 0x4168D8: delete_gdb_breakpoint (mem-break.c:1098)
==4803== by 0x4134E3: process_serial_event (server.c:4051)
==4803==
And:
==7272== Conditional jump or move depends on uninitialised value(s)
==7272== at 0x3615E48361: vfprintf (vfprintf.c:1634)
==7272== by 0x414E89: debug_vprintf (debug.c:60)
==7272== by 0x42800A: debug_printf (common-debug.c:35)
==7272== by 0x43937B: my_waitpid (linux-waitpid.c:149)
==7272== by 0x42D740: linux_wait_for_event_filtered (linux-low.c:2441)
==7272== by 0x42DADA: linux_wait_for_event (linux-low.c:2552)
==7272== by 0x42E165: linux_wait_1 (linux-low.c:2860)
==7272== by 0x42F5D8: linux_wait (linux-low.c:3453)
==7272== by 0x4144A4: mywait (target.c:107)
==7272== by 0x413969: handle_target_event (server.c:4214)
==7272== by 0x41A1A6: handle_file_event (event-loop.c:429)
==7272== by 0x41996D: process_event (event-loop.c:184)
gdb/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* nat/linux-waitpid.c (my_waitpid): Only print *status if waitpid
returned > 0.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_write_memory): Rewrite debug output to avoid
reading beyond the passed in buffer length.
This adds a kfailed test that has the whole process exit just while
several threads continuously step over a breakpoint. Usually, the
process exits just while GDB or GDBserver is handling the breakpoint
hit. In other words, the process disappears while the event thread is
(ptrace-) stopped. This exposes several issues in GDB and GDBserver.
Errors, crashes, etc.
I fixed some of these issues recently, but there's a lot more to do.
It's a bit like playing whack-a-mole at the moment. You fix an issue,
which then exposes several others.
E.g., with the native target, you get (among other errors):
(...)
[New Thread 0x7ffff47b9700 (LWP 18077)]
[New Thread 0x7ffff3fb8700 (LWP 18078)]
[New Thread 0x7ffff37b7700 (LWP 18079)]
Cannot find user-level thread for LWP 18076: generic error
(gdb) KFAIL: gdb.threads/process-dies-while-handling-bp.exp: non_stop=on: cond_bp_target=1: inferior 1 exited (prompt) (PRMS: gdb/18749)
gdb/testsuite/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
PR gdb/18749
* gdb.threads/process-dies-while-handling-bp.c: New file.
* gdb.threads/process-dies-while-handling-bp.exp: New file.
This field was never set nor used. This patch removes it.
gdb/ChangeLog:
* common/agent.c (symbol_list) <required>: Remove.
gdb/gdbserver/ChangeLog:
* tracepoint.c (symbol_list) <required>: Remove.
Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html
This adds a test that has a multithreaded program have several threads
continuously fork, while another thread continuously steps over a
breakpoint.
This exposes several intertwined issues, which this patch addresses:
- When we're stopping and suspending threads, some thread may fork,
and we missed setting its suspend count to 1, like we do when a new
clone/thread is detected. When we next unsuspend threads, the fork
child's suspend count goes below 0, which is bogus and fails an
assertion.
- If a step-over is cancelled because a signal arrives, but then gdb
is not interested in the signal, we pass the signal straight back
to the inferior. However, we miss that we need to re-increment the
suspend counts of all other threads that had been paused for the
step-over. As a result, other threads indefinitely end up stuck
stopped.
- If a detach request comes in just while gdbserver is handling a
step-over (in the test at hand, this is GDB detaching the fork
child), gdbserver internal errors in stabilize_thread's helpers,
which assert that all thread's suspend counts are 0 (otherwise we
wouldn't be able to move threads out of the jump pads). The
suspend counts aren't 0 while a step-over is in progress, because
all threads but the one stepping past the breakpoint must remain
paused until the step-over finishes and the breakpoint can be
reinserted.
- Occasionally, we see "BAD - reinserting but not stepping." being
output (from within linux_resume_one_lwp_throw). That was because
GDB pokes memory while gdbserver is busy with a step-over, and that
suspends threads, and then re-resumes them with proceed_one_lwp,
which missed another reason to tell linux_resume_one_lwp that the
thread should be set back to stepping.
- In a couple places, we were resuming threads that are meant to be
suspended. E.g., when a vCont;c/s request for thread B comes in
just while gdbserver is stepping thread A past a breakpoint. The
resume for thread B must be deferred until the step-over finishes.
- The test runs with both "set detach-on-fork" on and off. When off,
it exercises the case of GDB detaching the fork child explicitly.
When on, it exercises the case of gdb resuming the child
explicitly. In the "off" case, gdb seems to exponentially become
slower as new inferiors are created. This is _very_ noticeable as
with only 100 inferiors gdb is crawling already, which makes the
test take quite a bit to run. For that reason, I've disabled the
"off" variant for now.
gdb/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* target/waitstatus.h (enum target_stop_reason)
<TARGET_STOPPED_BY_SINGLE_STEP>: New value.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Set the fork child's suspend
count if stopping and suspending threads.
(check_stopped_by_breakpoint): If stopped by trace, set the LWP's
stop reason to TARGET_STOPPED_BY_SINGLE_STEP.
(linux_detach): Complete an ongoing step-over.
(lwp_suspended_inc, lwp_suspended_decr): New functions. Use
throughout.
(resume_stopped_resumed_lwps): Don't resume a suspended thread.
(linux_wait_1): If passing a signal to the inferior after
finishing a step-over, unsuspend and re-resume all lwps. If we
see a single-step event but the thread should be continuing, don't
pass the trap to gdb.
(stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use
internal_error instead of gdb_assert.
(enqueue_pending_signal): New function.
(check_ptrace_stopped_lwp_gone): Add debug output.
(start_step_over): Use internal_error instead of gdb_assert.
(complete_ongoing_step_over): New function.
(linux_resume_one_thread): Don't resume a suspended thread.
(proceed_one_lwp): If the LWP is stepping over a breakpoint, reset
it stepping.
gdb/testsuite/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* gdb.threads/forking-threads-plus-breakpoint.exp: New file.
* gdb.threads/forking-threads-plus-breakpoint.c: New file.
The tail end of linux_wait_1 isn't expecting that the select_event_lwp
machinery can pick a whole-process exit event to report to GDB. When
that happens, both gdb and gdbserver end up quite confused:
...
(gdb)
[Thread 24971.24971] #1 stopped.
0x0000003615a011f0 in ?? ()
c&
Continuing.
(gdb) [New Thread 24971.24981]
[New Thread 24983.24983]
[New Thread 24971.24982]
[Thread 24983.24983] #3 stopped.
0x0000003615ebc7cc in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:130
130 pid = ARCH_FORK ();
[New Thread 24984.24984]
Error in re-setting breakpoint -16: PC register is not available
Error in re-setting breakpoint -17: PC register is not available
Error in re-setting breakpoint -18: PC register is not available
Error in re-setting breakpoint -19: PC register is not available
Error in re-setting breakpoint -24: PC register is not available
Error in re-setting breakpoint -25: PC register is not available
Error in re-setting breakpoint -26: PC register is not available
Error in re-setting breakpoint -27: PC register is not available
Error in re-setting breakpoint -28: PC register is not available
Error in re-setting breakpoint -29: PC register is not available
Error in re-setting breakpoint -30: PC register is not available
PC register is not available
(gdb)
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (add_lwp): Set waitstatus to TARGET_WAITKIND_IGNORE.
(linux_thread_alive): Use lwp_is_marked_dead.
(extended_event_reported): Delete.
(linux_wait_1): Check if waitstatus is TARGET_WAITKIND_IGNORE
instead of extended_event_reported.
(mark_lwp_dead): Don't set the 'dead' flag. Store the waitstatus
as well.
(lwp_is_marked_dead): New function.
(lwp_running): Use lwp_is_marked_dead.
* linux-low.h: Delete 'dead' field, and update 'waitstatus's
comment.
The "extended event with waitstatus" debug output is unreachable, as
it is guarded by "if (!report_to_gdb)". If extended_event_reported is
true, then so is report_to_gdb. Move it to where we print why we're
reporting an event to GDB.
Also, the debug output currently tries to print the wrong struct
target_waitstatus.
gdb/gdbserver/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_wait_1): Move fork event output out of the
!report_to_gdb check. Pass event_child->waitstatus to
target_waitstatus_to_string instead of ourstatus.
At https://sourceware.org/ml/gdb-patches/2015-08/msg00097.html, Joel
observed that trying to next/step a program on GNU/Linux sometimes
results in the following failed assertion:
% gdb -q .obj/gprof/main
(gdb) start
(gdb) n
(gdb) step
[...]/infrun.c:2391: internal-error:
resume: Assertion `sig != GDB_SIGNAL_0' failed.
What happened is that, during the "next" operation, GDB hit a
longjmp/exception/step-resume breakpoint but failed to see that this
breakpoint was set for a different thread than the one being stepped.
Joel's detailed analysis follows:
More precisely, at the end of the "start" command, we are stopped at
the start of function Main in main.adb; there are 4 threads in total,
and we are in the main thread (which is thread 1):
(gdb) info thread
Id Target Id Frame
4 Thread 0xb7a56ba0 (LWP 28379) 0xffffe410 in __kernel_vsyscall ()
3 Thread 0xb7c5aba0 (LWP 28378) 0xffffe410 in __kernel_vsyscall ()
2 Thread 0xb7e5eba0 (LWP 28377) 0xffffe410 in __kernel_vsyscall ()
* 1 Thread 0xb7ea18c0 (LWP 28370) main () at /[...]/main.adb:57
All the logs below reference Thread ID/LWP, but it'll be easier to
talk about the threads by GDB thread number. For instance, thread 1
is LWP 28370 while thread 3 is LWP 28378. So, the explanations below
translate the LWPs into thread numbers.
Back to what happens while we are trying to "next' our program:
(gdb) n
infrun: clear_proceed_status_thread (Thread 0xb7a56ba0 (LWP 28379))
infrun: clear_proceed_status_thread (Thread 0xb7c5aba0 (LWP 28378))
infrun: clear_proceed_status_thread (Thread 0xb7e5eba0 (LWP 28377))
infrun: clear_proceed_status_thread (Thread 0xb7ea18c0 (LWP 28370))
infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x805451e
infrun: target_wait (-1.0.0, status) =
infrun: 28370.28370.0 [Thread 0xb7ea18c0 (LWP 28370)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x8054523
We've resumed thread 1 (LWP 28370), and received in return a signal
that the same thread stopped slightly further. It's still in the
range of instructions for the line of source we started the "next"
from, as evidenced by the following trace...
infrun: stepping inside range [0x805451e-0x8054531]
... and thus, we decide to continue stepping the same thread:
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523
infrun: prepare_to_wait
That's when we get an event from a different thread (thread 3)...
infrun: target_wait (-1.0.0, status) =
infrun: 28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x80782d0
infrun: context switch
infrun: Switching context from Thread 0xb7ea18c0 (LWP 28370) to Thread 0xb7c5aba0 (LWP 28378)
... which we find to be at the address where we set a breakpoint on
"the unwinder debug hook" (namely "_Unwind_DebugHook"). But GDB fails
to notice that the breakpoint was inserted for thread 1 only, and so
decides to handle it as...
infrun: BPSTAT_WHAT_SET_LONGJMP_RESUME
... and inserts a breakpoint at the corresponding resume address, as
evidenced by this the next log:
infrun: exception resume at 80542a2
That breakpoint seems innocent right now, but will play a role fairly
quickly. But for now, GDB has inserted the exception-resume
breakpoint, and needs to single-step thread 3 past the breakpoint it
just hit. Thus, it temporarily disables the exception breakpoint, and
requests a step of that thread:
infrun: skipping breakpoint: stepping past insn at: 0x80782d0
infrun: skipping breakpoint: stepping past insn at: 0x80782d0
infrun: skipping breakpoint: stepping past insn at: 0x80782d0
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 0xb7c5aba0 (LWP 28378)] at 0x80782d0
infrun: prepare_to_wait
We then get a notification, still from thread 3, that it's now past
that breakpoint...
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x8078424
... so we can resume what we were doing before, which is single-stepping
thread 1 until we get to a new line of code:
infrun: switching back to stepped thread
infrun: Switching context from Thread 0xb7c5aba0 (LWP 28378) to Thread 0xb7ea18c0 (LWP 28370)
infrun: expected thread still hasn't advanced
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523
The "resume" log above shows that we're resuming thread 1 from where
we left off (0x8054523). We get one more stop at 0x8054529, which is
still inside our stepping range so we go again. That's when we get
the following event, from thread 3:
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x80542a2
Now the stop_pc address is interesting, because it's the address of
"exception resume" breakpoint...
infrun: context switch
infrun: Switching context from Thread 0xb7ea18c0 (LWP 28370) to Thread 0xb7c5aba0 (LWP 28378)
infrun: BPSTAT_WHAT_CLEAR_LONGJMP_RESUME
... and since that location is at a different line of code, this is
where it decides the "next" operation should stop:
infrun: stop_waiting
[Switching to Thread 0xb7c5aba0 (LWP 28378)]
0x080542a2 in inte_tache_rt.ttache_rt (
<_task>=0x80968ec <inte_tache_rt_inst.tache2>)
at /[...]/inte_tache_rt.adb:54
54 end loop;
However, what GDB should have noticed earlier that the exception
breakpoint we hit was for a different thread, thus should have
single-stepped that thread out of the breakpoint _without_ inserting
the exception-return breakpoint, and then resumed the single-stepping
of the initial thread (thread 1) until that thread stepped out of its
stepping range.
This is what this patch does, and after applying it, GDB now correctly
stops on the next line of code.
The patch adds a C++ test that exercises this, both for setjmp/longjmp
and exception breakpoints. With an unpatched GDB it shows:
(gdb) next
[Switching to Thread 22445.22455]
thread_try_catch (arg=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/next-other-thr-longjmp.c:59
59 catch (...)
(gdb) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 1
next
/home/pedro/gdb/mygit/build/../src/gdb/infrun.c:4865: internal-error: process_event_stop_test: Assertion `ecs->event_thread->control.exception_resume_breakpoint != NULL' fa
iled.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 2 (GDB internal error)
Resyncing due to internal error.
n
Tested on x86_64-linux, no regressions.
gdb/ChangeLog:
2015-08-05 Pedro Alves <palves@redhat.com>
Joel Brobecker <brobecker@adacore.com>
* breakpoint.c (bpstat_what) <bp_longjmp, bp_longjmp_call_dummy>
<bp_exception, bp_longjmp_resume, bp_exception_resume>: Handle the
case where BS->STOP is not set.
gdb/testsuite/ChangeLog:
2015-08-05 Pedro Alves <palves@redhat.com>
* gdb.threads/next-while-other-thread-longjmps.c: New file.
* gdb.threads/next-while-other-thread-longjmps.exp: New file.
Fixes a build error due to typedef redefinition with some compilers.
Also added missing copyright header.
gdb/
* nat/gdb_thread_db.h: Add copyright header.
Protect against multiple inclusion.
