Belt and braces fix. Either of the changes here is sufficient to
ensure vd_nodename is initialized properly.
* elf.c (_bfd_elf_slurp_version_tables): Always init vd_nodename.
Don't copy fields not set by _bfd_elf_swap_verdef_in.
In C++ mode:
src/gdb/gdbserver/ax.c: In function ‘eval_result_type gdb_eval_agent_expr(eval_agent_expr_context*, agent_expr*, ULONGEST*)’:
src/gdb/gdbserver/ax.c:1335:11: error: invalid conversion from ‘int’ to ‘eval_result_type’ [-fpermissive]
return 1;
^
"1" as an enum eval_result_type is expr_eval_empty_expression, but
clearly this wants to return expr_eval_unhandled_opcode.
gdb/gdbserver/ChangeLog:
2015-08-21 Pedro Alves <palves@redhat.com>
* ax.c (gdb_eval_agent_expr): Return expr_eval_unhandled_opcode
instead of literal 1.
Fixes:
../../src/gdb/dwarf2read.c:127:15: error: declaration of ‘asection* dwarf2_section_info::<anonymous union>::asection’ [-fpermissive]
asection *asection;
^
In file included from ../../src/gdb/common/common-types.h:35:0,
from ../../src/gdb/common/common-defs.h:44,
from ../../src/gdb/defs.h:28,
from ../../src/gdb/dwarf2read.c:31:
../bfd/bfd.h:1596:3: error: changes meaning of ‘asection’ from ‘typedef struct bfd_section asection’ [-fpermissive]
} asection;
^
gdb/ChangeLog:
2015-08-21 Tom Tromey <tromey@redhat.com>
* dwarf2read.c (struct dwarf2_section_info): Rename field
'asection' to 'section'.
(dwarf2_has_info, get_section_bfd_owner, get_section_bfd_section)
(dwarf2_locate_sections, dwarf2_locate_sections)
(locate_dwz_sections, locate_v1_virtual_dwo_sections)
(dwarf2_locate_dwo_sections, dwarf2_locate_dwo_sections)
(dwarf2_locate_v2_dwp_sections): Adjust.
This patch fixes the following bug in TUI:
(gdb) break foo
No symbol table is loaded. Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) <ENTER>
By submitting an empty command line to a secondary prompt, the line
corresponding to the secondary prompt is undesirably cleared and
overwritten. Outside of a secondary prompt, clearing the prompt line
after submitting an empty command line is intended behavior which
complements GDB's repeat-command shorthand. But inside a secondary
prompt, this behavior is undesired since the shorthand is not applicable
in that case. We should retain the secondary-prompt line even when it's
given no input.
This patch makes sure that a prompt that was given an empty command line
is cleared and overwritten only if it's not a secondary prompt. To
acheive this, a new predicate is defined which informs us whether the
current input handler is a secondary prompt.
gdb/ChangeLog:
* top.h (gdb_in_secondary_prompt_p): Declare.
* top.c (gdb_secondary_prompt_depth): Define.
(gdb_in_secondary_prompt_p): Define.
(gdb_readline_wrapper_cleanup): Decrement
gdb_secondary_prompt_depth.
(gdb_readline_wrapper): Increment gdb_secondary_prompt_depth.
* tui/tui-io.c (tui_getc): Don't clear the prompt line if we
are in a secondary prompt.
This is necessary to make sure that start_line is updated after a
command has been entered. Usually, start_line gets updated anyway
because most commands output text, and outputting text is done through
the function tui_puts, which updates start_line. However if a command
does not output text, then tui_puts will not get called and start_line
will not get updated in time for the next prompt to be displayed.
One can observe this bug by executing the command "delete" within TUI.
After executing, the prompt line
(gdb) delete
gets overwritten by the next prompt. With this patch, the prompt line
gets preserved.
gdb/ChangeLog:
* tui/tui-io.c (tui_getc): Use tui_putc instead of waddch to
emit the newline.
Running that test in a loop, I found a gdbserver core dump with the
following back trace:
Core was generated by `../gdbserver/gdbserver --once --multi :2346'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000406ab6 in inferior_regcache_data (inferior=0x0) at src/gdb/gdbserver/inferiors.c:236
236 return inferior->regcache_data;
(gdb) up
#1 0x0000000000406d7f in get_thread_regcache (thread=0x0, fetch=1) at src/gdb/gdbserver/regcache.c:31
31 regcache = (struct regcache *) inferior_regcache_data (thread);
(gdb) bt
#0 0x0000000000406ab6 in inferior_regcache_data (inferior=0x0) at src/gdb/gdbserver/inferiors.c:236
#1 0x0000000000406d7f in get_thread_regcache (thread=0x0, fetch=1) at src/gdb/gdbserver/regcache.c:31
#2 0x0000000000409271 in prepare_resume_reply (buf=0x20dd593 "", ptid=..., status=0x20edce0) at src/gdb/gdbserver/remote-utils.c:1147
#3 0x000000000040ab0a in vstop_notif_reply (event=0x20edcc0, own_buf=0x20dd590 "T05") at src/gdb/gdbserver/server.c:183
#4 0x0000000000426b38 in notif_write_event (notif=0x66e6c0 <notif_stop>, own_buf=0x20dd590 "T05") at src/gdb/gdbserver/notif.c:69
#5 0x0000000000426c55 in handle_notif_ack (own_buf=0x20dd590 "T05", packet_len=8) at src/gdb/gdbserver/notif.c:113
#6 0x000000000041118f in handle_v_requests (own_buf=0x20dd590 "T05", packet_len=8, new_packet_len=0x7fff742c77b8)
at src/gdb/gdbserver/server.c:2862
#7 0x0000000000413850 in process_serial_event () at src/gdb/gdbserver/server.c:4148
#8 0x0000000000413945 in handle_serial_event (err=0, client_data=0x0) at src/gdb/gdbserver/server.c:4196
#9 0x000000000041a1ef in handle_file_event (event_file_desc=5) at src/gdb/gdbserver/event-loop.c:429
#10 0x00000000004199b6 in process_event () at src/gdb/gdbserver/event-loop.c:184
#11 0x000000000041a735 in start_event_loop () at src/gdb/gdbserver/event-loop.c:547
#12 0x00000000004123d2 in captured_main (argc=4, argv=0x7fff742c7ac8) at src/gdb/gdbserver/server.c:3562
#13 0x000000000041252e in main (argc=4, argv=0x7fff742c7ac8) at src/gdb/gdbserver/server.c:3631
Clearly this means that a thread pushed a stop reply in the event
queue, and then before GDB confused the event, the whole process died,
along with its thread. But the pending thread event was left
dangling. When GDB fetched that event, gdbserver looked up the
corresponding thread, but found NULL; not expecting this, gdbserver
crashes when it tries to read this thread's registers.
gdb/gdbserver/
2015-08-21 Pedro Alves <palves@redhat.com>
PR gdb/18749
* inferiors.c (remove_thread): Discard any pending stop reply for
this thread.
* server.c (remove_all_on_match_pid): Rename to ...
(remove_all_on_match_ptid): ... this. Work with a filter ptid
instead of a pid.
(discard_queued_stop_replies): Change parameter to a ptid. Now
extern.
(handle_v_kill, kill_inferior_callback)
(process_serial_event): Adjust.
(captured_main): Call initialize_notif before starting the
program, thus before threads are created.
* server.h (discard_queued_stop_replies): Declare.
In all-stop mode, if the current thread disappears while stopping all
threads, gdbserver calls set_desired_thread(0) ['0' means "I want the
continue thread"] which just picks the first thread in the list.
This looks like a dangerous thing to do. GDBserver continues
processing whatever it was doing, but to the wrong thread. If
debugging more than one process, we may even pick the wrong process.
Instead, GDBserver should detect the situation and bail out of
whatever is was doing.
The backends used to pay attention to the set 'cont_thread' (the Hc
thread, used in the old way to resume threads, before vCont), but all
such 'cont_thread' checks have been eliminated meanwhile. The
remaining implicit dependencies that I found on there being a selected
thread in the backends are in the Ctrl-C handling, which some backends
use as thread to send a signal to. Even that seems to me to be better
handled by always using the first thread in the list or by using the
signal_pid PID.
In order to make this a systematic approach, I'm making
set_desired_thread never fallback to a random thread, and instead end
up with current_thread == NULL, like already done in non-stop mode.
Then I updated all callers to handle the situation.
I stumbled on this while fixing other bugs exposed by
gdb.threads/fork-plus-threads.exp test. The problems I saw were fixed
in a different way, but in any case, I think the potential for
problems is more or less obvious, and the resulting code looks a bit
less magical to me.
Tested on x86-64 Fedora 20, w/ native-extended-gdbserver board.
gdb/gdbserver/ChangeLog:
2015-08-21 Pedro Alves <palves@redhat.com>
* linux-low.c (wait_for_sigstop): Always switch to no thread
selected if the previously current thread dies.
* lynx-low.c (lynx_request_interrupt): Use the first thread's
process instead of the current thread's.
* remote-utils.c (input_interrupt): Don't check if there's no
current thread.
* server.c (gdb_read_memory, gdb_write_memory): If setting the
current thread to the general thread fails, error out.
(handle_qxfer_auxv, handle_qxfer_libraries)
(handle_qxfer_libraries_svr4, handle_qxfer_siginfo)
(handle_qxfer_spu, handle_qxfer_statictrace, handle_qxfer_fdpic)
(handle_query): Check if there's a thread selected instead of
checking whether there's any thread in the thread list.
(handle_qxfer_threads, handle_qxfer_btrace)
(handle_qxfer_btrace_conf): Don't error out early if there's no
thread in the thread list.
(handle_v_cont, myresume): Don't set the current thread to the
continue thread.
(process_serial_event) <Hg handling>: Also set thread_id if the
previous general thread is still alive.
(process_serial_event) <g/G handling>: If setting the current
thread to the general thread fails, error out.
* spu-low.c (spu_resume, spu_request_interrupt): Use the first
thread's lwp instead of the current thread's.
* target.c (set_desired_thread): If the desired thread was not
found, leave the current thread pointing to NULL. Return an int
(boolean) indicating success.
* target.h (set_desired_thread): Change return type to int.
GDB provides no indicator of progress during file operations, and can
appear to have locked up during slow remote transfers. This commit
updates GDB to print a warning each time a file is accessed over RSP.
An additional message detailing how to avoid remote transfers is
printed for the first transfer only.
gdb/ChangeLog:
* target.h (struct target_ops) <to_fileio_open>: New argument
warn_if_slow. Update comment. All implementations updated.
(target_fileio_open_warn_if_slow): New declaration.
* target.c (target_fileio_open): Renamed as...
(target_fileio_open_1): ...this. New argument warn_if_slow.
Pass warn_if_slow to implementation. Update debug printing.
(target_fileio_open): New function.
(target_fileio_open_warn_if_slow): Likewise.
* gdb_bfd.c (gdb_bfd_iovec_fileio_open): Use new function
target_fileio_open_warn_if_slow.
gdb/testsuite/ChangeLog:
* gdb.trace/pending.exp: Cope with remote transfer warnings.
This commit fixes a stale cleanup left by linux_mntns_access_fs.
gdb/ChangeLog:
* nat/linux-namespaces.c (linux_mntns_access_fs):
Do not overwrite old_chain.
These changes allow debugging multithreaded NPTL xtensa applications.
2015-08-20 Max Filippov <jcmvbkbc@gmail.com>
gdb/gdbserver/
* configure.srv (xtensa*-*-linux*): Add srv_linux_thread_db=yes.
* linux-xtensa-low.c (arch/xtensa.h gdb_proc_service.h): New
#includes.
(ps_get_thread_area): New function.
2015-08-20 Max Filippov <jcmvbkbc@gmail.com>
gdb/
* arch/xtensa.h: New file.
* xtensa-linux-nat.c (gdb_proc_service.h): New #include.
(ps_get_thread_area): New function.
* xtensa-linux-tdep.c (xtensa_linux_init_abi): Add call to
set_gdbarch_fetch_tls_load_module_address to enable TLS support.
* xtensa-tdep.c (osabi.h): New #include.
(xtensa_gdbarch_init): Call gdbarch_init_osabi to register
xtensa-specific hooks.
* xtensa-tdep.h (struct xtensa_elf_gregset_t): Add threadptr
member and move the structure to arch/xtensa.h.
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.
