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.
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.
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.
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.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
