[RFC] Support for dynamic core file register notes

[Andreas Arnez <arnez at linux dot vnet dot ibm dot com>]

On this list I've posted several iterations of a patch set that adds
GDB support for the new S/390 TDB register set.

The TDB regset is treated by the Linux kernel in an unusual way: it is
"present" only if the inferior was interrupted within a hardware
transaction.  Consequently, the kernel omits it from a core dump unless
the fault occurred within a transaction.

Currently GDB's regset handling infrastructure can not model this
behavior correctly.  Thus my patch sets also added such "dynamic" regset
support to GDB.  However, this change got stuck after some discussion,
thereby blocking the whole TDB regset patch set.  Thus I concluded that
it may be preferable to separate the two changes more cleanly and start
a new discussion thread specifically on the dynamic regset support, such
that the discussion can focus on the best way of adding such support to
GDB.

Let me summarize the approaches that have been kicked around so far:

* My initial proposal unconditionally replaces the gdbarch variable
  'core_regset_sections' by a new method 'iterate_over_regset_sections':

    http://sourceware.org/ml/gdb-patches/2013-06/msg00285.html

  This change affects all those architectures which had been setting the
  'core_regset_sections' gdbarch variable before.  In my view this
  change simplifies the regset handling, particularly on architectures
  with many regsets and with many different possible regset combinations
  in core files.  However, there doesn't seem to be consensus on this.

* The next version of the proposal adds 'iterate_over_regset_sections'
  as well, but makes it optional and keeps 'core_regset_sections' as a
  fallback, such that most architectures can stay unchanged:

    http://sourceware.org/ml/gdb-patches/2013-07/msg00149.html

  Note that this change requires a small tweak in the gdbarch.sh logic,
  to enable the required fallback handling.  Also note that this
  approach makes it unlikely to ever move all architectures to the
  iterator method.  Thus we'd again (!) enlarge the number of ways of
  specifying regsets.

* Before even posting the first patch set, I considered changing the
  return type of collect_regset_ftype from void to int, such that the
  collect routines could indicate availability of a regset dynamically.
  Adding return values to all regset collect routines is a trivial but
  pervasive change.  I didn't post it because of its pervasiveness and
  because it increases the code size, while the iterator approach
  actually decreases it.

* Along the lines of adding a return value to the collect routines, I
  also considered throwing an exception from within a regset collect
  routine when the regset is currently invalid.  Then the exception
  would be intercepted, and the regset would be skipped.  This is a
  smaller change than adding the return value, but the code size is
  still increased.

* After realizing the drawbacks of the "iterator with fallback"
  proposal, I outlined the opportunity to merge the information from
  core_regset_section into struct regset itself:

    http://sourceware.org/ml/gdb-patches/2013-07/msg00364.html

 This would allow dropping the core_regset_sections variable and
 replacing regset_from_core_section with iterate_over_regset_sections.
 Overall, the number of gdbarch interfaces would be reduced, and the
 complexity of the iterator methods would be comparable to the existing
 regset_from_core_section methods.

 This is a fairly large change, much more pervasive than adding a return
 value to collect_regset_ftype.  On the other hand, there's some
 potential for cleaning up the regset handling a little bit on the way.
 I've started a patch set, but haven't completed it yet.  Currently
 diffstat (on the merged patch) says:

   38 files changed, 384 insertions(+), 498 deletions(-)

 When finished, I expect the patch to be at least 50% bigger than that,
 and overall I expect several hundred lines of code reduction.  Unless
 anybody states that a change like this will never make it upstream,
 I'll take a shot at completing it.

Did I miss anything?  Maybe there's a better approach I have overlooked
so far?

In any case, I'd be interested in any suggestions which path to pursue.


--
Andreas