This patch almost halves the time it takes to "target remote + run to
main" on a higher-latency connection.
E.g., I've got a ping time of ~85ms to an x86-64 machine on the gcc
compile farm (almost 2000km away from me), and I'm behind a ~16Mbit
ADSL. When I connect to a gdbserver debugging itself on that machine
and run to main, it takes almost 55 seconds:
[palves@gcc76] $ ./gdbserver :9999 ./gdbserver
[palves@home] $ ssh -L 9999:localhost:9999 gcc76.fsffrance.org
[palves@home] $ time ./gdb -data-directory=data-directory -ex "tar rem :9999" -ex "b main" -ex "c" -ex "set confirm off" -ex "quit"
Pristine gdb 7.10.50.20150820-cvs gets us:
...
Remote debugging using :9999
Reading symbols from target:/home/palves/gdb/build/gdb/gdbserver/gdbserver...done.
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
0x00007ffff7ddd190 in ?? () from target:/lib64/ld-linux-x86-64.so.2
Breakpoint 1 at 0x41200c: file ../../../src/gdb/gdbserver/server.c, line 3635.
Continuing.
Breakpoint 1, main (argc=1, argv=0x7fffffffe3d8) at ../../../src/gdb/gdbserver/server.c:3635
3635 ../../../src/gdb/gdbserver/server.c: No such file or directory.
/home/palves/gdb/build/gdb/gdbserver/gdbserver: No such file or directory.
real 0m54.803s
user 0m0.329s
sys 0m0.064s
While with the readahead cache added by this patch, it drops to:
real 0m29.462s
user 0m0.454s
sys 0m0.054s
I added a few counters to show cache hit/miss, and got:
readahead cache miss 142
readahead cache hit 310
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-08-21 Pedro Alves <palves@redhat.com>
* remote.c (struct readahead_cache): New.
(struct remote_state) <readahead_cache>: New field.
(remote_open_1): Invalidate the cache.
(readahead_cache_invalidate, readahead_cache_invalidate_fd): New
functions.
(remote_hostio_pwrite): Invalidate the readahead cache.
(remote_hostio_pread): Rename to ...
(remote_hostio_pread_vFile): ... this.
(remote_hostio_pread_from_cache): New function.
(remote_hostio_pread): Reimplement.
(remote_hostio_close): Invalidate the readahead cache.
Fixes implicit function declaration
error in gdb/procfs.c:4927 about undeclared
make_cleanup_close().
gdb/ChangeLog:
PR build/18843
* procfs.c: Include "filestuff.h".
These fields are currently used to track the location of the cursor
inside the command window. But their usefulness is questionable because
ncurses already internally keeps track of the location of the cursor,
whose coordinates we can query using the functions getyx(), getcurx() or
getcury(). It is an unnecessary pain to keep these fields in sync with
ncurses, and their meaning is not well-defined anyway. For instance, it
is not clear whether the coordinates held in these fields are
authoritative, or whether the coordinates reported by ncurses are.
So to keep things simple, this patch removes these fields and replaces
existing reads of these fields with calls to the appropriate ncurses
querying functions, and replaces writes to these fields with calls to
wmove() (when necessary and applicable).
In the function tui_cont_sig(), I removed the call to wmove() entirely
because moving to (start_line, curch) makes no sense. The move should
have been to (cur_line, curch) -- which would now be a no-op.
Tested on x86_64 Fedora 22, no obvious regressions.
gdb/ChangeLog:
* tui/tui-data.h (tui_command_info): Remove fields cur_line and
curch.
* tui/tui-data.c (tui_clear_win_detail) [CMD_WIN]: Don't set
cur_line or curch, instead call wmove().
(init_win_info) [CMD_WIN]: Likewise.
* tui/tui-io.c (tui_puts): Likewise. Don't read cur_line,
instead call getcury().
(tui_redisplay_readline): Don't set cur_line or curch.
(tui_mld_erase_entire_line): Don't read cur_line, instead call
getcury().
(tui_cont_sig): Remove call to wmove.
(tui_getc): Don't read cur_line or curch, instead call getcury()
or getyx(). Don't set curch.
* tui/tui-win.c (make_visible_with_new_height) [CMD_WIN]: Don't
set cur_line or curch. Always move cursor to (0,0).
Commit 221e1a37 (remote non-stop: Process initially stopped threads
before other commands) caused a test regression when testing with the
native-extended-gdbserver board:
FAIL: gdb.server/solib-list.exp: non-stop 1: non-stop interior stop (timeout)
This "interior stop" now happens before "target remote" prints the
prompt, so we should no longer explicitly expect it.
gdb/testsuite/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* gdb.server/solib-list.exp: No longer expect an interior stop in
non-stop mode.
The main motivation for this is making non-stop / all-stop behave
similarly on initial connection, in order to move in the direction of
reimplementing all-stop mode with the remote target always running in
non-stop mode.
When we connect to a remote target in non-stop mode, we may find
threads either running or already stopped. The act of connecting
itself does not force threads to stop. To handle that, the remote
non-stop connection is currently roughly like this:
#1 - Fetch list of remote threads (qXfer:threads:read, qfThreadInfo,
etc). All threads are assumed to be running until the target
reports an asynchronous stop reply for them.
#2 - Fetch the initial set of threads that were already stopped, with
the '?' packet. (In non-stop, this is coupled with the vStopped
mechanism to be able to retrieve the status of more than one
thread.)
The stop replies fetched in #2 are placed in the pending stop reply
queue, and left for the regular event loop to process. That is,
"target remote" finishes and returns _before_ those stops are
processed.
That means that it's possible to have GDB process further commands
before the initial set of stopped threads is reported to the user.
E.g., before the patch, note how the prompt is printed before the
frame:
Remote debugging using :9999
(gdb)
[Thread 15296] #1 stopped.
0x0000003615a011f0 in ?? ()
Even though thread #1 was not running, for a moment, the user can see
it as such:
$ gdb a.out -ex "set non-stop 1" -ex "tar rem :9999" -ex "info threads" -ex "info registers"
Remote debugging using :9999
Id Target Id Frame
* 1 Thread 4772 (running)
Target is executing. <<<<<<< info registers
(gdb)
[Thread 4772] #1 stopped.
0x0000003615a011f0 in ?? ()
To fix that, this commit makes gdb process all threads found already
stopped at connection time, before giving the prompt to the user.
The fix takes a cue from fork-child.c:startup_inferior [1], and
processes the events locally in remote.c, avoiding the whole
wait_for_inferior/handle_inferior_event path. I decided to try this
approach after noticing that:
- several cases in handle_inferior_event miss checking stop_soon.
- we don't want to fetch the thread list in normal_stop.
and trying to fix them was resulting in sprinkling stop_soon checks in
many places, and uglifying normal_stop even more.
While with this patch, I'm avoiding changing GDB's output other than
when the prompt is printed, I think this approach is more flexible if
we do want to change it. And also, it's likely easier to get rid of
the MI *running event that is still sent for threads that are
initially found stopped, if we want to.
This happens to fix the testsuite too. All non-stop tests are racy
against "target remote" / gdbserver testing currently. That is,
sometimes the tests run, but other times they're just skipped without
any indication of PASS/FAIL. When that happens, the logs show:
target remote localhost:2346
Remote debugging using localhost:2346
(gdb)
[Thread 25418] #1 stopped.
0x0000003615a011f0 in ?? ()
^CQuit
(gdb) Remote debugging from host 127.0.0.1
Killing process(es): 25418
monitor exit
(gdb) Remote connection closed
(gdb) testcase /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/multi-create-ns-info-thr.exp completed in 61 seconds
The trouble here is that there's output after the prompt, and the
regex in question doesn't expect that:
-re "Remote debugging using .*$serialport_re.*$gdb_prompt $" {
verbose "Set target to $targetname"
return 0
}
[1] - before startup_inferior was added, we'd go through
wait_for_inferior/handle_inferior_event while going through the shell,
and that turned out problematic.
Tested on x86_64 Fedora 20, gdbserver.
gdb/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* infrun.c (print_target_wait_results): Make extern.
* infrun.h (print_target_wait_results): Declare.
* remote.c (set_stop_requested_callback): Delete.
(process_initial_stop_replies): New function.
(remote_start_remote): Use it.
(stop_reply_queue_length): New function.
gdb/testsuite/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* gdb.server/connect-stopped-target.c: New file.
* gdb.server/connect-stopped-target.exp: New file.
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.
A symbol value in an ELF final linked binary is absolute, in contrast
to a relocatable object file where the value is section relative. For
--emit-relocs it is therefore incorrect to use the value of a section
symbol as the addend when adjusting relocs against input section
symbols to output section symbols.
PR gold/18846
* target-reloc.h (relocate_relocs <RELOC_ADJUST_FOR_SECTION_RELA>):
Subtract os->address() from addend.
* powerpc.cc (relocate_relocs): Likewise.
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.
If a symbol is defined with ".symver foo,foo@VER", the assembler
creates two symbols in the object: one unversioned, and one with
the (non-default) version "VER". If foo is listed in a version
script, gold would then make the first of those symbols the
default version, and would ignore the second symbol as a
duplicate, without making it a non-default version. While this is
arguably reasonable behavior, it doesn't match Gnu ld behavior,
so this patch fixes that by allowing the second definition to
override the first by resetting the "default version" indication.
Several test cases from the Gnu ld testsuite also exposed another
related problem, where a symbol defined with ".symver foo,foo@",
placed into a shared library, is not handled properly by gold.
This patch also fixes that case, binding the symbol to the base
version.
gold/
PR gold/18703
* dynobj.cc (Versions::record_version): Handle symbol defined with
base version.
(Versions::symbol_section_contents): Likewise.
* symtab.h (Symbol::set_is_not_default): New class method.
(Symbol_table::resolve): Add is_default_version parameter.
(Symbol_table::should_override): Likewise.
* resolve.cc (Symbol_table::resolve): Add is_default_version parameter,
and pass to should_override. Adjust all callers and explicit
instantiations.
(Symbol_table::should_override): Add is_default_value parameter;
allow default version in a dynamic object to override existing
definition from same object.
* symtab.cc (Symbol_table::add_from_object): Handle case where same
symbol is defined as unversioned and non-default version in the same
object.
* testsuite/Makefile.am (ver_test_13): New test case.
* testsuite/Makefile.in: Regenerate.
* testsuite/ver_test_4.cc: Add test for symbol with base version.
* testsuite/ver_test_4.sh: Likewise.
* testsuite/ver_test_13.c: New source file.
* testsuite/ver_test_13.script: New version script.
* testsuite/ver_test_13.sh: New test case.
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 done two types of cleanup:
* in aarch64_reloc_got_type and elfNN_aarch64_relocate_section
We don't need those redundant "case" check, as they can be merged
with the "default" which just "break".
* in elfNN_aarch64_gc_sweep_hook and elfNN_aarch64_check_relocs
All TLS local executable relocations and some local dynamic
relocations (those calculate module offset) actually don't need GOT
entry, so remove them from GOT entry counting.
2015-08-18 Jiong Wang <jiong.wang@arm.com>
bfd/
* elfnn-aarch64.c (aarch64_reloc_got_type): Delete useless check.
(elfNN_aarch64_relocate_section): Likewise.
(elfNN_aarch64_gc_sweep_hook): Likewise.
(elfNN_aarch64_check_relocs): Likewise.
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.
bfd/
* elf64-ppc.c (ppc64_elf_func_desc_adjust): Don't redefine .TOC.
if already defined, and set linker_def.
(ppc64_elf_set_toc): Use .TOC. value if defined other than by
the backend.
ld/
* ldexp.c (exp_fold_tree_1): Clear linker_def on symbol assignment.
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.
HJ recently removed trailing space in binutils files, but unfortunately
they return when regenerating files in opcodes. This fixes the regen
process.
* cgen.sh: Trim trailing space from cgen output.
* ia64-gen.c (print_dependency_table): Don't generate trailing space.
(print_dis_table): Likewise.
* opc2c.c (dump_lines): Likewise.
(orig_filename): Warning fix.
* ia64-asmtab.c: Regenerate.
