From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31035 invoked by alias); 30 Aug 2010 07:10:08 -0000 Received: (qmail 31022 invoked by uid 22791); 30 Aug 2010 07:10:05 -0000 X-SWARE-Spam-Status: No, hits=-5.1 required=5.0 tests=AWL,BAYES_40,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Aug 2010 07:10:00 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o7U79xIe012543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Aug 2010 03:09:59 -0400 Received: from host1.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o7U79uGx003207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Aug 2010 03:09:58 -0400 Received: from host1.dyn.jankratochvil.net (localhost [127.0.0.1]) by host1.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id o7U79u61011298 for ; Mon, 30 Aug 2010 09:09:56 +0200 Received: (from jkratoch@localhost) by host1.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id o7U79ue9011297 for gdb-patches@sourceware.org; Mon, 30 Aug 2010 09:09:56 +0200 Date: Mon, 30 Aug 2010 07:10:00 -0000 From: Jan Kratochvil To: gdb-patches@sourceware.org Subject: [0/9]#2 Fix lost siginfo_t Message-ID: <20100830070955.GA6831@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-12-10) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-08/txt/msg00480.txt.bz2 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