binutils_os216

Fork

Bump date

Bump version to match embedded-binutils-2_26-branch

2016-06-22 Thomas Preud'homme <thomas.preudhomme@arm.com>

bfd/
* version.h (BFD_VERSION_DATE): Bump date to 20160616.

Add missing ChangeLog.arm entry for previous commit

2016-06-20 Thomas Preud'homme <thomas.preudhomme@arm.com>

Backport from mainline
Skip unwritable frames in command "finish"

Nowadays, GDB can't insert breakpoint on the return address of the
exception handler on ARM M-profile, because the address is a magic
one 0xfffffff9,

(gdb) bt
#0 CT32B1_IRQHandler () at ../src/timer.c:67
#1 <signal handler called>
#2 main () at ../src/timer.c:127

(gdb) info frame
Stack level 0, frame at 0x200ffa8:
pc = 0x4ec in CT32B1_IRQHandler (../src/timer.c:67); saved pc = 0xfffffff9
called by frame at 0x200ffc8
source language c.
Arglist at 0x200ffa0, args:
Locals at 0x200ffa0, Previous frame's sp is 0x200ffa8
Saved registers:
r7 at 0x200ffa0, lr at 0x200ffa4

(gdb) x/x 0xfffffff9
0xfffffff9: Cannot access memory at address 0xfffffff9

(gdb) finish
Run till exit from #0 CT32B1_IRQHandler () at ../src/timer.c:67
Ed:15: Target error from Set break/watch: Et:96: Pseudo-address (0xFFFFFFxx) for EXC_RETURN is invalid (GDB error?)

Warning:
Cannot insert hardware breakpoint 0.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

Command aborted.

even some debug probe can't set hardware breakpoint on the magic
address too,

(gdb) hbreak *0xfffffff9
Hardware assisted breakpoint 2 at 0xfffffff9
(gdb) c
Continuing.
Ed:15: Target error from Set break/watch: Et:96: Pseudo-address (0xFFFFFFxx) for EXC_RETURN is invalid (GDB error?)

Warning:
Cannot insert hardware breakpoint 2.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

Command aborted.

The problem described above is quite similar to PR 8841, in which GDB
can't set breakpoint on signal trampoline, which is mapped to a read-only
page by kernel. The rationale of this patch is to skip "unwritable"
frames when looking for caller frames in command "finish", and a new
gdbarch method code_of_frame_writable is added. This patch fixes
the problem on ARM cortex-m target, but it can be used to fix
PR 8841 too.

gdb:

2016-05-10 Yao Qi <yao.qi@arm.com>

* arch-utils.c (default_code_of_frame_writable): New function.
* arch-utils.h (default_code_of_frame_writable): Declare.
* arm-tdep.c (arm_code_of_frame_writable): New function.
(arm_gdbarch_init): Install gdbarch method
code_of_frame_writable if the target is M-profile.
* frame.c (skip_unwritable_frames): New function.
* frame.h (skip_unwritable_frames): Declare.
* gdbarch.sh (code_of_frame_writable): New.
* gdbarch.c, gdbarch.h: Re-generated.
* infcmd.c (finish_command): Call skip_unwritable_frames.

Add an expect for running commands with CLI jump

2016-04-05 Thomas Preud'homme <thomas.preudhomme@arm.com>

Backport from master
2015-12-22 Thomas Preud'homme <thomas.preudhomme@arm.com>

gdb/testsuite/
* lib/mi-support.exp (mi_run_cmd_full): Add an expect for the CLI jump
case.

Fix using uninitialised values

We did a code refacotr here
https://sourceware.org/ml/gdb-patches/2013-11/msg00063.html

> (get_current_thread): New function, factored out from ...
> (add_current_inferior_and_thread): ... this. Adjust.
>
>@@ -3332,18 +3371,8 @@ add_current_inferior_and_thread (char *wait_status)
>
> inferior_ptid = null_ptid;
>
>- /* Now, if we have thread information, update inferior_ptid. First
>- if we have a stop reply handy, maybe it's a T stop reply with a
>- "thread" register we can extract the current thread from. If
>- not, ask the remote which is the current thread, with qC. The
>- former method avoids a roundtrip. Note we don't use
>- remote_parse_stop_reply as that makes use of the target
>- architecture, which we haven't yet fully determined at this
>- point. */
>- if (wait_status != NULL)
>- ptid = stop_reply_extract_thread (wait_status);
>- if (ptid_equal (ptid, null_ptid))
>- ptid = remote_current_thread (inferior_ptid);
>+ /* Now, if we have thread information, update inferior_ptid. */
>+ ptid = get_current_thread (wait_status);

but after the refactor, local variable ptid is used without
initialisation. However, before this change, ptid is initialised to
null_ptid. This error can be found by valgrind too...

==3298== at 0x6B99BA: ptid_equal (ptid.c:80)
==3298== by 0x4C67FF: get_current_thread (remote.c:3484)
==3298== by 0x4C6951: add_current_inferior_and_thread (remote.c:3511)
==3298== by 0x4C762C: extended_remote_create_inferior (remote.c:8506)
==3298== by 0x5A5312: run_command_1 (infcmd.c:606)
==3298== by 0x68B4FB: execute_command (top.c:463)
==3298== by 0x5C7214: command_handler (event-top.c:494)
==3298== by 0x5C78A3: command_line_handler (event-top.c:692)
==3298== by 0x6DEB57: rl_callback_read_char (callback.c:220)
==3298== by 0x5C7278: rl_callback_read_char_wrapper (event-top.c:171)
==3298== by 0x5C72C2: stdin_event_handler (event-top.c:432)
==3298== by 0x5C6194: gdb_wait_for_event (event-loop.c:834)

This patch initialises local variable ptid to null in get_current_thread.
We don't need to initialise ptid in add_current_inferior_and_thread,
so this patch also removes the ptid initialisation.

gdb/ChangeLog.arm:
2016-03-29 Andre Vieira <andre.simoesdiasvieira@arm.com>
Backport from mainline
2015-07-17 Yao Qi <yao.qi@linaro.org>

* remote.c (get_current_thread): Initialise ptid to null_ptid.
(add_current_inferior_and_thread): Don't initialise ptid.

Fix for GDB crashing with printf on ARM targets.

gdb/ChangeLog.arm:
2016-02-16 Andre Vieira <andre.simoesdiasvieira@arm.com>
Backport from mainline
2016-02-04 Yao Qi <yao.qi@linaro.org>

* remote.c (remote_wait_as): Set rs->waiting_for_stop_reply to
0 before handling 'F' and set it back afterwards.

Fix '-data-read-memory-bytes' typo/assertion

Backported to the 7.10 branch per this thread:
https://www.sourceware.org/ml/gdb-patches/2016-02/msg00134.html

This patch fixes a typo in target.c:read_memory_robust, where
it calls read_whatever_is_readable with the function arguments
in the wrong order. Depending on the address being read, it
can cause an xmalloc with a huge size, resulting in an assertion
failure, or just read something other than what was requested.

The problem only arises when GDB is handling an MI
"-data-read-memory-bytes" request and the initial target_read returns
an error status. Note that read_memory_robust is only called from
the MI code.

gdb/ChangeLog:

* gdb/target.c (read_memory_robust): Call
read_whatever_is_readable with arguments in the correct order.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in