[patch 0/3] Remove bpstat_what

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

Hi,

there is now bpstat_what function and its problematic state machine:

#   static const enum bpstat_what_main_action
#     table[(int) class_last][(int) BPSTAT_WHAT_LAST] =
#   {
#   /*                              old action */
#   /*               kc   ss   sn   sgl  slr  clr  sr  shl  jit */
# /* no_effect */   {kc,  ss,  sn,  sgl, slr, clr, sr, shl, jit},
# /* wp_silent */   {ss,  ss,  sn,  ss,  ss,  ss,  sr, shl, jit},
# /* wp_noisy */    {sn,  sn,  sn,  sn,  sn,  sn,  sr, shl, jit},
# /* bp_nostop */   {sgl, ss,  sn,  sgl, slr, slr, sr, shl, jit},
# /* bp_silent */   {ss,  ss,  sn,  ss,  ss,  ss,  sr, shl, jit},
# /* bp_noisy */    {sn,  sn,  sn,  sn,  sn,  sn,  sr, shl, jit},
# /* long_jump */   {slr, ss,  sn,  slr, slr, err, sr, shl, jit},
# /* long_resume */ {clr, ss,  sn,  err, err, err, sr, shl, jit},
# /* step_resume */ {sr,  sr,  sr,  sr,  sr,  sr,  sr, sr,  sr },
# /* shlib */       {shl, shl, shl, shl, shl, shl, sr, shl, shl},
# /* jit_event */   {jit, jit, jit, jit, jit, jit, sr, jit, jit}
#   };

There is also a comment:

# We could simply walk the bpstat list and choose the highest priority action
# we find

This patchset implements removal of this state machine.

Currently creating new enum bptype item implies dealing with possibly new
state (table row).  It is needlessly complicated and leads to difficult to
debug bugs (one example was the syscall-catch case).  The patchset originally
fixed PR 9436 caused by this state machine but that PR 9436 tested by
3/3-attached gdb.base/break-solib-event.exp started working on FSF GDB HEAD.
I did not run git-bisect as this PR was not a reason for this patchset anyway.

submit reason:
My gnu-ifunc patch http://sourceware.org/ml/gdb-patches/2010-02/msg00354.html
with two new breakpoint types would need this patch, also the gdb-side of PR
glibc/2328 would need a new libpthread-initialized breakpoint type and thus
dealing with bpstat_what again, I met it more times.


Maybe an opinion first would be nice, while I have been rechecking the patch
in the past month I can give it a one more go if it is the right way to go.

The code has been written with the goal of no functionality change when single
event happens.  More cleanups/fixes can and should happen in this new simpler
code but that is outside of the scope of this patch.  Due to the removal of
the state machine when >= 2 events happen the behavior now will be different,
I hope always only the better one.

No regressions on {x86_64,x86_64-m32,i686}-fedora12-linux-gnu.


Thanks,
Jan