GDB Administrator [Tue, 1 Dec 2015 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in
Antoine Tremblay [Thu, 19 Nov 2015 16:29:10 +0000 (11:29 -0500)]
Remove too simple breakpoint_reinsert_addr implementations.
This patch removes too simple implementations of the breakpoint_reinsert_addr
operation.
The only reason to keep them around was to support thread events when
PTRACE_EVENT_CLONE was not present but this support has been removed in a
previous patch.
No regressions, tested on ubuntu 14.04 ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
Also compilation was tested on aarch64, bfin, cris, crisv32,
m32r, mips, nios2, ppc, s390, sparc, tic6x, tile, xtensa.
gdb/gdbserver/ChangeLog:
* linux-arm-low.c (arm_reinsert_addr): Remove function.
(struct linux_target_ops <breakpoint_reinsert_addr>: Set to NULL.
* linux-cris-low.c (cris_reinsert_addr> Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
* linux-crisv32-low.c (cris_reinsert_addr): Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
* linux-mips-low.c (mips_reinsert_addr): Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
* linux-nios2-low.c (nios2_reinsert_addr): Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
* linux-sparc-low.c (sparc_reinsert_addr): Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
Antoine Tremblay [Thu, 19 Nov 2015 16:29:10 +0000 (11:29 -0500)]
Remove support for thread events without PTRACE_EVENT_CLONE in GDBServer.
This patch removes support for thread events if PTRACE_EVENT_CLONE is not
supported in GDBServer.
Before, on systems that did not support PTRACE_EVENT_CLONE, both GDB and
GDBServer coordinated with libthread_db.so to insert breakpoints at magic
locations in libpthread.so, in order to break at thread creation and thread
death.
Simple software single stepping support was implemented to step over these
breakpoints in case there was no hardware single stepping support. However,
these simple software single stepping implementations were not fit for any other
use as discussed in :
https://sourceware.org/ml/gdb-patches/2015-04/msg01110.html
These too simple implementations conflict with ongoing work to make proper
implementations of software single stepping in GDBServer.
The problem is that if some implementations are correct and others are not and
only there for the thread magic breakpoint, we can't enable features based
solely software single step support since some would be broken.
To keep the incorrect implementations and allow the new proper ones at the same
time we would need to implement fallback code and it quickly becomes ugly and
confusing with multiple checks for legacy software single step or proper
software single step.
However, PTRACE_EVENT_CLONE was first introduced in Linux 2.5.46,
released in November 2002.
So I think it's reasonable to just remove support for kernels that don't support
PTRACE_EVENT_CLONE, and sidestep the libthread_db breakpoints issues entirely.
This thread on the mailling list discusses the issue :
https://sourceware.org/ml/gdb/2015-10/msg00078.html
No regressions, tested on ubuntu 14.04 ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_look_up_symbols): Don't call
linux_supports_traceclone.
* linux-low.h (thread_db_init): Remove use_events argument.
* thread-db.c (thread_db_use_event): Remove global variable.
(struct thread_db) <td_thr_event_enable_p>: Remove field.
(struct thread_db) <td_create_bp>: Remove field.
(thread_db_create_event): Remove function.
(thread_db_enable_reporting): Likewise.
(find_one_thread): Don't check for thread_db_use_events.
(attach_thread): Likewise.
(thread_db_load_search): Remove td_thr_event_enable_p initialization.
(try_thread_db_load_1): Don't check for thread_db_use_events.
(thread_db_init): Remove use_events argument and thread events
handling.
(remove_thread_event_breakpoints): Remove function.
(thread_db_detach): Remove call to remove_thred_event_breakpoints.
Antoine Tremblay [Thu, 19 Nov 2015 16:29:10 +0000 (11:29 -0500)]
Refactor queries for hardware and software single stepping support in GDBServer.
Before this patch there was only one call: can_hardware_single_step. Its
implementation was a check on breakpoint_reinsert_addr if NULL it assumed
that the target could hardware single step.
This patch prepares for the case where this is not true anymore.
In order to improve software single stepping in GDBServer the
breakpoint_reinsert_addr operation of targets that had a very simple
software implementation used only for stepping over thread creation events
will be removed.
This will create a case where a target does not support hardware single
step and has the operation breakpoint_reinsert_addr set to NULL, thus
can_hardware_single_step needs to be implemented another way.
A new target operation supports_hardware_single_step is introduced and is
to return true if the target does support such a feature, support for the
feature is manually hardcoded.
Note that the hardware single step support was enabled as per the current
behavior, I did not check if tile for example really has ptrace singlestep
support but since the current implementation assumed it had, I kept it
that way.
No regressions on Ubuntu 14.04 on ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
Compilation tested on: aarch64,arm,bfind,crisv32,m32r,ppc,s390,tic6x,tile,
xtensa.
Not tested : sh.
gdb/gdbserver/ChangeLog:
* linux-aarch64-low.c (aarch64_supports_hardware_single_step):
New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-arm-low.c (arm_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-bfin-low.c (bfin_supports_hardware_single_step): New function.
(struct linux_target_ops) <bfin_supports_hardware_single_step>:
Initialize.
* linux-crisv32-low.c (cris_supports_hardware_single_step):
New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-low.c (can_hardware_single_step): Use
supports_hardware_single_step.
(can_software_single_step): New function.
(start_step_over): Call can_software_single_step.
(linux_supports_hardware_single_step): New function.
(struct target_ops) <supports_software_single_step>: Initialize.
* linux-low.h (struct linux_target_ops)
<supports_hardware_single_step>: Initialize.
* linux-m32r-low.c (m32r_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-ppc-low.c (ppc_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step> Initialize.
* linux-s390-low.c (s390_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-sh-low.c (sh_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-tic6x-low.c (tic6x_supports_hardware_single_step): New function.
(struct linux_target_ops) <tic6x_supports_hardware_single_step>:
Initialize.
* linux-tile-low.c (tile_supports_hardware_single_step): New function.
(struct linux_target_ops) <tile_supports_hardware_single_step>:
Initialize.
* linux-x86-low.c (x86_supports_hardware_single_step) New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-xtensa-low.c (xtensa_supports_hardware_single_step):
New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* target.h (struct target_ops): <supports_software_single_step>:
New field.
(target_supports_software_single_step): New macro.
Antoine Tremblay [Mon, 30 Nov 2015 20:16:22 +0000 (15:16 -0500)]
Fix instruction skipping when using software single step in GDBServer
Without this patch, when doing a software single step, with for example
a conditional breakpoint, gdbserver would wrongly avance the pc of
breakpoint_len and skips an instruction.
This is due to gdbserver assuming that it's hardware single stepping.
When it resumes from the breakpoint address it expects the trap to be
caused by ptrace and if it's rather caused by a software breakpoint
it assumes this is a permanent breakpoint and that it needs to skip
over it.
However when software single stepping, this breakpoint is legitimate as
it's the reinsert breakpoint gdbserver has put in place to break at
the next instruction. Thus gdbserver wrongly advances the pc and skips
an instruction.
This patch fixes this behavior so that gdbserver checks if it is a
reinsert breakpoint from software single stepping. If it is it won't
advance the pc. And if there's no reinsert breakpoint there we assume
then that it's a permanent breakpoint and advance the pc.
Here's a commented log of what would happen before and after the fix on
gdbserver :
/* Here there is a conditional breakpoint at 0x10428 that needs to be
stepped over. */
Need step over [LWP 11204]? yes, found breakpoint at 0x10428
...
/*
e7f001f0 is a breakpoint instruction on arm
Here gdbserver writes the software breakpoint we would like to hit
*/
Writing
e7f001f0 to 0x0001042c in process 11204
...
Resuming lwp 11220 (continue, signal 0, stop not expected)
pending reinsert at 0x10428
stop pc is
00010428
continue from pc 0x10428
...
/* Here gdbserver hit the software breakpoint that was in place
for the step over */
stop pc is
0001042c
pc is 0x1042c
step-over for LWP 11220.11220 executed software breakpoint
Finished step over.
Could not find fast tracepoint jump at 0x10428 in list (reinserting).
/* Here gdbserver writes back the original instruction */
Writing
e50b3008 to 0x0001042c in process 11220
Step-over finished.
Need step over [LWP 11220]? No
/* Here because gdbserver assumes this is a permenant breakpoint it advances
the pc of breakpoint_len, in this case 4 bytes, so we have just skipped
the instruction that was written back here :
Writing
e50b3008 to 0x0001042c in process 11220
*/
stop pc is
00010430
pc is 0x10430
Need step over [LWP 11220]? No, no breakpoint found at 0x10430
Proceeding, no step-over needed
proceed_one_lwp: lwp 11220
stop pc is
00010430
This patch fixes this situation and we get the right behavior :
Writing
e50b3008 to 0x0001042c in process 11245
Hit a gdbserver breakpoint.
Hit a gdbserver breakpoint.
Step-over finished.
proceeding all threads.
Need step over [LWP 11245]? No
stop pc is
0001042c
pc is 0x1042c
Need step over [LWP 11245]? No, no breakpoint found at 0x1042c
Proceeding, no step-over needed
proceed_one_lwp: lwp 11245
stop pc is
0001042c
pc is 0x1042c
Resuming lwp 11245 (continue, signal 0, stop not expected)
stop pc is
0001042c
continue from pc 0x1042c
It also works if the value at 0x0001042c is a permanent breakpoint.
If so gdbserver will finish the step over, remove the reinserted breakpoint,
resume at that location and on the next SIGTRAP gdbserver will trigger
the advance PC condition as reinsert_breakpoint_inserted_here will be false.
I also tested this against bp-permanent.exp on arm (with a work in progress
software single step patchset) without any regressions.
It's also tested against x86 bp-permanent.exp without any regression.
So both software and hardware single step are tested.
No regressions on Ubuntu 14.04 on ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_wait_1): Fix pc advance condition.
* mem-break.c (reinsert_breakpoint_inserted_here): New function.
* mem-break.h (reinsert_breakpoint_inserted_here): New declaration.
Antoine Tremblay [Mon, 30 Nov 2015 20:08:04 +0000 (15:08 -0500)]
Fix breakpoint size when stepping over a permanent breakpoint in GDBServer.
When manually stepping over a permanent breakpoint on ARM we need to fetch the
right breakpoint size based on the current instruction set used.
Since this is not encoded in the stop_pc, the instruction mode needs to be
fetched from the CPSR register.
This is done by introducing a new target operation called :
breakpoint_kind_from_current_state.
For other targets that do not need this, breakpoint_kind_from_pc is used.
No regressions, tested on ubuntu 14.04 ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
gdb/gdbserver/ChangeLog:
* linux-arm-low.c (arm_is_thumb_mode): New function.
(arm_breakpoint_at): Use arm_is_thumb_mode.
(arm_breakpoint_kind_from_current_state): New function.
(struct linux_target_ops) <breakpoint_kind_from_current_state>:
Initialize.
* linux-low.c (linux_wait_1): Call breakpoint_kind_from_current_state.
(linux_breakpoint_kind_from_current_state): New function.
(struct target_ops <breakpoint_kind_from_current_state>: Initialize.
* linux-low.h (struct linux_target_ops)
<breakpoint_kind_from_current_state>: New field.
* target.h (struct target_ops): Likewise.
(target_breakpoint_kind_from_current_state): New macro.
Pedro Alves [Mon, 30 Nov 2015 16:05:27 +0000 (16:05 +0000)]
gdbserver: don't exit until GDB disconnects
When testing with "target remote" with "maint set target-non-stop on",
we regressions like this:
Running /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/continue-pending-after-query.exp ...
FAIL: gdb.threads/continue-pending-after-query.exp: iter 4: continue until exit
FAIL: gdb.threads/continue-pending-after-query.exp: iter 6: continue until exit
FAIL: gdb.threads/continue-pending-after-query.exp: iter 10: continue until exit
=== gdb Summary ===
# of expected passes 28
# of unexpected failures 3
where gdb.log shows:
continue
Continuing.
Remote communication error. Target disconnected.: Connection reset by peer.
(gdb) FAIL: gdb.threads/continue-pending-after-query.exp: iter 4: continue until exit
Enabling gdb + gdbserver debug logs we see:
gdbserver: <<<< exiting linux_wait_1
gdbserver: handling possible serial event
gdbserver: Writing resume reply for LWP 11089.11089:0
gdbserver: handling possible serial event
gdbserver: GDBserver exiting
GDB: Packet received: OK
GDB: infrun: prepare_to_wait
GDB: Sending packet: $vStopped#55...Packet received: W0;process:2b51
GDB: Sending packet: $vStopped#55...Packet received: OK
GDB: infrun: target_wait (-1.0.0, status) =
GDB: infrun: -1.0.0 [Thread 0],
GDB: infrun: status->kind = no-resumed
GDB: Sending packet: $Hgp2b51.2b51#41...Remote connection closed
(gdb) FAIL: gdb.threads/continue-pending-after-query.exp: iter 1: continue until exit
Notice the "Packet received: W0;process:2b51" followed by
vStopped->OK.
That means the process exit notification was successfully sent to GDB
and GDB fetched it. That makes gdbserver exit, in
server.c:process_serial_event:
if (!extended_protocol && have_ran && !target_running ())
{
/* In non-stop, defer exiting until GDB had a chance to query
the whole vStopped list (until it gets an OK). */
if (QUEUE_is_empty (notif_event_p, notif_stop.queue))
{
/* Be transparent when GDB is connected through stdio -- no
need to spam GDB's console. */
if (!remote_connection_is_stdio ())
fprintf (stderr, "GDBserver exiting\n");
remote_close ();
exit (0);
}
}
However, GDB is still busy processing an earlier "no-resumed" event,
and sends a "Hg" packet, which errors out with "Remote connection
closed". IOW, it's not enough to wait for GDB to query the whole
vStopped list, gdbserver needs to wait until the exit event is really
processed.
The fix is to make gdbserver not disconnect until gdb does.
Tested on x86_64 Fedora, native gdbserver, remote + extended-remote +
with and without "maint set target-non-stop on".
gdb/gdbserver/ChangeLog:
2015-10-14 Pedro Alves <palves@redhat.com>
* remote-utils.c (readchar): Don't print "Got EOF" unless
debugging gdbserver.
* server.c (captured_main): Exit gdbserver if gdb disconnects when
in "target remote" mode and there are no processes left to debug.
(process_serial_event): Remove 'have_ran' static local and remove
logic that exits gdbserver in "target remote" mode.
Pedro Alves [Mon, 30 Nov 2015 16:05:26 +0000 (16:05 +0000)]
gdbserver/linux: Always wake up event loop after resume
Running killed-outside.exp in with "maint set target-non-stop on"
hangs currently. This test has the inferior process die with a
SIGKILL while stopped. gdbserver gets a SIGCHLD and reacts by
retrieveing the SIGKILL events out of waitpid. But because the
process is not resumed from GDB's perspective, the event is left
pending. When GDB resumes the process afterwards, the process is not
really resumed because it already has the event pending. But nothing
wakes up the event loop to consume the event.
Handle this in the same way nat/linux-nat.c:linux_nat_resume handles
this.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_resume): Wake up the event loop before
returning.
Pedro Alves [Mon, 30 Nov 2015 16:05:26 +0000 (16:05 +0000)]
gdbserver:prepare_access_memory: pick another thread
Say GDB wants to access the inferior process's memory. The current
remote general thread is 3, but GDB's switched to thread 2. Because
both threads are of the same process, GDB skips making the remote
thread be thread 2 as well (sending an Hg packet) before accessing
memory (remote.c:set_general_process). However, if thread 3 has
exited meanwhile, thread 3 no longer exists on the server and
gdbserver points current_thread to NULL. The result is the memory
access fails, even through the process still exists.
Fix this by making prepare_to_access memory select the thread to
access memory through.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* mem-break.c (check_gdb_bp_preconditions): Remove current_thread
check.
(set_gdb_breakpoint): If prepare_to_access_memory fails, set *ERR
to -1.
* target.c (struct thread_search): New structure.
(thread_search_callback): New function.
(prev_general_thread): New global.
(prepare_to_access_memory, done_accessing_memory): New functions.
* target.h (prepare_to_access_memory, done_accessing_memory):
Replace macros with function declarations.
Pedro Alves [Mon, 30 Nov 2015 16:05:25 +0000 (16:05 +0000)]
Implement TARGET_WAITKIND_NO_RESUMED in the remote protocol
Testing with "maint set target-non-stop on" causes regressions in
tests that rely on TARGET_WAITKIND_NO_RESUMED, which isn't modelled on
the RSP. In real all-stop, gdbserver detects the situation and
reporst error to GDB, and so the tests (e.g.,
gdb.threads/no-unwaited-for-left.exp) at fail quickly. But with
"maint set target-non-stop on", GDB instead hangs forever waiting for
a stop reply that never comes, and so the tests take longer to time
out.
This adds a new "N" stop reply packet that maps 1-1 to
TARGET_WAITKIND_NO_RESUMED.
gdb/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
PR 14618
* NEWS (New remote packets): Mention the N stop reply.
* remote.c (remote_protocol_features): Add "no-resumed" entry.
(remote_query_supported): Report no-resumed+ support.
(remote_parse_stop_reply): Handle 'N'.
(process_stop_reply): Handle TARGET_WAITKIND_NO_RESUMED.
(remote_wait_as): Handle 'N' / TARGET_WAITKIND_NO_RESUMED.
(_initialize_remote): Register "set/show remote
no-resumed-stop-reply" commands.
gdb/doc/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
PR 14618
* gdb.texinfo (Stop Reply Packets): Document the N stop reply.
(Remote Configuration): Add the "set/show remote
no-resumed-stop-reply" to the available settings table.
(General Query Packets): Document the "no-resumed" qSupported
feature.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
PR 14618
* linux-low.c (linux_wait_1): If the last resumed thread is gone,
report TARGET_WAITKIND_NO_RESUMED.
* remote-utils.c (prepare_resume_reply): Handle
TARGET_WAITKIND_NO_RESUMED.
* server.c (report_no_resumed): New global.
(handle_query) <qSupported>: Handle "no-resumed+". Report
"no-resumed+" support.
(resume): When the target reports TARGET_WAITKIND_NO_RESUMED, only
return error if the client doesn't support no-resumed events.
(push_stop_notification): New function.
(handle_target_event): Use it. Report TARGET_WAITKIND_NO_RESUMED
events if the client supports them.
gdb/testsuite/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.threads/no-unwaited-for-left.exp: Remove setup_kfail calls.
Pedro Alves [Mon, 30 Nov 2015 16:05:24 +0000 (16:05 +0000)]
infrun: Fix TARGET_WAITKIND_NO_RESUMED handling in non-stop mode
Running the testsuite against gdbserver with "maint set target-non-stop on"
stumbled on a set of problems. See code comments for details.
This handles my concerns expressed in PR14618.
gdb/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
PR 14618
* infrun.c (handle_no_resumed): New function.
(handle_inferior_event_1) <TARGET_WAITKIND_NO_RESUMED>: Defer to
handle_no_resumed.
Pedro Alves [Mon, 30 Nov 2015 16:05:23 +0000 (16:05 +0000)]
testsuite: Range stepping and non-stop mode
The range-stepping tests fail with "maint set target-non-stop on" mode
because exec_cmd_expect_vCont_count doesn't know that in non-stop
mode, vCont's reply is simply "OK".
gdb/testsuite/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* lib/range-stepping-support.exp (exec_cmd_expect_vCont_count):
Handle non-stop mode vCont replies.
Pedro Alves [Mon, 30 Nov 2015 16:05:23 +0000 (16:05 +0000)]
gdbserver: fix killed-outside.exp
killed-outside.exp regresses with "maint set target-non-stop on". The
logs show:
(gdb) continue
Continuing.
infrun: clear_proceed_status_thread (Thread 9028.9028)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming Thread 9028.9028
Sending packet: $Z0,
3615a03966,1#4b... Notification received: Stop:X9;process:2344
Packet received: E01
Sending packet: $Z0,
3615a13970,1#47...Packet received: E01
Sending packet: $Z0,
3615a14891,1#4a...Packet received: E01
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 9028.9028] at 0x4005e4
Sending packet: $vCont;c:p2344.2344#1a...Packet received: E.target not running.
Sending packet: $qXfer:threads:read::0,fff#03...Packet received: l<threads>\n</threads>\n
Sending packet: $vStopped#55...Packet received: OK
Unexpected vCont reply in non-stop mode: E.target not running.
(gdb) remote_async_inferior_event_handler
infrun: target_wait (-1.0.0, status) =
infrun: 9028.0.0 [process 9028],
infrun: status->kind = signalled, signal = GDB_SIGNAL_KILL
infrun: TARGET_WAITKIND_SIGNALLED
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
infrun: stop_waiting
infrun: clear_step_over_info
infrun: stop_all_threads
remote_thread_exit_events(1)
Note the "Unexpected vCont reply" error.
I traced it to a problem in status_pending_p_callback. It resumes an
LWP when it shouldn't.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (thread_still_has_status_pending_p): Don't check
vCont;t here.
(lwp_resumed): New function.
(status_pending_p_callback): Return early if the LWP is not
supposed to be resumed.
Pedro Alves [Mon, 30 Nov 2015 16:05:21 +0000 (16:05 +0000)]
Remote thread create/exit events
When testing with "maint set target-non-stop on", a few
threading-related tests expose an issue that requires new RSP packets.
Say there are 3 threads running, 1-3. If GDB tries to stop thread 1,
2 and 3, and then waits for their stops, but meanwhile say, thread 2
exits, GDB hangs forever waiting for a stop for thread 2 that won't
ever happen.
This patch fixes the issue by adding support for thread exit events to
the protocol. However, we don't want these always enabled, as they're
useless most of the time, and would slow down remote debugging. So I
made it so that GDB can enable/disable them, and then made gdb do that
around the cases that need it, which currently is only
infrun.c:stop_all_threads.
In turn, if we have thread exit events, then the extra "thread x
exited" traffic slows down attach-many-short-lived-threads.exp enough
that gdb has trouble keeping up with new threads that are spawned
while gdb tries to stop existing ones. To fix that I added support
for the counterpart thread created events too. Enabling those when we
try to stop threads ensures that new threads never get a chance to
themselves start new threads, killing the race.
gdb/doc/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Remote Configuration): List "set/show remote
thread-events" command in configuration table.
(Stop Reply Packets): Document "T05 create" stop
reason and 'w' stop reply.
(General Query Packets): Document QThreadEvents packet. Document
QThreadEvents qSupported feature.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Assert that the LWP's
waitstatus is TARGET_WAITKIND_IGNORE. If GDB wants to hear about
thread create events, leave the new child's status pending.
(linux_low_filter_event): If GDB wants to hear about thread exit
events, leave the LWP marked dead and don't delete it.
(linux_wait_for_event_filtered): Don't check for thread exit.
(filter_exit_event): New function.
(linux_wait_1): Use it, when returning an exit event.
(linux_resume_one_lwp_throw): Assert that the LWP's
waitstatus is TARGET_WAITKIND_IGNORE.
* remote-utils.c (prepare_resume_reply): Handle
TARGET_WAITKIND_THREAD_CREATED and TARGET_WAITKIND_THREAD_EXITED.
* server.c (report_thread_events): New global.
(handle_general_set): Handle QThreadEvents.
(handle_query) <qSupported>: Handle and report QThreadEvents+;
(handle_target_event): Handle TARGET_WAITKIND_THREAD_CREATED and
TARGET_WAITKIND_THREAD_EXITED.
* server.h (report_thread_events): Declare.
gdb/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* NEWS (New commands): Mention "set/show remote thread-events"
commands.
(New remote packets): Mention thread created/exited stop reasons
and QThreadEvents packet.
* infrun.c (disable_thread_events): New function.
(stop_all_threads): Disable/enable thread create/exit events.
Handle TARGET_WAITKIND_THREAD_EXITED.
(handle_inferior_event_1): Handle TARGET_WAITKIND_THREAD_CREATED
and TARGET_WAITKIND_THREAD_EXITED.
* remote.c (remove_child_of_pending_fork): Also remove threads of
threads that have TARGET_WAITKIND_THREAD_EXITED events.
(remote_parse_stop_reply): Handle "create" magic register. Handle
'w' stop reply.
(initialize_remote): Install remote_thread_events as
to_thread_events target hook.
(remote_thread_events): New function.
* target-delegates.c: Regenerate.
* target.c (target_thread_events): New function.
* target.h (struct target_ops) <to_thread_events>: New field.
(target_thread_events): Declare.
* target/waitstatus.c (target_waitstatus_to_string): Handle
TARGET_WAITKIND_THREAD_CREATED and TARGET_WAITKIND_THREAD_EXITED.
* target/waitstatus.h (enum target_waitkind)
<TARGET_WAITKIND_THREAD_CREATED, TARGET_WAITKIND_THREAD_EXITED):
New values.
Pedro Alves [Mon, 30 Nov 2015 16:05:19 +0000 (16:05 +0000)]
Make dprintf-non-stop.exp cope with remote testing
Testing with the extended-remote board with "maint set target-non-stop
on" shows a dprintf-non-stop.exp regression. The issue is simply that
the test is expecting output that is only valid for the native target:
native:
[process 8676] #1 stopped.
remote:
[Thread 8900.8900] #1 stopped.
In order to expose this without "maint set target-non-stop on", this
restarts gdb with non-stop mode already enabled.
gdb/testsuite/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.base/dprintf-non-stop.exp: Use build_executable instead of
prepare_for_testing. Start gdb with "set non-stop on" appended to
GDBFLAGS. Lax expected stop output.
Pedro Alves [Mon, 30 Nov 2015 16:05:19 +0000 (16:05 +0000)]
gdbserver resume_stop handling bug
Running attach-many-short-lived-threads.exp with the extended-remote
board with "maint set target-non-stop on" times out -- the attach
never completes. Enabling infrun debug logs, we see that GDB is stuck
stopping all threads:
infrun: target_wait (-1.0.0, status) =
infrun: 1639.22213.0 [Thread 1639.22213],
infrun: status->kind = stopped, signal = GDB_SIGNAL_0
infrun: Thread 1639.22260 not executing
infrun: Thread 1639.22256 not executing
infrun: Thread 1639.22258 not executing
infrun: Thread 1639.22257 not executing
infrun: Thread 1639.22259 not executing
infrun: Thread 1639.22255 not executing
infrun: Thread 1639.22253 executing, already stopping
infrun: Thread 1639.22251 executing, already stopping
infrun: Thread 1639.22252 executing, already stopping
infrun: Thread 1639.22250 executing, already stopping
infrun: Thread 1639.22254 executing, already stopping
infrun: Thread 1639.22247 executing, already stopping
infrun: Thread 1639.22213 not executing
infrun: Thread 1639.22207 not executing
infrun: Thread 1639.22201 not executing
infrun: Thread 1639.22219 not executing
infrun: Thread 1639.1639 not executing
** HANG HERE **
GDB is waiting for the stop replies of any of those "already stopping"
threads. Take 22253 for example. On the gdbserver logs we see:
...
resume_stop request for LWP 22253
stopping LWP 22253
Sending sigstop to lwp 22253
linux_resume done
...
and:
my_waitpid (-1, 0x40000001)
my_waitpid (-1, 0x80000001): status(3057f), 22253
LWFE: waitpid(-1, ...) returned 22253, ERRNO-OK
LLW: waitpid 22253 received Trace/breakpoint trap (stopped)
pc is 0x3615ef4ce1
HEW: Got clone event from LWP 22253, new child is LWP 22259
but from here on, we never see any other event for LWP 22253. In
particular, we never see the expected SIGSTOP (from "Sending sigstop"
above). The issue is that linux_resume_stopped_resumed_lwps never
re-resumes the 22253 after the clone event.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (resume_stopped_resumed_lwps): Don't check whether
the thread's last_resume_kind was resume_stop.
Pedro Alves [Mon, 30 Nov 2015 16:05:18 +0000 (16:05 +0000)]
gdbserver crash if gdb attaches too fast
With "maint set target-non-stop on", the attach tests occasionally
crash gdbserver.
Basically, gdb attaches with vAttach;PID, and then shortly after reads
the xml target description for that process, to figure out the
process' architecture. On the gdbserver side, the target description
is only filled in when the first process/thread in the thread group
reports its initial PTRACE_ATTACH SIGSTOP. So if GDB is fast enough,
it can read the target description _before_ that initial stop, and
then gdbserver dies dereferencing a NULL tdesc pointer.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_attach): In non-stop mode, wait for one stop
before returning.
Pedro Alves [Mon, 30 Nov 2015 16:05:17 +0000 (16:05 +0000)]
New vCtrlC packet, non-stop mode equivalent of \003
There's currently no non-stop equivalent of the all-stop ^C (\003)
"packet" that GDB sends when a ctrl-c is pressed while a foreground
command is active. There's vCont;t, but that's defined to cause a
"signal 0" stop.
This fixes many tests that type ^C, when testing with extended-remote
with "maint set target-non-stop on". E.g.:
Continuing.
talk to me baby
PASS: gdb.base/interrupt.exp: process is alive
a
a
PASS: gdb.base/interrupt.exp: child process ate our char
^C
[Thread 22730.22730] #1 stopped.
0x0000003615ee6650 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:81
81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) FAIL: gdb.base/interrupt.exp: send_gdb control C
p func1 ()
gdb/
2015-11-30 Pedro Alves <palves@redhat.com>
* NEWS (New remote packets): Mention vCtrlC.
* remote.c (PACKET_vCtrlC): New enum value.
(async_remote_interrupt): Call target_interrupt instead of
target_stop.
(remote_interrupt_as): Remove 'ptid' parameter.
(remote_interrupt_ns): New function.
(remote_stop): Adjust.
(remote_interrupt): If the target is in non-stop mode, try
interrupting with vCtrlC.
(initialize_remote): Install set remote ctrl-c packet.
gdb/doc/
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Bootstrapping): Add "interrupting remote targets"
anchor.
(Packets): Document vCtrlC.
gdb/gdbserver/
2015-11-30 Pedro Alves <palves@redhat.com>
* server.c (handle_v_requests): Handle vCtrlC.
Pedro Alves [Mon, 30 Nov 2015 16:05:16 +0000 (16:05 +0000)]
remote: stop reason and watchpoint data address per thread
Running local-watch-wrong-thread.exp with "maint set target-non-stop
on" exposes that gdb/remote.c only records whether the target stopped
for a breakpoint/watchpoint plus the watchpoint data address *for the
last reported remote event*. But in non-stop mode, we need to keep
that info per-thread, as each thread can end up with its own
last-status pending.
gdb/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* remote.c (struct remote_state) <remote_watch_data_address,
stop_reason>: Delete fields.
(struct private_thread_info) <stop_reason, watch_data_address>:
New fields.
(resume_clear_thread_private_info): New function.
(append_pending_thread_resumptions): Call it.
(remote_resume): Clear all threads' private info.
(process_stop_reply): Adjust.
(remote_wait_as): Don't reference remote_state's stop_reason
field.
(remote_stopped_by_sw_breakpoint)
(remote_stopped_by_hw_breakpoint, remote_stopped_by_watchpoint)
(remote_stopped_data_address): Adjust to refer get data from the
current thread.
Pedro Alves [Mon, 30 Nov 2015 16:05:15 +0000 (16:05 +0000)]
gdbserver crash running gdb.threads/non-ldr-exc-1.exp
This fixes a gdbserver crash when running
gdb.threads/non-ldr-exc-1.exp with "maint set target-non-stop on".
The problem is that qSymbol is called when gdbserver has
current_thread == NULL.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdbthread.h (find_any_thread_of_pid): Declare.
* inferiors.c (thread_of_pid, find_any_thread_of_pid): New
functions.
* server.c (handle_query): If current_thread is NULL, look for
another thread of the selected process.
Pedro Alves [Mon, 30 Nov 2015 16:05:14 +0000 (16:05 +0000)]
attach + target always in non-stop mode: stop all threads
When running with "maint set target-non-stop on", and in all-stop
mode, nothing is stopping all threads after attaching. vAttach in
non-stop can leave all threads running and GDB has to explicitly pause
them.
This is not visible with the native target, as in that case, attach
always stops all threads (the core re-resumes them in case of
"attach&").
In addition, it's not defined which thread manages to report the
initial attach stop, so always pick the lowest one (otherwise
multi-attach.exp regresses).
gdb/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* infcmd.c (attach_post_wait): If the target is always in non-stop
mode, and the UI is in all-stop mode, stop all threads and pick
the one with lowest number as current.
Pedro Alves [Mon, 30 Nov 2015 16:05:13 +0000 (16:05 +0000)]
Remote all-stop-on-top-of-non-stop
This is the first pass at implementing support for all-stop mode
running against the remote target using the non-stop variant of the
protocol.
The trickiest part here is the initial connection setup/synching. We
need to fetch all inferiors' target descriptions etc. before stopping
threads, because stop_all_threads needs to read the threads' registers
(to record each thread's stop_pc). But OTOH, the initial inferior
setup (target_post_attach, post_create_inferior, etc.), only works
correctly if the inferior is stopped... So I've split that initial
setup part from attach_command_post_wait to a separate function, and
added a "still needs setup" flag to the inferior structure. This is
similar to gdbserver/linux-low.c's handling of discovering the
process's target description). Then if on connection all threads of
the remote inferior are running, when we go about stopping them, as
soon as they stop we call setup_inferior, from within
stop_all_threads.
Also, in all-stop, we need to process all the initial stop replies to
learn about all the pending signal the threads may already be stopped
for, and pick the one to report as current. This is exposed by
gdb.threads/reconnect-signal.exp.
gdb/
2015-11-30 Pedro Alves <palves@redhat.com>
* gdbthread.h (switch_to_thread_no_regs): Declare.
* infcmd.c (setup_inferior): New function, factored out from ...
(attach_command_post_wait): ... this. Rename to ...
(attach_post_wait): ... this. Replace parameter async_exec with
attach_post_wait_mode parameter. Adjust.
(enum attach_post_wait_mode): New enum.
(struct attach_command_continuation_args): Replace 'async_exec'
field with 'mode' field.
(attach_command_continuation): Adjust.
(attach_command): Add comment. Mark the inferior as needing
setup. Adjust to use enum attach_post_wait_mode.
(notice_new_inferior): Use switch_to_thread_no_regs. Adjust to
use enum attach_post_wait_mode.
* inferior.h (setup_inferior): Declare.
(struct inferior) <needs_setup>: New field.
* infrun.c (set_last_target_status): Make extern.
(stop_all_threads): Make extern. Setup inferior, if necessary.
* infrun.h (set_last_target_status, stop_all_threads): Declare.
* remote-notif.c (remote_async_get_pending_events_handler)
(handle_notification): Replace non_stop checks with
target_is_non_stop_p() checks.
* remote.c (remote_notice_new_inferior): Remove non_stop check.
(remote_update_thread_list): Replace non_stop check with
target_is_non_stop_p() check.
(print_one_stopped_thread): New function.
(process_initial_stop_replies): New 'from_tty' parameter.
"Notice" all new live inferiors after storing initial stops as
pending status in each corresponding thread. If all-stop, stop
all threads, try picking a signalled thread as current, and print
the status of that one thread. Record the last target status.
(remote_start_remote): Replace non_stop checks with
target_is_non_stop_p() checks. Don't query for the remote current
thread of use qOffsets here. Pass from_tty to
process_initial_stop_replies.
(extended_remote_attach): Replace non_stop checks with
target_is_non_stop_p() checks.
(extended_remote_post_attach): Send qOffsets here.
(remote_vcont_resume, remote_resume, remote_stop)
(remote_interrupt, remote_parse_stop_reply, remote_wait): Replace
non_stop checks with target_is_non_stop_p() checks.
(remote_async): If target is non-stop, mark/clear the pending
events token.
* thread.c (switch_to_thread_no_regs): New function.
Pedro Alves [Mon, 30 Nov 2015 16:05:12 +0000 (16:05 +0000)]
Fix mi-nonstop.exp with extended-remote
Testing with "maint set target-non-stop on" makes mi-nonstop.exp run
with the extended-remote board. That reveals that mi-nonstop.exp is
using the wrong predicate to check for "using remote protocol".
This is not visible today because non-stop tests all fail to run with
extended-remote board, because they spawn gdb and then do "set
non-stop on". However, with that board, gdb connects to the gdbserver
from within mi_gdb_start, and changing non-stop when already connected
doesn't work. Fix that by instead enabling non-stop mode on gdb's
command line.
gdb/testsuite/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-nonstop.exp: Append "set non-stop on" to GDBFLAGS
instead of issuing "-gdb-set non-stop 1" after starting gdb.
Use mi_is_target_remote instead of checking "is_remote target".
* lib/gdb.exp (gdb_is_target_remote): Rename to ...
(gdb_is_target_remote_prompt): ... this, and add 'prompt_regexp'
parameter.
(gdb_is_target_remote): Reimplement.
* lib/mi-support.exp (mi_is_target_remote): New procedure.
Pedro Alves [Mon, 30 Nov 2015 18:32:24 +0000 (18:32 +0000)]
Fix ChangeLog entry
There should be only one date in multi-author entries.
Andrew Burgess [Fri, 16 Oct 2015 09:58:02 +0000 (11:58 +0200)]
objdump: Handle 32-bit base address in debug_ranges / debug_loc.
When the DWARF address size is 32-bit, but the host machine is 64-bit,
objdump fails to spot base addresses specified in the .debug_ranges and
.debug_loc lists.
As an example, here is the output when dumping an example .debug_ranges
section with the pre-patched objdump:
Contents of the .debug_ranges section:
Offset Begin End
00000000 ffffffff 00000004 (start > end)
00000000 00000000 00000004
00000000 ffffffff 00000008 (start > end)
00000000 00000000 00000004
00000000 <End of list>
And this is what the same section looks like when dumped with the
patched version of objdump:
Contents of the .debug_ranges section:
Offset Begin End
00000000 ffffffff 00000004 (base address)
00000000 00000004 00000008
00000000 ffffffff 00000008 (base address)
00000000 00000008 0000000c
00000000 <End of list>
binutils/ChangeLog:
* dwarf.c (is_max_address): New function.
(display_loc_list): Remove out of date comment, use
is_max_address.
(display_debug_ranges): Likewise.
binutils/testsuite/ChangeLog:
* binutils-all/objdump.exp: Add test for .debug_ranges decode.
* binutils-all/dw2-ranges.S: New file.
* binutils-all/dw2-ranges.W: New file.
GDB Administrator [Mon, 30 Nov 2015 00:00:08 +0000 (00:00 +0000)]
Automatic date update in version.in
Cary Coutant [Sun, 29 Nov 2015 01:19:52 +0000 (17:19 -0800)]
Update my email address in MAINTAINERS.
binutils/
* MAINTAINERS: Update my email address.
GDB Administrator [Sun, 29 Nov 2015 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in
Pedro Alves [Sat, 28 Nov 2015 16:39:32 +0000 (16:39 +0000)]
Adjust GDB to demangler API change
Before commit
3a8724032abf, DEMANGLE_COMPONENT_CAST was used for both
casts and conversion operators. We now have
DEMANGLE_COMPONENT_CONVERSION for the latter.
gdb/ChangeLog:
2014-11-28 Pedro Alves <palves@redhat.com>
* cp-name-parser.y (conversion_op): Use
DEMANGLE_COMPONENT_CONVERSION instead of DEMANGLE_COMPONENT_CAST.
Maxim Ostapenko [Sat, 28 Nov 2015 16:39:32 +0000 (16:39 +0000)]
libsanitizer merge from upstream r250806, compiler part.
gcc/
* asan.c (asan_emit_stack_protection): Don't pass local stack to
asan_stack_malloc_[n] anymore. Check if asan_stack_malloc_[n] returned
NULL and use local stack than.
(asan_finish_file): Insert __asan_version_mismatch_check_v[n] call
in addition to __asan_init.
* sanitizer.def (BUILT_IN_ASAN_INIT): Rename to __asan_init.
(BUILT_IN_ASAN_VERSION_MISMATCH_CHECK): Add new builtin call.
* asan.h (asan_intercepted_p): Handle new string builtins.
* ubsan.c (ubsan_use_new_style_p): New function.
(ubsan_instrument_float_cast): If location is unknown, assign
input_location to loc. Propagate loc to ubsan_create_data if
ubsan_use_new_style_p returned true.
config/
* bootstrap-asan.mk: Replace ASAN_OPTIONS=detect_leaks with
LSAN_OPTIONS=detect_leaks.
gcc/testsuite/
* c-c++-common/ubsan/float-cast-overflow-10.c: Adjust test.
* c-c++-common/ubsan/float-cast-overflow-8.c: Likewise.
* c-c++-common/ubsan/float-cast-overflow-9.c: Likewise.
* g++.dg/asan/default-options-1.C: Likewise.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@229112
138bc75d-0d04-0410-961f-
82ee72b054a4
Rainer Orth [Sat, 28 Nov 2015 16:39:32 +0000 (16:39 +0000)]
Port libvtv to Solaris
libstdc++-v3:
* acinclude.m4 (GLIBCXX_ENABLE_VTABLE_VERIFY) <solaris2*>: Use
-Wl,-R in VTV_CXXLINKFLAGS.
* configure: Regenerate.
* testsuite/18_support/bad_exception/23591_thread-1.c: Use
-fvtable-verify=none on Solaris 12+.
libgcc:
* Makefile.in (VTV_CFLAGS): New variable.
(vtv_start$(objext), vtv_end$(objext), vtv_end$(objext))
(vtv_start_preinit$(objext), vtv_end_preinit$(objext)): Use it.
* config.host (*-*-solaris2*): Add t-crtstuff-pic to tmake_file.
Add vtv_start.o, vtv_end.o, vtv_start_preinit.o, vtv_end_preinit.o
to extra_parts if $enable_vtable_verify = yes.
libvtv:
* configure.tgt (*-*-solaris2.[1-9]*): Declare supported.
* configure.ac: Call AC_USE_SYSTEM_EXTENSIONS.
<*-*-solaris2*>: Check for init priority support.
Check for getexecname, __fortify_fail, _obstack_begin.
(VTV_NO_OBSTACK): New conditional.
* configure: Regenerate.
* Makefile.am [VTV_NO_OBSTACK] (obstack.c): Use new condition.
Create empty config.h
* Makefile.in: Regenerate.
* vtv_rts.cc [HAVE_GETEXECNAME] (program_invocation_name): New
variable.
(read_section_offset_and_length) [HAVE_GETEXECNAME]: Set it.
(dl_iterate_phdr_callback) [HAVE_GETEXECNAME]: Set it.
(__fortify_fail): Wrap in HAVE___FORTIFY_FAIL
[!HAVE___FORTIFY_FAIL]: Provide non-Cygwin implementation.
(read_section_offset_and_length): Assert sh_size >= VTV_PAGE_SIZE.
(iterate_modules): Fix typo.
Use VTV_PAGE_SIZE.
(dl_iterate_phdr_callback): Fix typo.
Use VTV_PAGE_SIZE.
(__VLTChangePermission): Fix typos.
include:
* vtv-change-permission.h (VTV_PAGE_SIZE) [__sun__ && __svr4__ &&
__sparc__]: Define.
gcc:
* config/sol2.h (SUPPORTS_INIT_PRIORITY): Move up.
(STARTFILE_VTV_SPEC, ENDFILE_VTV_SPEC): Define.
(STARTFILE_SPEC): Use %(startfile_vtv).
(ENDFILE_SPEC): Use %(endfile_vtv).
(SUBTARGET_EXTRA_SPECS): Handle STARTFILE_VTV_SPEC,
ENDFILE_VTV_SPEC.
* gcc.c (LINK_COMMAND_SPEC): Move VTABLE_VERIFICATION_SPEC after %{L*}.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@230865
138bc75d-0d04-0410-961f-
82ee72b054a4
Rich Felker [Sat, 28 Nov 2015 16:39:31 +0000 (16:39 +0000)]
SH FDPIC backend support
gcc/ChangeLog
* config.gcc: Handle --enable-fdpic.
* config/sh/constraints.md (Ccl): New constraint.
* config/sh/linux.h (SUBTARGET_LINK_EMUL_SUFFIX): Handle -mfdpic.
* config/sh/sh-c.c (sh_cpu_cpp_builtins): Add __FDPIC__ and
__SH_FDPIC__.
* config/sh/sh-mem.cc (expand_block_move): Support FDPIC for calls
to library functions.
* config/sh/sh-protos.h (function_symbol_result): New struct.
(function_symbol): Return function_symbol_result.
(sh_get_fdpic_reg_initial_val, sh_load_function_descriptor): New
declarations.
* config/sh/sh.c (TARGET_ASM_INTEGER, sh_assemble_integer):
Implement target hook.
(TARGET_CANNOT_FORCE_CONST_MEM, sh_cannot_force_const_mem_p):
Likewise.
(sh_option_override): Force -fPIC if FDPIC is in effect.
(sh_asm_output_addr_const_extra): Add UNSPEC_GOTFUNCDESC and
UNSPEC_GOTOFFFUNCDESC cases.
(prepare_move_operands): Use FDPIC initial GOT register for
TLS-related GOT access; inhibit cross-section address offset
constants for FDPIC.
(sh_assemble_integer): New function.
(sh_cannot_copy_insn_p): Inhibit copying insns that are FDPIC
PC-relative call sites.
(expand_ashiftrt): Adapt invocation of function_symbol.
(sh_expand_prologue): Inhibit PC-relative GOT address load for
FDPIC.
(nonpic_symbol_mentioned_p): Add cases for UNSPEC_GOTFUNCDESC and
UNSPEC_GOTOFFFUNCDESC.
(legitimize_pic_address): Resolve function symbols to function
descriptors for FDPIC. Do not use GOT-relative addressing for
local data that may be read-only on FDPIC.
(sh_emit_storesi, sh_emit_storehi): New functions.
(sh_trampoline_init): Generate FDPIC trampolines.
(sh_function_ok_for_sibcall): Add TARGET_FDPIC check.
(sh_expand_sym_label2reg): Don't assume sibcalls are local.
(sh_output_mi_thunk): Generate FDPIC call.
(function_symbol): Return function_symbol_result. For
SFUNC_STATIC on FDPIC, generate call site labels to use
PC-relative addressing rather than GOT-relative addressing.
(sh_conditional_register_usage): Make PIC register fixed and call used
when FDPIC is in effect.
(sh_legitimate_constant_p): Impose FDPIC
constant constraints.
(sh_cannot_force_const_mem_p, sh_load_function_descriptor)
(sh_get_fdpic_reg_initial_val): New functions.
* config/sh/sh.h (SUBTARGET_ASM_SPEC, SUBTARGET_LINK_EMUL_SUFFIX):
Handle -mfdpic.
(FDPIC_SELF_SPECS, SUBTARGET_DRIVER_SELF_SPECS)
(PIC_OFFSET_TABLE_REG_CALL_CLOBBERED)
(SH_OFFSETS_MUST_BE_WITHIN_SECTIONS_P): New macros.
(DRIVER_SELF_SPECS): Add SUBTARGET_DRIVER_SELF_SPECS and
FDPIC_SELF_SPECS.
(TRAMPOLINE_SIZE): Select trampoline size for FDPIC.
(ASM_PREFERRED_EH_DATA_FORMAT): Add EH format constraints for
FDPIC.
(ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX): Handle FDPIC case.
* config/sh/sh.md (UNSPEC_GOTFUNCDESC, UNSPEC_GOTOFFFUNCDESC): New
constants.
(calli_fdpic, call_valuei_fdpic, sibcalli_fdpic)
(sibcalli_pcrel_fdpic, sibcall_pcrel_fdpic, sibcall_valuei_fdpic)
(sibcall_valuei_pcrel_fdpic, sibcall_value_pcrel_fdpic)
(sym2GOTFUNCDESC, symGOTFUNCDESC2reg, sym2GOTOFFFUNCDESC)
(symGOTOFFFUNCDESC2reg): New patterns.
(udivsi3_i1, udivsi3_i4, udivsi3_i4_single, udivsi3,
*divsi_inv_call_combine, divsi3_i4, divsi3_i4_single, divsi3)
(ashlsi3, ashlsi3_d_call, ashrsi3_n, lshrsi3, lshrsi3_d_call)
(calli, call_valuei, call, call_value, sibcalli, sibcalli_pcrel)
(sibcall_pcrel, sibcall, sibcall_valuei, sibcall_valuei_pcrel)
(sibcall_value_pcrel, sibcall_value, GOTaddr2picreg, symGOT_load)
(symGOTOFF2reg, block_move_real, block_lump_real)
(block_move_real_i4, block_lump_real_i4): Add support for FDPIC
calls.
(mulsi3, ic_invalidate_line, initialize_trampoline, call_pop,
call_value_pop): Adjust for new function_symbol signature.
* config/sh/sh.opt (-mfdpic): New option.
* doc/install.texi (Options specification): Document
--enable-fdpic.
* doc/invoke.texi (SH Options): Document -mfdpic.
include/ChangeLog:
* longlong.h (udiv_qrnnd): Add FDPIC compatible version for SH.
libitm/ChangeLog:
* config/sh/sjlj.S (_ITM_beginTransaction): Bypass PLT calling
GTM_begin_transaction for compatibility with FDPIC.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@229438
138bc75d-0d04-0410-961f-
82ee72b054a4
Pedro Alves [Sat, 28 Nov 2015 16:39:31 +0000 (16:39 +0000)]
PR other/61321 - demangler crash on casts in template parameters
The fix for bug 59195:
[C++ demangler handles conversion operator incorrectly]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59195
unfortunately makes the demangler crash due to infinite recursion, in
case of casts in template parameters.
For example, with:
template<int> struct A {};
template <typename Y> void function_temp(A<sizeof ((Y)(999))>) {}
template void function_temp<int>(A<sizeof (int)>);
The 'function_temp<int>' instantiation above mangles to:
_Z13function_tempIiEv1AIXszcvT_Li999EEE
The demangler parses this as:
typed name
template
name 'function_temp'
template argument list
builtin type int
function type
builtin type void
argument list
template (*)
name 'A'
template argument list
unary operator
operator sizeof
unary operator
cast
template parameter 0 (**)
literal
builtin type int
name '999'
And after the fix for 59195, due to:
static void
d_print_cast (struct d_print_info *dpi, int options,
const struct demangle_component *dc)
{
...
/* For a cast operator, we need the template parameters from
the enclosing template in scope for processing the type. */
if (dpi->current_template != NULL)
{
dpt.next = dpi->templates;
dpi->templates = &dpt;
dpt.template_decl = dpi->current_template;
}
when printing the template argument list of A (what should be "<sizeof
(int)>"), the template parameter 0 (that is, "T_", the '**' above) now
refers to the first parameter of the the template argument list of the
'A' template (the '*' above), exactly what we were already trying to
print. This leads to infinite recursion, and stack exaustion. The
template parameter 0 should actually refer to the first parameter of
the 'function_temp' template.
Where it reads "for the cast operator" in the comment in d_print_cast
(above), it's really talking about a conversion operator, like:
struct A { template <typename U> explicit operator U(); };
We don't want to inject the template parameters from the enclosing
template in scope when processing a cast _expression_, only when
handling a conversion operator.
The problem is that DEMANGLE_COMPONENT_CAST is currently ambiguous,
and means _both_ 'conversion operator' and 'cast expression'.
Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
which does what DEMANGLE_COMPONENT_CAST does today, and making
DEMANGLE_COMPONENT_CAST just simply print its component subtree.
I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
d_print_comp_inner still do:
@@ -5001,9 +5013,9 @@ d_print_comp_inner (struct d_print_info *dpi, int options,
d_print_comp (dpi, options, dc->u.s_extended_operator.name);
return;
case DEMANGLE_COMPONENT_CAST:
d_append_string (dpi, "operator ");
- d_print_cast (dpi, options, dc);
+ d_print_conversion (dpi, options, dc);
return;
leaving the unary cast case below calling d_print_cast, but seems to
me that spliting the component types makes it easier to reason about
the code.
g++'s testsuite actually generates three symbols that crash the
demangler in the same way. I've added those as tests in the demangler
testsuite as well.
And then this fixes PR other/61233 too, which happens to be a
demangler crash originally reported to GDB, at:
https://sourceware.org/bugzilla/show_bug.cgi?id=16957
Bootstrapped and regtested on x86_64 Fedora 20.
Also ran this through GDB's testsuite. GDB will require a small
update to use DEMANGLE_COMPONENT_CONVERSION in one place it's using
DEMANGLE_COMPONENT_CAST in its sources.
libiberty/
2015-11-27 Pedro Alves <palves@redhat.com>
PR other/61321
PR other/61233
* demangle.h (enum demangle_component_type)
<DEMANGLE_COMPONENT_CONVERSION>: New value.
* cp-demangle.c (d_demangle_callback, d_make_comp): Handle
DEMANGLE_COMPONENT_CONVERSION.
(is_ctor_dtor_or_conversion): Handle DEMANGLE_COMPONENT_CONVERSION
instead of DEMANGLE_COMPONENT_CAST.
(d_operator_name): Return a DEMANGLE_COMPONENT_CONVERSION
component if handling a conversion.
(d_count_templates_scopes, d_print_comp_inner): Handle
DEMANGLE_COMPONENT_CONVERSION.
(d_print_comp_inner): Handle DEMANGLE_COMPONENT_CONVERSION instead
of DEMANGLE_COMPONENT_CAST.
(d_print_cast): Rename as ...
(d_print_conversion): ... this. Adjust comments.
(d_print_cast): Rewrite - simply print the left subcomponent.
* cp-demint.c (cplus_demangle_fill_component): Handle
DEMANGLE_COMPONENT_CONVERSION.
* testsuite/demangle-expected: Add tests.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231020
138bc75d-0d04-0410-961f-
82ee72b054a4
Mike Stump [Sat, 28 Nov 2015 16:39:31 +0000 (16:39 +0000)]
libiberty TAGS
* Makefile.in (etags tags TAGS): Use && instead of ;.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@230270
138bc75d-0d04-0410-961f-
82ee72b054a4
Jason Merrill [Sat, 28 Nov 2015 16:39:30 +0000 (16:39 +0000)]
(Makefiles): PATCH to include libcpp and libiberty in GCC etags
gcc/c/
* Make-lang.in (c.tags): Also include libcpp TAGS.
gcc/cp/
* Make-lang.in (c++.tags): Also include libcpp TAGS.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@229504
138bc75d-0d04-0410-961f-
82ee72b054a4
Iain Sandoe [Sat, 28 Nov 2015 16:39:30 +0000 (16:39 +0000)]
Fix PR63758 by using the _NSGetEnviron() API on Darwin
include/
Roland McGrath <roland@gnu.org>
PR other/63758
* environ.h: New file.
libiberty/
Roland McGrath <roland@gnu.org>
Iain Sandoe <iain@codesourcery.com>
PR other/63758
* pex-unix.c: Obtain the environment interface from settings in environ.h
rather than in-line code. Update copyright date.
* setenv.c: Likewise.
* xmalloc.c: Likewise.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@228942
138bc75d-0d04-0410-961f-
82ee72b054a4
Jason Merrill [Sat, 28 Nov 2015 16:39:30 +0000 (16:39 +0000)]
Implement N4514, C++ Extensions for Transactional Memory.
gcc/
* builtins.def (BUILT_IN_ABORT): Add transaction_pure attribute.
gcc/c-family/
* c-common.c (c_common_reswords): Add C++ TM TS keywords.
(c_common_attribute_table): Add transaction_safe_dynamic.
transaction_safe now affects type identity.
(handle_tm_attribute): Handle transaction_safe_dynamic.
* c-common.h (enum rid): Add RID_ATOMIC_NOEXCEPT,
RID_ATOMIC_CANCEL, RID_SYNCHRONIZED.
(OBJC_IS_CXX_KEYWORD): Add RID_SYNCHRONIZED.
(D_TRANSMEM): New.
* c-cppbuiltin.c (c_cpp_builtins): Define __cpp_transactional_memory.
* c-pretty-print.c (pp_c_attributes_display): Don't print
transaction_safe in C++.
gcc/c/
* c-parser.c (c_lex_one_token): Handle @synchronized.
* c-decl.c (match_builtin_function_types): A declaration of a built-in
can change whether the function is transaction_safe.
gcc/cp/
* cp-tree.h (struct cp_declarator): Add tx_qualifier field.
(BCS_NORMAL, BCS_TRANSACTION): New enumerators.
* lex.c (init_reswords): Limit TM kewords to -fgnu-tm.
* parser.c (cp_lexer_get_preprocessor_token): Fix @synchronized.
(make_call_declarator): Take tx_qualifier.
(cp_parser_tx_qualifier_opt): New.
(cp_parser_lambda_declarator_opt): Use it.
(cp_parser_direct_declarator): Likewise.
(cp_parser_statement): Handle atomic_noexcept, atomic_cancel.
(cp_parser_compound_statement): Change in_try parameter to bcs_flags.
(cp_parser_std_attribute): Map optimize_for_synchronized to
transaction_callable.
(cp_parser_transaction): Take the token. Handle atomic_noexcept.
* lambda.c (maybe_add_lambda_conv_op): Handle transaction-safety.
* call.c (enum conversion_kind): Add ck_tsafe.
(standard_conversion): Handle transaction-safety conversion.
(convert_like_real, resolve_address_of_overloaded_function): Likewise.
(check_methods): Diagnose transaction_safe_dynamic on non-virtual
function.
(look_for_tm_attr_overrides): Don't inherit transaction_safe_dynamic.
* cvt.c (tx_safe_fn_type_p, tx_unsafe_fn_variant)
(can_convert_tx_safety): New.
* typeck.c (composite_pointer_type): Handle transaction-safety.
* name-lookup.h (enum scope_kind): Add sk_transaction.
* name-lookup.c (begin_scope): Handle it.
* semantics.c (begin_compound_stmt): Pass it.
* decl.c (check_previous_goto_1): Check it.
(struct named_label_entry): Add in_transaction_scope.
(poplevel_named_label_1): Set it.
(check_goto): Check it.
(duplicate_decls): A specialization can be transaction_safe
independently of its template.
(grokdeclarator): Handle tx-qualifier.
* rtti.c (ptr_initializer): Handle transaction-safe.
* search.c (check_final_overrider): Check transaction_safe_dynamic.
Don't check transaction_safe.
* mangle.c (write_function_type): Mangle transaction_safe here.
(write_CV_qualifiers_for_type): Not here.
(write_type): Preserve transaction_safe when stripping attributes.
* error.c (dump_type_suffix): Print transaction_safe.
libiberty/
* cp-demangle.c (d_cv_qualifiers): Dx means transaction_safe.
(cplus_demangle_type): Let d_cv_qualifiers handle it.
(d_dump, d_make_comp, has_return_type, d_encoding)
(d_count_templates_scopes, d_print_comp_inner)
(d_print_mod_list, d_print_mod, d_print_function_type)
(is_ctor_or_dtor): Handle DEMANGLE_COMPONENT_TRANSACTION_SAFE.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@228462
138bc75d-0d04-0410-961f-
82ee72b054a4
Mikhail Maltsev [Sat, 28 Nov 2015 16:39:29 +0000 (16:39 +0000)]
Fix several crashes of C++ demangler on fuzzed input.
libiberty/
* cp-demangle.c (d_dump): Fix syntax error.
(d_identifier): Adjust type of len to match d_source_name.
(d_expression_1): Fix out-of-bounds access. Check code variable for
NULL before dereferencing it.
(d_find_pack): Do not recurse for FIXED_TYPE, DEFAULT_ARG and NUMBER.
(d_print_comp_inner): Add NULL pointer check.
* cp-demangle.h (d_peek_next_char): Define as inline function when
CHECK_DEMANGLER is defined.
(d_advance): Likewise.
* testsuite/demangle-expected: Add new testcases.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@225727
138bc75d-0d04-0410-961f-
82ee72b054a4
Uros Bizjak [Sat, 28 Nov 2015 16:39:29 +0000 (16:39 +0000)]
Avoid "enum conversion when passing argument 1 of 'getrusage' is invalid in C++" warning
* getruntime.c (RUSAGE_SELF): Define if not already defined.
(get_runtime): Use RUSAGE_SELF as argument 1 of getrusage call.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@225614
138bc75d-0d04-0410-961f-
82ee72b054a4
Uros Bizjak [Sat, 28 Nov 2015 16:39:29 +0000 (16:39 +0000)]
Avoid "enum conversion when passing argument 1 of 'getrusage' is invalid in C++" warning
* getruntime.c (get_run_time) [__USE_GNU]: Use RUSAGE_SELF as
argument 1 of getrusage call.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@225534
138bc75d-0d04-0410-961f-
82ee72b054a4
GDB Administrator [Sat, 28 Nov 2015 00:00:08 +0000 (00:00 +0000)]
Automatic date update in version.in
Matthew Wahab [Fri, 27 Nov 2015 16:32:21 +0000 (16:32 +0000)]
[AArch64][PATCH 3/3] Add floating-point FP16 instructions
ARMv8.2 adds 16-bit floating point operations as an optional extension
to the ARMv8 FP support. This patch adds the new FP16 instructions,
making them available when the architecture extension +fp+fp16 is
specified.
The instructions added are:
- Comparisons and conditionals: FCMP, FCCMPE, FCMP, FCMPE and FCSEL.
- Arithmetic: FABS, FNEG, FSQRT, FMUL, FDIV, FADD, FSUB, FMADD, FMSUB,
FNMADD and FNMSUB.
- Rounding: FRINTN, FRINTP, FRINTM, FRINTZ, FRINTA, FRINTX and FRINTI.
- Conversions: SCVTF (fixed-point), SCVTF (integer), UCVTF (fixed-point)
UCVTF (integer), FCVTZS (fixed-point), FCVTZS (integer), FCVTZU
(fixed-point), FCVTZU (integer), FCVTNS, FCVTNU, FCVTAS, FCVTAU,
FCVTPS, FCVTPU, FCVTMS and FCVTMU.
- Scalar FMOV: immediate, general and register
gas/testsuite/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* gas/aarch64/float-fp16.d: New.
* gas/aarch64/float-fp16.s: New.
opcodes/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* aarch64-asm-2.c: Regenerate.
* aarch64-dis-2.c: Regenerate.
* aarch64-opc-2.c: Regenerate.
* aarch64-tbl.h (QL_FIX2FP_H, QL_FP2FIX_H): New.
(QL_INT2FP_H, QL_FP2INT_H): New.
(QL_FP2_H, QL_FP3_H, QL_FP4_H): New
(QL_DST_H): New.
(QL_FCCMP_H): New.
(aarch64_opcode_table): Add 16-bit variants of scvt, ucvtf,
fcvtzs, fcvtzu, fcvtns, fcvtnu, scvtf, ucvtf, fcvtas, fcvtau,
fmov, fcvtpos, fcvtpu, fcvtms, fcvtmu, fcvtzs, fcvtzu, fccmp,
fccmpe, fcmp, fcmpe, fabs, fneg, fsqrt, frintn, frintp, frintm,
frintz, frinta, frintx, frinti, fmul, fdiv, fadd, fsub, fmax,
fmin, fmaxnm, fminnm, fnmul, fmadd, fmsub, fnmadd, fnmsub and
fcsel.
Change-Id: Ie6d40bd1b215a9bc024e12ba75e52afbe1675eb7
Matthew Wahab [Fri, 27 Nov 2015 16:25:52 +0000 (16:25 +0000)]
[AArch64][PATCH 2/3] Adjust a utility function for floating point values.
ARMv8.2 adds 16-bit floating point operations as an optional
extension. This patch adjusts the utility function expand_fp_imm to
support 16-bit values.
The function is intended to convert an 8-bit immediate representing a
floating point value to a representation that can be passed to
fprintf. Because of the limited use of the results, the only change made
to the function is to treat a request for a 16-bit float as a request
for a 32-bit float.
opcodes/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* aarch64-opc.c (half_conv_t): New.
(expand_fp_imm): Replace is_dp flag with the parameter size to
specify the number of bytes for the required expansion. Treat
a 16-bit expansion like a 32-bit expansion. Add check for an
unsupported size request. Update comment.
(aarch64_print_operand): Update to support 16-bit floating point
values. Update for changes to expand_fp_imm.
Change-Id: I1ae3df3864be375d71925197ab03397ed1ad2d15
Matthew Wahab [Fri, 27 Nov 2015 15:47:53 +0000 (15:47 +0000)]
[AArch64][PATCH 1/3] Support ARMv8.2 FP16 floating point instructions.
ARMv8.2 adds 16-bit floating point operations as an optional extension
to the ARMv8 FP support. This patch set adds support for the 16-bit FP
instructions to binutils, enabling the instructions when both +fp and
+fp16 architecture extensions are enabled.
The patches in this series:
- Add a feature macro for use by the encoding/decoding mechanism.
- Adjust a utility function, used when disassembling, to support 16-bit
floating point values.
- Add the new scalar floating-point instructions.
This patch adds the feature macro FP_F16 to the AArch64 encoding/decoding
mechanism, enabling it when both +fp and +fp16 are selected.
opcodes/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* aarch64-tbl.h (aarch64_feature_fp_f16): New.
(FP_F16): New.
Change-Id: Ie370e43e3d77a7d54b4416b4be901b363a37f3d5
Matthew Wahab [Fri, 27 Nov 2015 15:39:12 +0000 (15:39 +0000)]
[AArch64] Add ARMv8.2 instruction alias REV64.
This patch adds the alias REV64 <Rd>, <Rs> as an alias for REV <Rd>,
<Rs>. However, REV is still the preferred form for the instruction.
gas/testsuite/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* gas/aarch64/alias-2.d: Add tests for REV.
* gas/aarch64/alias-2.s: Likewise.
opcodes/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* aarch64-asm-2.c: Regenerate.
* aarch64-dis-2.c: Regenerate.
* aarch64-opc-2.c: Regenerate.
* aarch64-tbl.h (aarchr64_opcode_table): Update "rev", add
"rev64".
Change-Id: I331567c8d3618ba9fec1673c6e0b5977222dde61
Matthew Wahab [Fri, 27 Nov 2015 15:25:08 +0000 (15:25 +0000)]
[AArch64] Add ARMv8.2 instructions BFC and REV64.
ARMv8.2 adds two new instructions: BFC as an alias for BFM and REV64 as
an alias for REV. This patch set adds support for these to binutils,
enabled when the -march=armv8.2-a is given. It depends on the support
for an instruction being its preferred form which was added in an
earlier patch.
This patch adds the alias BFC <Rd>, #<imm>, #<width> as the preferred
form for BFM when the source is a zero register and the conditions for
using the BFI form are met (in other words, BFC is the preferred form
for BFI <Rd>, <Rs>, #<imm>, #<width> when the <Rs> is a zero register).
gas/testsuite/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* gas/aarch64/alias-2.d: New.
* gas/aarch64/alias-2.s: New.
include/opcode/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* aarch64.h (aarch64_op): Add OP_BFC.
opcodes/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* aarch64-asm-2.c: Regenerate.
* aarch64-asm.c (convert_bfc_to_bfm): New.
(convert_to_real): Add case for OP_BFC.
* aarch64-dis-2.c: Regenerate.
* aarch64-dis.c: (convert_bfm_to_bfc): New.
(convert_to_alias): Add case for OP_BFC.
* aarch64-opc-2.c: Regenerate.
* aarch64-opc.c (operand_general_constraint_met_p): Weaken assert
to allow width operand in three-operand instructions.
* aarch64-tbl.h (QL_BF1): New.
(aarch64_feature_v8_2): New.
(ARMV8_2): New.
(aarch64_opcode_table): Add "bfc".
Change-Id: I6efe318b2538ba11f0caece7c6d70957441c872b
Simon Marchi [Fri, 27 Nov 2015 15:14:42 +0000 (10:14 -0500)]
remote.c: Add missing cast
Fixes in C++:
/home/emaisin/src/binutils-gdb/gdb/remote.c: In function ‘void start_thread(gdb_xml_parser*, const gdb_xml_element*, void*, VEC_gdb_xml_value_s*)’:
/home/emaisin/src/binutils-gdb/gdb/remote.c:2975:59: error: invalid conversion from ‘void*’ to ‘const char*’ [-fpermissive]
item.name = attr != NULL ? (char *) xstrdup (attr->value) : NULL;
^
In file included from /home/emaisin/src/binutils-gdb/gdb/common/common-defs.h:64:0,
from /home/emaisin/src/binutils-gdb/gdb/defs.h:28,
from /home/emaisin/src/binutils-gdb/gdb/remote.c:22:
/home/emaisin/src/binutils-gdb/gdb/../include/libiberty.h:323:14: error: initializing argument 1 of ‘char* xstrdup(const char*)’ [-fpermissive]
extern char *xstrdup (const char *) ATTRIBUTE_MALLOC ATTRIBUTE_RETURNS_NONNULL;
^
make[2]: *** [remote.o] Error 1
gdb/ChangeLog:
* remote.c (start_thread): Add cast.
Matthew Wahab [Fri, 27 Nov 2015 15:02:26 +0000 (15:02 +0000)]
[AArch64] Let aliased instructions be their preferred form.
Although the AArch64 backend supports aliased instructions, the aliasing
forms are always preferred over the real instruction. This makes it
awkward to handle instructions which have aliases but which are their
own preferred form.
This patch includes the instruction being aliased in the list of
alternatives which is searched when considering which form to use.
opcodes/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* aarch64-asm-2.c: Regenerate.
* aarch64-dis-2.c: Regenerate.
* aarch64-dis.c: Weaken assert.
* aarch64-gen.c: Include the instruction in the list of its
possible aliases.
Change-Id: I1f23eb25fccef76a64d3d732d58761bd25fad94e
Yao Qi [Fri, 27 Nov 2015 14:53:32 +0000 (14:53 +0000)]
[AArch64] Only check breakpoint alignment on inserting
This patch fixes the GDB internal error on AArch64 when running
watchpoint-fork.exp
top?bt 15
internal_error (file=file@entry=0x79d558 "../../binutils-gdb/gdb/linux-nat.c", line=line@entry=4866, fmt=0x793b20 "%s: Assertion `%s' failed.")
at ../../binutils-gdb/gdb/common/errors.c:51
#1 0x0000000000495bc4 in linux_nat_thread_address_space (t=<optimized out>, ptid=<error reading variable: Cannot access memory at address 0x1302>)
at ../../binutils-gdb/gdb/linux-nat.c:4866
#2 0x00000000005db2c8 in delegate_thread_address_space (self=<optimized out>, arg1=<error reading variable: Cannot access memory at address 0x1302>)
at ../../binutils-gdb/gdb/target-delegates.c:2447
#3 0x00000000005e8c7c in target_thread_address_space (ptid=<error reading variable: Cannot access memory at address 0x1302>)
at ../../binutils-gdb/gdb/target.c:2727
#4 0x000000000054eef8 in get_thread_arch_regcache (ptid=..., gdbarch=0xad51e0) at ../../binutils-gdb/gdb/regcache.c:529
#5 0x000000000054efcc in get_thread_regcache (ptid=...) at ../../binutils-gdb/gdb/regcache.c:546
#6 0x000000000054f120 in get_thread_regcache_for_ptid (ptid=...) at ../../binutils-gdb/gdb/regcache.c:560
#7 0x00000000004a2278 in aarch64_point_is_aligned (is_watchpoint=0, addr=34168, len=2) at ../../binutils-gdb/gdb/nat/aarch64-linux-hw-point.c:122
#8 0x00000000004a2e68 in aarch64_handle_breakpoint (type=hw_execute, addr=34168, len=2, is_insert=0, state=0xae8880)
at ../../binutils-gdb/gdb/nat/aarch64-linux-hw-point.c:465
#9 0x000000000048edf0 in aarch64_linux_remove_hw_breakpoint (self=<optimized out>, gdbarch=<optimized out>, bp_tgt=<optimized out>)
at ../../binutils-gdb/gdb/aarch64-linux-nat.c:657
#10 0x00000000005da8dc in delegate_remove_hw_breakpoint (self=<optimized out>, arg1=<optimized out>, arg2=<optimized out>)
at ../../binutils-gdb/gdb/target-delegates.c:492
#11 0x0000000000536a24 in bkpt_remove_location (bl=<optimized out>) at ../../binutils-gdb/gdb/breakpoint.c:13065
#12 0x000000000053351c in remove_breakpoint_1 (bl=0xb3fe70, is=is@entry=mark_inserted) at ../../binutils-gdb/gdb/breakpoint.c:4026
#13 0x000000000053ccc0 in detach_breakpoints (ptid=...) at ../../binutils-gdb/gdb/breakpoint.c:3930
#14 0x00000000005a3ac0 in handle_inferior_event_1 (ecs=0x7ffffff048) at ../../binutils-gdb/gdb/infrun.c:5042
After the fork, GDB will physically remove the breakpoints from the child
process (in frame #14), but at that time, GDB doesn't create an inferior
yet for child, but inferior_ptid is set to child's ptid (in frame #13).
In aarch64_point_is_aligned, we'll get the regcache of current_lwp_ptid
to determine if the current process is 32-bit or 64-bit, so the inferior
can't be found, and the internal error is caused.
I don't find a better fix other than not checking alignment on removing
breakpoint.
gdb:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* nat/aarch64-linux-hw-point.c (aarch64_dr_state_remove_one_point):
Don't assert on alignment.
(aarch64_handle_breakpoint): Only check alignment when IS_INSERT
is true.
Yao Qi [Fri, 27 Nov 2015 14:50:30 +0000 (14:50 +0000)]
New test gdb.arch/arm-neon.exp
Both ARM and AArch64 have defined some SIMD data types in arm_neon.h,
but we don't have a test case for passing them and returning them in
inferior call. This test also covers passing and returning
homogeneous short vector aggregate (defined by AArch64 ABI document)
in inferior call too.
gdb/testsuite:
* gdb.arch/arm-neon.exp: New.
* gdb.arch/arm-neon.c: New.
Yao Qi [Fri, 27 Nov 2015 14:50:30 +0000 (14:50 +0000)]
[AArch64] Handle HFA and HVA together
AArch64 AAPCS defined HFA (homogeneous floating-point aggregate)
and HVF (homogeneous short vector aggregate), bug GDB only handles the
former. In the AAPCS doc, both types are treated exactly the same
in terms of alignment and passing locations (on registers or stack).
This patch is to extend is_hfa to handle both HFA and HVA.
gdb:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (is_hfa): Rename to ...
(is_hfa_or_hva): ... this. Handle vector type. All callers
updated.
(aarch64_extract_return_value): Update debugging message.
(aarch64_store_return_value): Likewise.
(aarch64_return_in_memory): Update comments.
Yao Qi [Fri, 27 Nov 2015 14:50:30 +0000 (14:50 +0000)]
[AArch64] Support gnu vector in inferior call
As defined in AArch64 AAPCS, short vectors are passed through V
registers, and its maximum alignment is 16-byte. This patch is
to reflect these rules in GDB. This patch fixes some fails in
gdb.base/gnu_vector.exp.
gdb:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_type_align): For vector type, return
its length, but with the maximum of 16 bytes.
(is_hfa): Return zero for vector type.
(aarch64_push_dummy_call): Handle short vectors.
(aarch64_extract_return_value): Likewise.
(aarch64_store_return_value): Likewise.
Yao Qi [Fri, 27 Nov 2015 14:15:49 +0000 (14:15 +0000)]
Use multi_line to make pattern more human readable
gdb/testsuite:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* gdb.cp/annota2.exp: Rewrite the pattern using multi_line.
Yao Qi [Fri, 27 Nov 2015 14:21:47 +0000 (14:21 +0000)]
Allow multiple occurrences of the frames-invalid annotation in gdb.cp/annota2.exp
Hi,
I see one fail on aarch64-linux testing,
FAIL: gdb.cp/annota2.exp: watch triggered on a.x (timeout)
because GDB prints two frames-invalid annotation but the test expects
only one.
next^M
^M
^Z^Zpost-prompt^M
^M
^Z^Zstarting^M
^M
^Z^Zframes-invalid^M
^M
^Z^Zframes-invalid^M
^M
Note I also see the fail on Debian-s390x-m64 too.
https://sourceware.org/ml/gdb-testers/2015-q4/msg07291.html
The test shouldn't only expect one frames-invalid annotation, because
there can be multiple times of stop/resume before the user visible
stop. Ulrich did something similar before
https://www.sourceware.org/ml/gdb-patches/2009-06/msg00118.html
This patch only changes ${frames_invalid} to \(${frames_invalid}\)*
in the regexp pattern.
The patch below fixes the fail on aarch64-linux.
gdb/testsuite:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* gdb.cp/annota2.exp: Allow multiple occurrences of the
frames-invalid annotation.
Yao Qi [Fri, 27 Nov 2015 14:21:47 +0000 (14:21 +0000)]
Use ${frames_invalid} in gdb.cp/annota2.exp
Variable frames_invalid was defined, but wasn't used much. This patch
is to replace the literals in the regexp with ${frames_invalid}.
gdb/testsuite:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* gdb.cp/annota2.exp: Use ${frames_invalid}.
Matthew Wahab [Fri, 27 Nov 2015 13:44:10 +0000 (13:44 +0000)]
[Aarch64] Support an ARMv8.2 system register.
ARMv8.2 adds a new system register id_aa64mmfr2_el1. This patch adds
support for the register to binutils, making it available when
-march=armv8.2-a is selected.
opcodes/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* aarch64-opc.c (aarch64_sys_regs): Add "id_aa64mmfr2_el1".
(aarch64_sys_reg_supported_p): Add ARMv8.2 system register
feature test.
gas/testsuite/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* gas/aarch64/sysreg-2.d: New.
* gas/aarch64/sysreg-2.s: New.
Change-Id: I767f18a60e2bd70ce74c89f6abfe07afdc9e601f
Matthew Wahab [Fri, 27 Nov 2015 13:19:50 +0000 (13:19 +0000)]
[AArch64] Add feature flags and command line for ARMv8.2 FP16 support.
ARMv8.2 adds optional support for 16-bit operations to the FP and
Adv.SIMD instructions. This patch adds a feature macro for this support
with a new command line option "+fp16" to enable/disable it.
Although the command line option is added as an architecture extension,
it only affects instructions available with when +fp or +simd is
enabled. If +fp16 is specified then it will also enable +fp.
There are currently no FP16 instructions implemented in binutils, this
patch is to enable subsequent work on supporting the extension.
gas/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* config/tc-aarch64.c (aarch64_features): Add "fp16".
* doc/c-aarch64.texi (Architecture Extensions): Add "fp16".
include/opcode/
2015-11-27 Matthew Wahab <matthew.wahab@arm.com>
* aarch64.h (AARCH64_FEATURE_F16): New.
(AARCH64_ARCH_V8_2): Add AARCH64_FEATURE_F16 to ARMv8.2
features.
Change-Id: Id2021e0513946e16d0935c2a5b9605574cdff95a
GDB Administrator [Fri, 27 Nov 2015 00:00:08 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Thu, 26 Nov 2015 20:49:46 +0000 (15:49 -0500)]
Adjust ChangeLog entry
Par Olsson was the original author of the fix, so change the name in the
ChangeLog to give him the credit.
Simon Marchi [Thu, 26 Nov 2015 14:49:04 +0000 (09:49 -0500)]
Add test for thread names
I couldn't find a test that verified the thread name functionality, so I
created a new one.
A target board can define gdb,no_thread_names if it doesn't support thread
names and wants to skip the tests that uses them.
This test has been made with Linux in mind. Not all platforms use
pthread_setname_np to set the thread name, but some #ifdefs can be added
later in order to support other platforms.
Tested on x86-64 Ubuntu 14.04, native and remote.
gdb/testsuite/ChangeLog:
* gdb.threads/names.exp: New file.
* gdb.threads/names.c: New file.
* README: Mention gdb,no_thread_names.
Simon Marchi [Thu, 26 Nov 2015 14:49:04 +0000 (09:49 -0500)]
Display names of remote threads
This patch adds support for thread names in the remote protocol, and
updates gdb/gdbserver to use it. The information is added to the XML
description sent in response to the qXfer:threads:read packet.
gdb/ChangeLog:
* linux-nat.c (linux_nat_thread_name): Replace implementation by call
to linux_proc_tid_get_name.
* nat/linux-procfs.c (linux_proc_tid_get_name): New function,
implementation inspired by linux_nat_thread_name.
* nat/linux-procfs.h (linux_proc_tid_get_name): New declaration.
* remote.c (struct private_thread_info) <name>: New field.
(free_private_thread_info): Free name field.
(remote_thread_name): New function.
(thread_item_t) <name>: New field.
(clear_threads_listing_context): Free name field.
(start_thread): Get name xml attribute.
(thread_attributes): Add "name" attribute.
(remote_update_thread_list): Copy name field.
(init_remote_ops): Assign remote_thread_name callback.
* target.h (target_thread_name): Update comment.
* NEWS: Mention remote thread name support.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_target_ops): Use linux_proc_tid_get_name.
* server.c (handle_qxfer_threads_worker): Refactor to include thread
name in reply.
* target.h (struct target_ops) <thread_name>: New field.
(target_thread_name): New macro.
gdb/doc/ChangeLog:
* gdb.texinfo (Thread List Format): Mention thread names.
Simon Marchi [Thu, 26 Nov 2015 14:49:03 +0000 (09:49 -0500)]
Constify thread name return path
Since this code path returns a string owned by the target (we don't know how
it's allocated, could be a static read-only string), it's safer if we return
a constant string. If, for some reasons, the caller wishes to modify the
string, it should make itself a copy.
gdb/ChangeLog:
* linux-nat.c (linux_nat_thread_name): Constify return value.
* target.h (struct target_ops) <to_thread_name>: Likewise.
(target_thread_name): Likewise.
* target.c (target_thread_name): Likewise.
* target-delegates.c (debug_thread_name): Regenerate.
* python/py-infthread.c (thpy_get_name): Constify local variables.
* thread.c (print_thread_info): Likewise.
(thread_find_command): Likewise.
Markus Metzger [Thu, 19 Nov 2015 13:33:41 +0000 (14:33 +0100)]
btrace: diagnose "record btrace pt" without libipt
If GDB has been configured without libipt support, i.e. HAVE_LIBIPT is
undefined, and is running on a system that supports Intel(R) Processor Trace,
GDB will run into an internal error when trying to decode the trace.
(gdb) record btrace
(gdb) s
usage (name=0x7fffffffe954 "fib-64")
at src/fib.c:12
12 fprintf(stderr, "usage: %s <num>\n", name);
(gdb) info record
Active record target: record-btrace
Recording format: Intel(R) Processor Trace.
Buffer size: 16kB.
gdb/btrace.c:971: internal-error: Unexpected branch trace format.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This requires a system with Linux kernel 4.1 or later running on a 5th
Generation Intel Core processor or later.
The issue is documented as PR 19297.
When trying to enable branch tracing, in addition to checking the target
support for the requested branch tracing format, also check whether GDB
supports. it.
gdb/
* btrace.c (btrace_enable): Check whether HAVE_LIBIPT is defined.
testsuite/
* lib/gdb.exp (skip_btrace_pt_tests): Check for a "GDB does not
support" error.
GDB Administrator [Thu, 26 Nov 2015 00:00:08 +0000 (00:00 +0000)]
Automatic date update in version.in
Joel Brobecker [Wed, 25 Nov 2015 23:09:09 +0000 (15:09 -0800)]
Import zlib 1.2.8 with local change merged in.
ChangeLog:
* zlib: Update to zlib 1.2.8 with local changes merged in.
Cary Coutant [Wed, 25 Nov 2015 16:50:41 +0000 (08:50 -0800)]
Adjust local symbol value in relocatable link to be relative to section.
gold/
PR gold/19291
* object.cc (Sized_relobj_file::write_local_symbols): If relocatable,
subtract section address from symbol value.
Alan Modra [Wed, 25 Nov 2015 03:08:43 +0000 (13:38 +1030)]
[GOLD] Align PowerPC64 GOT
As done in
a27e685f for bfd ld.
* powerpc.cc (Output_data_got_powerpc::Output_data_got_powerpc): Align
to 256 byte boundary.
GDB Administrator [Wed, 25 Nov 2015 00:00:08 +0000 (00:00 +0000)]
Automatic date update in version.in
Christophe Monat [Tue, 24 Nov 2015 21:17:54 +0000 (22:17 +0100)]
[GAS, ARM] Invalid LDR immediate transformation
2015-11-24 Christophe Monat <christophe.monat@st.com>
* config/tc-arm.c (move_or_literal_pool): Do not transform ldr
ri,=imm into movs when ri is a high register in T1.
2015-11-24 Christophe Monat <christophe.monat@st.com>
* gas/arm/thumb2_ldr_immediate_armv6t2.s: Added high register
tests.
* gas/arm/thumb2_ldr_immediate_armv6t2.d: Accounted for new test
cases.
* gas/arm/thumb2_ldr_immediate_highregs_armv6t2.s: New.
* gas/arm/thumb2_ldr_immediate_highregs_armv6t2.d: New.
Pedro Alves [Tue, 24 Nov 2015 18:11:23 +0000 (18:11 +0000)]
NEWS: "info" commands now list in ascending order
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
* NEWS: Mention that a few "info" commands now list the
corresponding items in ascending ID order.
Pedro Alves [Tue, 24 Nov 2015 18:11:22 +0000 (18:11 +0000)]
List displays in ascending order
Before:
(gdb) info display
Auto-display expressions now in effect:
Num Enb Expression
3: y 1
2: y 1
1: y 1
After:
(gdb) info display
Auto-display expressions now in effect:
Num Enb Expression
1: y 1
2: y 1
3: y 1
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* printcmd.c (display_command): Append new display at the end of
the list.
gdb/testsuite/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.base/display.exp: Expect displays to be sorted in ascending
order. Use multi_line.
* gdb.base/solib-display.exp: Likewise.
Pedro Alves [Tue, 24 Nov 2015 18:11:22 +0000 (18:11 +0000)]
List checkpoints in ascending order
Before:
(gdb) info checkpoints
3 process 29132 at 0x4008ad, file foo.c, line 81
2 process 29131 at 0x4008ad, file foo.c, line 81
1 process 29130 at 0x4008ad, file foo.c, line 81
* 0 Thread 0x7ffff7fc5740 (LWP 29128) (main process) at 0x4008ad, file foo.c, line 81
After:
(gdb) info checkpoints
* 0 Thread 0x7ffff7fc5740 (LWP 29128) (main process) at 0x4008ad, file foo.c, line 81
1 process 29130 at 0x4008ad, file foo.c, line 81
2 process 29131 at 0x4008ad, file foo.c, line 81
3 process 29132 at 0x4008ad, file foo.c, line 81
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* printcmd.c (display_command): Append new display at the end of
the list.
gdb/testsuite/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.base/display.exp: Expect displays to be sorted in ascending
order. Use multi_line.
* gdb.base/solib-display.exp: Likewise.
Pedro Alves [Tue, 24 Nov 2015 18:11:21 +0000 (18:11 +0000)]
List inferiors/threads/pspaces in ascending order
Before:
(gdb) info threads
Id Target Id Frame
3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30
2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
* 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=
140737353893632, thread_return=0x0) at pthread_join.c:92
After:
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=
140737353893632, thread_return=0x0) at pthread_join.c:92
2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30
gdb/doc/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.texinfo (Inferiors and Programs): Adjust "maint info
program-spaces" example to ascending order listing.
(Threads): Adjust "info threads" example to ascending order
listing.
(Forks): Adjust "info inferiors" example to ascending order
listing.
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* inferior.c (add_inferior_silent): Append the new inferior to the
end of the list.
* progspace.c (add_program_space): Append the new pspace to the
end of the list.
* thread.c (new_thread): Append the new thread to the end of the
list.
gdb/testsuite/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.base/foll-exec-mode.exp: Adjust to GDB listing inferiors and
threads in ascending order.
* gdb.base/foll-fork.exp: Likewise.
* gdb.base/foll-vfork.exp: Likewise.
* gdb.base/multi-forks.exp: Likewise.
* gdb.mi/mi-nonstop.exp: Likewise.
* gdb.mi/mi-nsintrall.exp: Likewise.
* gdb.multi/base.exp: Likewise.
* gdb.multi/multi-arch.exp: Likewise.
* gdb.python/py-inferior.exp: Likewise.
* gdb.threads/break-while-running.exp: Likewise.
* gdb.threads/execl.exp: Likewise.
* gdb.threads/gcore-thread.exp: Likewise.
* gdb.threads/info-threads-cur-sal.exp: Likewise.
* gdb.threads/kill.exp: Likewise.
* gdb.threads/linux-dp.exp: Likewise.
* gdb.threads/multiple-step-overs.exp: Likewise.
* gdb.threads/next-bp-other-thread.exp: Likewise.
* gdb.threads/step-bg-decr-pc-switch-thread.exp: Likewise.
* gdb.threads/step-over-lands-on-breakpoint.exp: Likewise.
* gdb.threads/step-over-trips-on-watchpoint.exp: Likewise.
* gdb.threads/thread-find.exp: Likewise.
* gdb.threads/tls.exp: Likewise.
* lib/mi-support.exp (mi_reverse_list): Delete.
(mi_check_thread_states): No longer reverse list.
Pedro Alves [Tue, 24 Nov 2015 18:11:20 +0000 (18:11 +0000)]
Linux: dump the signalled thread first
... like the kernel does.
gcore-thread.exp has a check to make sure the signalled thread is the
current thread after loading the core back, but that just works by
accident, because the signalled thread happened to be the last thread
on the thread list, and gdb currently iterates over threads in reverse
order.
So this fixes gcore-thread.exp once we start walking threads in
ascending number.
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
* linux-tdep.c (find_stop_signal): Delete.
(struct linux_corefile_thread_data) <pid>: Remove field.
(linux_corefile_thread_callback): Rename to ...
(linux_corefile_thread): ... this. Now takes a struct
linux_corefile_thread_data pointer rather than a void pointer.
Remove thread state and thread pid checks.
(linux_make_corefile_notes): Prefer dumping the signalled thread
first. Use ALL_NON_EXITED_THREADS instead of
iterate_over_threads.
Pedro Alves [Tue, 24 Nov 2015 18:11:19 +0000 (18:11 +0000)]
Make gdb.python/py-inferior.exp test names unique
Before we had:
$ cat testsuite/gdb.sum | grep "PASS" | sort | uniq -c | sort -n
...
1 PASS: gdb.python/py-inferior.exp: write str
2 PASS: gdb.python/py-inferior.exp: Get inferior list length
2 PASS: gdb.python/py-inferior.exp: py start_addr = gdb.selected_frame ().read_var ('search_buf')
2 PASS: gdb.python/py-inferior.exp: Switch to first inferior
3 PASS: gdb.python/py-inferior.exp: find mixed-sized pattern
4 PASS: gdb.python/py-inferior.exp: py length = search_buf.type.sizeof
4 PASS: gdb.python/py-inferior.exp: py start_addr = search_buf.address
5 PASS: gdb.python/py-inferior.exp: Check inferior validity
$
gdb/testsuite/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
* gdb.python/py-inferior.exp: Use with_test_prefix. Consistently
use lowercase.
Matthew Wahab [Tue, 24 Nov 2015 10:21:52 +0000 (10:21 +0000)]
[ARM][GAS] Fix invalid arm-wince-pe tests.
There are a number of failures for the arm-wince-pe targets, most are due
to the test being invalid for the target.
This patch adjusts the invalid tests to either make them valid or to set
them as skipped for arm-wince-pe targets.
gas/testsuite
2015-11-24 Matthew Wahab <matthew.wahab@arm.com>
* gas/arm/armv7e-m+fpv5-d16.d: Skip test for *-*-pe, *-wince-* and
for *-*-coff targets.
* gas/arm/armv7e-m+fpv5-sp-d16.d: Likewise.
* gas/arm/blx-bl-convert.d: Likewise.
* gas/arm/ldst-offset0.d: Likewise.
* gas/arm/thumb2_ldr_immediate_armv6t2.d: Likewise.
* gas/arm/armv8-a+pan.s: Adjust test to make it
valid for non-ELF targets.
* gas/arm/wince.d: Add assembler option "-mccs".
* gas/arm/wince_inst.d: Update expected output.
Change-Id: I33a356e97eace3f8e1d581a46ec6413898105bef
Nick Clifton [Tue, 24 Nov 2015 08:47:59 +0000 (08:47 +0000)]
Add an AArch64 simulator to GDB.
sim * configure.tgt: Add aarch64 entry.
* configure: Regenerate.
* sim/aarch64/configure.ac: New configure template.
* sim/aarch64/aclocal.m4: Generate.
* sim/aarch64/config.in: Generate.
* sim/aarch64/configure: Generate.
* sim/aarch64/cpustate.c: New file - functions for accessing
AArch64 registers.
* sim/aarch64/cpustate.h: New header.
* sim/aarch64/decode.h: New header.
* sim/aarch64/interp.c: New file - interface between GDB and
simulator.
* sim/aarch64/Makefile.in: New makefile template.
* sim/aarch64/memory.c: New file - functions for simulating
aarch64 memory accesses.
* sim/aarch64/memory.h: New header.
* sim/aarch64/sim-main.h: New header.
* sim/aarch64/simulator.c: New file - aarch64 simulator
functions.
* sim/aarch64/simulator.h: New header.
include/gdb * sim-aarch64.h: New file.
sim/test * configure: Regenerate.
* sim/aarch64: New directory.
GDB Administrator [Tue, 24 Nov 2015 00:00:08 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Mon, 23 Nov 2015 23:47:09 +0000 (18:47 -0500)]
Fix internal error when saving fast tracepoint definitions
When trying to save fast tracepoints to file, gdb returns internal failure:
gdb/breakpoint.c:13446: internal-error: unhandled tracepoint type 27
A problem internal to GDB has been detected, further debugging may prove unreliable.
And no file including the fast tracepoints definition is created.
The patch also extends save-trace.exp to test saving tracepoint with a
fast tracepoint in there. Note that because this test doesn't actually
inserts the tracepoints in the program, we can run it with targets that
don't actually support fast tracepoints (or tracepoints at all).
gdb/ChangeLog:
* breakpoint.c (tracepoint_print_recreate): Fix logic error
if -> else if.
gdb/testsuite/ChangeLog:
* gdb.trace/actions.c: Include trace-common.h.
(main): Add a location for a fast tracepoint.
* gdb.trace/save-trace.exp: Set a fast tracepoint in addition to
the normal tracepoints.
(gdb_verify_tracepoints): Adjust number of expected tracepoints.
Simon Marchi [Mon, 23 Nov 2015 23:47:08 +0000 (18:47 -0500)]
Refactor gdb.trace/save-trace.exp
Some code is duplicated, to run the test twice with absolute and
relative paths, so I factored it out in a few procs. It uses
with_test_prefix to differentiate between test runs.
I replaced usages of "save-tracepoints" with "save tracepoint", since
the former is deprecated.
I also removed the "10.x", as it doesn't make much sense anymore. It
isn't used in general in the testsuite, and I don't think it's really
useful.
gdb/testsuite/ChangeLog:
* save-trace.exp: Factor out code to these...
(gdb_save_tracepoints): New.
(gdb_load_tracepoints): New.
(do_save_load_test): New.
Kevin Buettner [Sat, 14 Nov 2015 20:15:45 +0000 (13:15 -0700)]
minsyms.c: Scan backwards over all zero sized symbols.
The comment for the code in question says:
/* If the minimal symbol has a zero size, save it
but keep scanning backwards looking for one with
a non-zero size. A zero size may mean that the
symbol isn't an object or function (e.g. a
label), or it may just mean that the size was not
specified. */
As written, the code in question will only scan past the first symbol
of zero size. My change fixes the implementation to match the
comment.
Having this correct is important when the compiler generates several
local labels that are left in place by the linker. (I've been told
that the linker should eliminate these symbols, but I know of one
architecture for which this is not happening.)
I've created a test case called asmlabel.c. It's pretty simple:
main (int argc, char **argv)
{
asm ("L0:");
v = 0;
asm ("L1:");
v = 1; /* set L1 breakpoint here */
asm ("L2:");
v = 2; /* set L2 breakpoint here */
return 0;
}
If breakpoints are placed on the lines indicated by the comments,
this is the behavior of GDB built without my patch:
(gdb) continue
Continuing.
Breakpoint 2, L1 () at asmlabel.c:26
26 v = 1; /* set L1 breakpoint here */
Note that L1 appears as the function instead of main. This is not
what we want to happen. With my patch in place, we see the desired
behavior instead:
(gdb) continue
Continuing.
Breakpoint 2, main (argc=1, argv=0x7fffffffdb88) at asmlabel.c:26
26 v = 1; /* set L1 breakpoint here */
gdb/ChangeLog:
* minsyms.c (lookup_minimal_symbol_by_pc_section_1): Scan backwards
over all zero-sized symbols.
gdb/testsuite/ChangeLog:
* gdb.base/asmlabel.exp: New test.
* gdb.base/asmlabel.c: New test case.
Joel Brobecker [Mon, 23 Nov 2015 18:02:50 +0000 (10:02 -0800)]
error/internal-error printing local variable during "bt full".
One of our users reported an internal error using the "bt full"
command. In their situation, reproducing involved the following
scenario:
(gdb) frame 1
(gdb) bt full
#0 0xf7783430 in __kernel_vsyscall ()
No symbol table info available.
#1 0xf5550aeb in waitpid () at ../sysdeps/unix/syscall-template.S:81
No locals.
[...]
#6 0x0fe83139 in xxxx (arg=...)
[...some locals printed, and then...]
<S17b> =
[...]/dwarf2loc.c:364: internal-error: dwarf_expr_frame_base: Assertion
`framefunc != NULL' failed.
As shown above, the error happens while GDB is trying to print the value
of <S17b>, which is a local string internally generated by the compiler.
For that, it finds that the array lives in memory, and therefore tries
to create a struct value for it via:
case DWARF_VALUE_MEMORY:
{
CORE_ADDR address = dwarf_expr_fetch_address (ctx, 0);
[...]
retval = value_at_lazy (type, address + byte_offset);
Unfortunately for us, TYPE happens to be an array whose bounds
are dynamic. More precisely, the bounds of our arrays are described
in the debugging info as being...
<4><2c1985e>: Abbrev Number: 33 (DW_TAG_subrange_type)
<2c1985f> DW_AT_type : <0x2c1989c>
<2c19863> DW_AT_lower_bound : <0x2c19835>
<2c19867> DW_AT_upper_bound : <0x2c19841>
... which are references to a pair of local variables. For instance,
the lower bound is a reference to the following DIE
<3><2c19835>: Abbrev Number: 32 (DW_TAG_variable)
<2c19836> DW_AT_name : [...]
<2c1983a> DW_AT_type : <0x2c198b4>
<2c1983e> DW_AT_artificial : 1
<2c1983e> DW_AT_location : 2 byte block: 91 58 (DW_OP_fbreg: -40)
As a result of the above, value_at_lazy indirectly triggers
a resolution of TYPE (via value_from_contents_and_address),
which means a resolution of TYPE's bounds, and as seen in
the DW_AT_location attribute above for our bounds, computing
the bound's location requires the frame (its location expression
uses DW_OP_fbreg).
Unfortunately for us, value_at_lazy does not get passed a frame,
we've lost the relevant frame when we try to resolve the array's
bounds. Instead, resolve_dynamic_range gets calls dwarf2_evaluate_property
with NULL as the frame:
static struct type *
resolve_dynamic_range (struct type *dyn_range_type,
struct property_addr_info *addr_stack)
{
[...]
if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value))
^^^^
... which then handles this by using the selected frame instead:
if (frame == NULL && has_stack_frames ())
frame = get_selected_frame (NULL);
In our case, the selected frame happens to be frame #1, which is
a frame where we have a minimal amount of debugging info, and in
particular, no debug info for the function itself. And because of that,
when we try to determine the frame's base...
static void
dwarf_expr_frame_base (void *baton, const gdb_byte **start,
size_t * length)
{
struct dwarf_expr_baton *debaton = (struct dwarf_expr_baton *) baton;
const struct block *bl = get_frame_block (debaton->frame, NULL);
[...]
framefunc = block_linkage_function (bl);
... framefunc ends up being NULL, which triggers the assert
in that same function:
gdb_assert (framefunc != NULL);
This patches avoids the issue by temporarily setting the selected_frame
before printing the locals of each frames.
This patch also adds a small testcase, which reproduces the same
issue, but with a slightly different outcome:
(gdb) bt full
#0 0x000000000040049a in opaque_routine ()
No symbol table info available.
#1 0x0000000000400532 in main () at wrong_frame_bt_full-main.c:20
my_table_size = 3
my_table = <error reading variable my_table (frame address is not available.)>
With this patch, the output becomes:
(gdb) bt full
[...]
my_table = {0, 1, 2}
gdb/ChangeLog:
* stack.c (print_frame_local_vars): Temporarily set the selected
frame to FRAME while printing the frame's local variables.
gdb/testsuite/ChangeLog:
* gdb.base/wrong_frame_bt_full-main.c: New file.
* gdb.base/wrong_frame_bt_full-opaque.c: New file.
* gdb.base/wrong_frame_bt_full.exp: New file.
Joel Brobecker [Mon, 23 Nov 2015 17:56:23 +0000 (09:56 -0800)]
[LynxOS] GDBserver crash debugging threaded program
This crash is observable by debugging a threaded program on LynxOS.
On the GDB side, this is what we would see:
% gdb q
(gdb) target remote machine:4444
(gdb) break q.adb:6
(gdb) cont
[gdb hits breakpoint]
(gdb) cont
Remote connection closed <<<--- expected: [Inferior 1 (Remote target) exited normally]
On the gdbserver side, which was launched as usual:
% gdbserver --once :4444 q
Segmentation fault (core dumped)
Ooops!
The problem happens while GDB is trying to handle the thread termination
event of the thread that hit the breakpoint. It started happening after
the following change was made:
commit
96e7a1eb6d09fda9e22e112e35e7d0085a8f4fd0
Date: Fri Oct 16 11:08:38 2015 -0400
Subject: gdbserver: Reset current_thread when the thread is removed.
Reset current_thread and make sure 'remove_process' is used
after all associated threads have been removed first.
More precisely:
. GDBserver receives the execution-resume order;
. lynx-low resumes it succesfully, and then relies on lynx_wait_1
to wait for the next event;
. We quickly receive one, which lynx_wait_1 analyzes to be
a "thread exit" event, and therefore does...
case SIGTHREADEXIT:
remove_thread (find_thread_ptid (new_ptid));
lynx_continue (new_ptid);
goto retry;
=> remove_thread causes current_thread to be set to NULL...
(that's the recent change mentioned above)
=> ... which causes problems during lynx_continue, because
it calls lynx_resume, which calls regcache_invalidate,
which unfortunately assumes that CURRENT_THREAD is not NULL:
void
regcache_invalidate (void)
{
/* Only update the threads of the current process. */
SEGV!--> int pid = ptid_get_pid (current_thread->entry.id);
find_inferior (&all_threads, regcache_invalidate_one, &pid);
}
Since the problem at hand is caused by trying to figure out which
inferior to reset the regcache for, and since lynx_resume actually
had that info, this patch fixes the problem by introducing a new
routine called regcache_invalidate_pid, which invalidates the cache
of the given pid; and then modifies lynx_resume use that new routine
rather than relying on regcache_invalidate to invalidate the regcache
of the expected inferior.
gdb/gdbserver/ChangeLog:
* regcache.h (regcache_invalidate_pid): Add declaration.
* regcache.c (regcache_invalidate_pid): New function, extracted
from regcache_invalidate.
(regcache_invalidate): Reimplement using regcache_invalidate_pid.
Add trivial documentation comment.
* lynx-low.c: Use regcache_invalidate_pid instead of
regcache_invalidate.
Joel Brobecker [Mon, 23 Nov 2015 17:53:31 +0000 (09:53 -0800)]
infinite loop stopping at "pop" insn on x64-windows
We noticed the following hang trying to run a program where one
of the subroutines we built without debugging info (opaque_routine):
$ gdb my_program
(gdb) break opaque_routine
(gdb) run
[...hangs...]
The problem comes from the fact that, at the breakpoint's address,
we have the following code:
=> 0x0000000000401994 <+4>: pop %rbp
At some point after hitting the breakpoint and stopping, GDB calls
amd64_windows_frame_decode_epilogue, which then gets stuck in the
following infinite loop:
| /* We don't care about the instruction deallocating the frame:
| if it hasn't been executed, the pc is still in the body,
| if it has been executed, the following epilog decoding will work. */
|
| /* First decode:
| - pop reg [41 58-5f] or [58-5f]. */
|
| while (1)
| {
| /* Read opcode. */
| if (target_read_memory (pc, &op, 1) != 0)
| return -1;
|
| if (op >= 0x40 && op <= 0x4f)
| {
| /* REX prefix. */
| rex = op;
|
| /* Read opcode. */
| if (target_read_memory (pc + 1, &op, 1) != 0)
| return -1;
| }
| else
| rex = 0;
|
| if (op >= 0x58 && op <= 0x5f)
| {
| /* pop reg */
| gdb_byte reg = (op & 0x0f) | ((rex & 1) << 3);
|
| cache->prev_reg_addr[amd64_windows_w2gdb_regnum[reg]] = cur_sp;
| cur_sp += 8;
| }
| else
| break;
|
| /* Allow the user to break this loop. This shouldn't happen as the
| number of consecutive pop should be small. */
| QUIT;
| }
Nothing in that loop updates PC, and therefore, because the instruction
we stopped at is a "pop", we keep looping forever doing the same thing
over and over!
This patch fixes the issue by advancing PC to the beginning of
the next instruction if the current one is a "pop reg" instruction.
gdb/ChangeLog:
* amd64-windows-tdep.c (amd64_windows_frame_decode_epilogue):
Increment PC in while loop skipping "pop reg" instructions.
Joel Brobecker [Mon, 23 Nov 2015 17:50:55 +0000 (09:50 -0800)]
[ARM] "svc" insn check at irrelevant address in ARM unwind info sniffer
The following issue has been observed on arm-android, trying to step
over the following line of code:
Put_Line (">>> " & Integer'Image (Message (I)));
Below is a copy of the GDB transcript:
(gdb) cont
Breakpoint 1, q.dump (message=...) at q.adb:11
11 Put_Line (">>> " & Integer'Image (Message (I)));
(gdb) next
0x00016000 in system.concat_2.str_concat_2 ()
The expected behavior for the "next" command is to step over
the call to Put_Line and stop at line 12:
(gdb) next
12 I := I + 1;
What happens during the next step is that the code for line 11
above make a call to system.concat_2.str_concat_2 (to implement
the '&' string concatenation operator) before making the call
to Put_Line. While stepping, GDB stops eventually stops at the
first instruction of that function, and fails to detect that
it's a function call from where we were before, and so decides
to stop stepping.
And the reason why it fails to detect that we landed inside a function
call is because it fails to unwind from that function:
(gdb) bt
#0 0x00016000 in system.concat_2.str_concat_2 ()
#1 0x0001bc74 in ?? ()
Debugging GDB, I found that GDB decides to use the ARM unwind info
for that function, which contains the following data:
0x16000 <system__concat_2__str_concat_2>: 0x80acb0b0
Compact model index: 0
0xac pop {r4, r5, r6, r7, r8, r14}
0xb0 finish
0xb0 finish
But, in fact, using that data is wrong, in this case, because
it mentions a pop of 6 registers, and therefore hints at a frame
size of 24 bytes. The problem is that, because we're at the first
instruction of the function, the 6 registers haven't been pushed
to the stack yet. In other words, using the ARM unwind entry above,
GDB is tricked into thinking that the frame size is 24 bytes, and
that the return address (r14) is available on the stack.
One visible manifestation of this issue can been seen by looking
at the value of the stack pointer, and the frame's base address:
(gdb) p /x $sp
$2 = 0xbee427b0
(gdb) info frame
Stack level 0, frame at 0xbee427c8:
^^^^^^^^^^
||||||||||
The frame's base address should be equal to the value of the stack
pointer at entry. And you eventually get the correct frame address,
as well as the correct backtrace if you just single-step one additional
instruction, past the push:
(gdb) x /i $pc
=> 0x16000 <system__concat_2__str_concat_2>:
push {r4, r5, r6, r7, r8, lr}
(gdb) stepi
(gdb) bt
#0 0x00016004 in system.concat_2.str_concat_2 ()
#1 0x00012b6c in q.dump (message=...) at q.adb:11
#2 0x00012c3c in q () at q.adb:19
Digging further, I found that GDB tries to use the ARM unwind info
only when sure that it is relevant, as explained in the following
comment:
/* The ARM exception table does not describe unwind information
for arbitrary PC values, but is guaranteed to be correct only
at call sites. We have to decide here whether we want to use
ARM exception table information for this frame, or fall back [...]
There is one case where it decides that the info is relevant,
described in the following comment:
/* We also assume exception information is valid if we're currently
blocked in a system call. The system library is supposed to
ensure this, so that e.g. pthread cancellation works.
For that, it just parses the instruction at the address it believes
to be the point of call, and matches it against an "svc" instruction.
For instance, for a non-thumb instruction, it is at...
get_frame_pc (this_frame) - 4
... and the code checking looks like the following.
if (safe_read_memory_integer (get_frame_pc (this_frame) - 4, 4,
byte_order_for_code, &insn)
&& (insn & 0x0f000000) == 0x0f000000 /* svc */)
exc_valid = 1;
However, the reason why this doesn't work in our case is that
because we are at the first instruction of a function in the innermost
frame. That frame can't possibly be making a call, and therefore
be stuck on a system call.
What the code above ends up doing is checking the instruction
just before the start of our function, which in our case is not
even an actual instruction, but unlucky for us, happens to match
the pattern it is looking for, thus leading GDB to improperly
trust the ARM unwinding data.
gdb/ChangeLog:
* arm-tdep.c (arm_exidx_unwind_sniffer): Do not check for a frame
stuck on a system call if the given frame is the innermost frame.
Joel Brobecker [Mon, 23 Nov 2015 17:48:16 +0000 (09:48 -0800)]
[gdbserver] disable Elf32_auxv_t/Elf64_auxv_t AC_CHECK_TYPES check on Android
See the comment added in configure.ac for more details behind
this change.
gdb/gdbserver/ChangeLog:
* configure.ac: Do not call AC_CHECK_TYPES for Elf32_auxv_t
and Elf64_auxv_t if the target is Android.
Joel Brobecker [Mon, 23 Nov 2015 17:45:52 +0000 (09:45 -0800)]
Fix space-vs-tab issues in gdb/testsuite/ChangeLog.
Joel Brobecker [Mon, 23 Nov 2015 17:44:16 +0000 (09:44 -0800)]
gdb/dwarf2read: Minimal handling of non-constant struct sizes.
Using the gdb.ada/var_rec_arr.exp test, where the program declares
an array of variant records...
type Record_Type (I : Small_Type := 0) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
... and then a variable A1 of type Array_Type, the following command
ocassionally trigger an internal error trying to allocate more memory
than we have left:
(gdb) ptype a1(1)
[...]/utils.c:1089: internal-error: virtual memory exhausted.
A problem internal to GDB has been detected,
[...]
What happens is that recent versions of GNAT are able to generate
DWARF expressions for type Record_Type, and therefore the record's
DW_AT_byte_size is not a constant, which unfortunately breaks
an assumption made by dwarf2read.c:read_structure_type when it does:
attr = dwarf2_attr (die, DW_AT_byte_size, cu);
if (attr)
{
TYPE_LENGTH (type) = DW_UNSND (attr);
}
As a result of this, when ada_evaluate_subexp tries to create
a value_zero for a1(1) while processing the OP_FUNCALL operator
as part of evaluating the subscripting operation in no-side-effect
mode, we try to allocate a value with a bogus size, potentially
triggering the out-of-memory internal error.
This patch avoids this issue by setting the length to zero in
this case. Until we decide to start supporting dynamic type
lengths in GDB's type struct, and it's not clear yet that
this is worth the effort (see added comment), that's probably
the best we can do.
gdb/ChangeLog:
* dwarf2read.c (read_structure_type): Set the type's length
to zero if it has a DW_AT_byte_size attribute which is not
a constant.
gdb/testsuite/ChangeLog:
* testsuite/gdb.ada/var_rec_arr.exp: Add "ptype a1(1)" test.
Tristan Gingold [Fri, 20 Nov 2015 16:24:52 +0000 (17:24 +0100)]
opcodes: handle mach-o for thumb/arm disambiguation.
opcodes/
* arm-dis.c (print_insn): Also set is_thumb for Mach-O.
Tristan Gingold [Wed, 8 Jul 2015 10:18:32 +0000 (12:18 +0200)]
darwin-nat: disable sstep cache.
Was not reliable after inferior call.
Tristan Gingold [Mon, 23 Nov 2015 10:45:05 +0000 (11:45 +0100)]
solib-darwin: support PIE for spawned processes.
solib-darwin is now able to read the load address of the executable
before any inferior execution.
Tristan Gingold [Thu, 9 Oct 2014 12:08:07 +0000 (14:08 +0200)]
darwin-nat: rewrite darwin_read_write_inferior
This is a little bit more efficient.
Doug Evans [Mon, 23 Nov 2015 01:24:03 +0000 (17:24 -0800)]
target.h: #include <sys/types.h>.
For musl.
GDB Administrator [Mon, 23 Nov 2015 00:00:08 +0000 (00:00 +0000)]
Automatic date update in version.in
Mike Frysinger [Sun, 22 Nov 2015 07:22:39 +0000 (23:22 -0800)]
sim: common: set up CPPFLAGS/CXXFLAGS/LDFLAGS from configure [PR sim/18762]
Make sure we pass down the CPP/CXX/LD flags that configure set up for us
like we already do for C flags.
Mike Frysinger [Sun, 22 Nov 2015 07:10:04 +0000 (23:10 -0800)]
sim: sim_do_commandf: fix call to va_end [PR sim/19273]
Make sure we call va_end even in the error case.
Mike Frysinger [Sun, 22 Nov 2015 06:56:04 +0000 (22:56 -0800)]
sim: ppc: avoid use of $< in ordinary rules [PR sim/13834]
POSIX does not define $< behavior in ordinary rules, so avoid its use
to fix building on non-GNU make setups.
Reported-by: Christopher January <chris.january@allinea.com>
Mike Frysinger [Sat, 20 Jun 2015 09:36:26 +0000 (15:21 +0545)]
sim: common: add PRI printf defines
Keeping track of the right printf formats for the various types can be
a pretty big hassle, especially in common code which has to support a
variety of bitsizes. Take a page from the existing standards and add
a set of PRI macros which hide the details in a common header.
Mike Frysinger [Sun, 22 Nov 2015 06:00:57 +0000 (22:00 -0800)]
sim: avr: move global state to sim/cpu state
We don't want global variables in the sim as all state should be in the
sim state or in the cpu state. This pushes down all that logic for avr.
Mike Frysinger [Sun, 22 Nov 2015 05:12:59 +0000 (21:12 -0800)]
sim: avr: switch to common sim-reg
This is not entirely useful as avr doesn't (yet) store its register
state in the cpu state, but it does allow for switching to the common
code for these functions.