espressif/binutils-gdb
1
0
Fork 0
mirror of https://github.com/espressif/binutils-gdb.git synced 2025-06-25 21:41:47 +08:00
Code Issues Packages Projects Releases Wiki Activity

Re-indent the code

Browse Source 
gdb/gdbserver:

2015-08-25  Yao Qi  <yao.qi@linaro.org>

	* linux-aarch64-low.c (debug_reg_change_callback): Re-indent
	the code.
This commit is contained in:
Yao Qi
2015-08-25 11:38:28 +01:00
parent ff3f0f45c5
commit 8ee525679d
2 changed files with 35 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
gdb/gdbserver/ChangeLog
View File

@ -1,3 +1,8 @@
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (debug_reg_change_callback): Re-indent
the code.
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_dr_update_callback_param) <pid>:

60
gdb/gdbserver/linux-aarch64-low.c
View File

@ -272,39 +272,39 @@ debug_reg_change_callback (struct lwp_info *lwp, void *ptr)
: &info->dr_changed_bp;
dr_changed = *dr_changed_ptr;
gdb_assert (idx >= 0
&& (idx <= (is_watchpoint ? aarch64_num_wp_regs
: aarch64_num_bp_regs)));
gdb_assert (idx >= 0
&& (idx <= (is_watchpoint ? aarch64_num_wp_regs
: aarch64_num_bp_regs)));
/* The following assertion is not right, as there can be changes
that have not been made to the hardware debug registers
before new changes overwrite the old ones. This can happen,
for instance, when the breakpoint/watchpoint hit one of the
threads and the user enters continue; then what happens is:
1) all breakpoints/watchpoints are removed for all threads;
2) a single step is carried out for the thread that was hit;
3) all of the points are inserted again for all threads;
4) all threads are resumed.
The 2nd step will only affect the one thread in which the
bp/wp was hit, which means only that one thread is resumed;
remember that the actual updating only happen in
aarch64_linux_prepare_to_resume, so other threads remain
stopped during the removal and insertion of bp/wp. Therefore
for those threads, the change of insertion of the bp/wp
overwrites that of the earlier removals. (The situation may
be different when bp/wp is steppable, or in the non-stop
mode.) */
/* gdb_assert (DR_N_HAS_CHANGED (dr_changed, idx) == 0); */
/* The following assertion is not right, as there can be changes
that have not been made to the hardware debug registers
before new changes overwrite the old ones. This can happen,
for instance, when the breakpoint/watchpoint hit one of the
threads and the user enters continue; then what happens is:
1) all breakpoints/watchpoints are removed for all threads;
2) a single step is carried out for the thread that was hit;
3) all of the points are inserted again for all threads;
4) all threads are resumed.
The 2nd step will only affect the one thread in which the
bp/wp was hit, which means only that one thread is resumed;
remember that the actual updating only happen in
aarch64_linux_prepare_to_resume, so other threads remain
stopped during the removal and insertion of bp/wp. Therefore
for those threads, the change of insertion of the bp/wp
overwrites that of the earlier removals. (The situation may
be different when bp/wp is steppable, or in the non-stop
mode.) */
/* gdb_assert (DR_N_HAS_CHANGED (dr_changed, idx) == 0); */
/* The actual update is done later just before resuming the lwp,
we just mark that one register pair needs updating. */
DR_MARK_N_CHANGED (dr_changed, idx);
*dr_changed_ptr = dr_changed;
/* The actual update is done later just before resuming the lwp,
we just mark that one register pair needs updating. */
DR_MARK_N_CHANGED (dr_changed, idx);
*dr_changed_ptr = dr_changed;
/* If the lwp isn't stopped, force it to momentarily pause, so
we can update its debug registers. */
if (!lwp->stopped)
linux_stop_lwp (lwp);
/* If the lwp isn't stopped, force it to momentarily pause, so
we can update its debug registers. */
if (!lwp->stopped)
linux_stop_lwp (lwp);
if (show_debug_regs)
{