IBM S/390 prologue analysis revisited

[Jim Blandy <jimb at redhat dot com>]

I'd like to revisit the question of how to proceed with the s390 frame
unwinding / prologue analysis code.  I'd like to commit my prologue
analysis changes, but the IBM GDB folks have expressed a general
interest in keeping the prologue analysis logic minimal and using
Dwarf CFI everywhere.  So I'd like to outline my reasons, and see what
the community thinks is the best approach to take.

At the moment, stack unwinding in optimized code works pretty badly.
There are two ways to address this:
- get s390-tdep.c to use Dwarf CFI, and / or
- improve s390-tdep.c's prologue analysis.

IBM has patches to use Dwarf CFI, but they predate most of Andrew's
recent changes to the frame, unwinding, and regcache interfaces.
These patches are effectively dead, until IBM brings them up to date.

But nowadays, of course, it's trivial to get a target to use Dwarf
CFI --- *if* it's using the latest interfaces.  Which s390-tdep.c
doesn't.  I've posted a list of the work needed, and it's going to
take a while.  So this option, which we should pursue, is a ways off.

I have patches for almost-current sources that implement a complex,
but quite effective, prologue analysis system in s390-tdep.c; they
make GDB a lot more useable on real code.  They are a drop-in
replacement for the existing prologue analyzer, which is an internal
interface, so I don't think they make it harder to bring the port up
to date.  They'd be an immediate step forward, without making further
improvements harder.  They'd make IBM's CFI patches even harder to
apply, but they're already dead anyway.  And finally, I suspect that,
even with Dwarf CFI widely available, prologue analysis will continue
to be useful for a while.

The major disadvantage is that it goes contrary to the general
preference for "minimal" prologue analysis.

So, how do you folks feel the balance falls?