[0/9]#2 Fix lost siginfo_t

[Jan Kratochvil <jan.kratochvil@redhat.com>]

series #2 of: http://sourceware.org/ml/gdb-patches/2010-07/msg00405.html

Hi,

currently GDB's postponing and resending signals across threads drops the
associated siginfo_t information.  This can break real world inferiors
	https://bugzilla.redhat.com/attachment.cgi?id=413842
and it is also tested by a new testcase.

IMO all current `int status', `int host_signal' and `enum target_signal'
should be associated with their siginfo_t as otherwise they carry incomplete
information.  This is implemented by this patchset although it brings sizeof
(target_signal) to 144.  It is currently passed by value everywhere, it could
be shortened by the currently unused 80 bytes siginfo_t padding to 64 bytes.

I tried to make target_signal a pointer with reference counter.  I have the
unfinished patch here but I really do not find it viable.  All the assignments
and passing by value to functions make it difficult to catch all the cases.
With C++ GDB this patchset could be greatly simplified with fixed performance.

Fortunately target_signal does not have to be allocated dynamically.  The
maximum-over-all-targets of sizeof (siginfo_t) is known during compilation.
Even for remote targets the tdep file must be compiled in.  And GDB currently
does not support any dlopen()able plugin tdeps (*).  Therefore currently if
none of the siginfo-supporting targets ({amd64,i386,arm}-linux) is compiled in
this patchset has absolutely no new overhead.

(*) One can probably dlopen() a new tdep .so file through python.  Let this be
    unsupported, it could internal_error in target_signal_siginfo_set otherwise.

Some native host files probably got broken needing trivial updates for the
target_signal_t->struct change.  I did some obvious ones but I could not catch
all without the specific host machine for a build.

Planned gdb/remote.c part will probably need to modify the
target_signal_siginfo_* functions a bit, therefore only RFCing that part now
to be checked-in only together with the gdb/remote.c part later.

No regressions on {x86_64,x86_64-m32,i686}-fedora14snapshot-linux-gnu.
  New gdb.threads/siginfo-threads.exp fully PASSes there.
{ppc64,s390x}-rhel60snapshot-linux-gnu: no regressions.
  New gdb.threads/siginfo-threads.exp PASSes but si_* checks are unsupported
  as gdbarch_get_siginfo_type is not supported there.
{ppc64(ppc),ia64,s390x}-rhel56-linux-gnu: no regressions.
  New gdb.threads/siginfo-threads.exp is completely UNSUPPORTED as the kernel
  there has no rt_tgsigqueueinfo syscall.

Not yet done:

 * gdb/remote.c still does not feature the siginfo_t preservation.
   I definitely need/plan to implement it for gdb/remote.c .

   Still the communication will probably get slowed down - both by more
   round-trips to always fetch+push associated TARGET_OBJECT_SIGNAL_INFO and
   also by all the 128 bytes blocks transferred back and forth.  The protocol
   would be probably appropriate to extend a bit for it.  I would normally
   rather care about ugdb (Linux kernel server, GPLv2) than FSF GDB gdbserver,
   unless required for the FSF GDB gdb/remote.c counterpart patch acceptance.

Not planned for this patchset:

 * gdb/gdbserver/ siginfo_t preservation.  I would normally
   rather care about ugdb (Linux kernel server, GPLv2) than FSF GDB gdbserver,
   unless required for the FSF GDB gdb/remote.c counterpart patch acceptance.

 * sim/ did not use `enum target_signal' and now it still does not use
   `target_signal_t' and none of the associated accessors.  There are several
   new FIXMEs at the gdb/remote-sim.c interface.

 * As target_signal_t is now gdbarch-specific for the specific frame I guess
   if you get in SPU frame a signal with "stop print pass", do `(gdb) return'
   to get out into a PPC frame and do `(gdb) continue' GDB will gdb_assert due
   to non-matching gdbarch.  One could probably extend siginfo_fixup() for
   this case although it is more questionable what behavior is correct in such
   case.


Thanks,
Jan