From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13651 invoked by alias); 2 Sep 2010 10:32:07 -0000 Received: (qmail 13637 invoked by uid 22791); 2 Sep 2010 10:32:06 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,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; Thu, 02 Sep 2010 10:31:59 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o82AVR0b024593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Sep 2010 06:31:28 -0400 Received: from host1.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o82AVPXi020929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Sep 2010 06:31:27 -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 o82AVOw9022140; Thu, 2 Sep 2010 12:31:24 +0200 Received: (from jkratoch@localhost) by host1.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id o82AVNOb022135; Thu, 2 Sep 2010 12:31:23 +0200 Date: Thu, 02 Sep 2010 14:01:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org, Daniel Jacobowitz , Joel Brobecker , Eli Zaretskii , Mark Kettenis Subject: Re: [patch 1/9]#2 Rename `enum target_signal' to target_signal_t Message-ID: <20100902103122.GA11298@host1.dyn.jankratochvil.net> References: <20100901200621.GA11085@caradoc.them.org> <201009012108.56984.pedro@codesourcery.com> <201009020254.47745.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201009020254.47745.pedro@codesourcery.com> 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-09/txt/msg00085.txt.bz2 On Thu, 02 Sep 2010 03:54:47 +0200, Pedro Alves wrote: > A target_signal_o array to hold > all the possible gdb signals, and a target_signal becomes: > > typedef const struct target_signal_o * target_signal; This means there is abandoned the possibility to associate dynamic information with a signal (such as to associate siginfo_t with it). Target signal (SIG*) without its siginfo_t is an incomplete information. Therefore I was automatically trying to fix this problem before. Therefore if GDB middle-end (infrun.c) does not need the siginfo_t part ... does it even need to know the signal number (int host_signal - SIG*) part? echo * mi/* tui/* gdbserver/*|tr ' ' '\n'|grep -v ChangeLog|xargs cat|perl -lne 'print $& while /\bTARGET_SIGNAL_\w+/g;'|sort|uniq -c|sort -nr|vi - says GDB references only 30 TARGET_SIGNAL_* signals (out of the 150 existing ones) so it does not need to really know the specific signal number. Those 120 signals could be kept private only to remote.c and gdbserver(s) for the purpose of compatibility of the gdbserver protocol. (In fact all TARGET_SIGNAL_* should be kept private to the target as for example the "Treating signal as SIGTRAP" hack in infrun.c should be target specific and TARGET_SIGNAL_SIGTRAP should be called TARGET_SIGNAL_BREAKPOINT_HIT etc. But a full signals abstraction is a too expensive/naive/unreal clean-up project for now.) As a proof Linux `SIGSTKFLT' is now missing in the TARGET_SIGNAL_* list. But no GDB middle-end code needs to know what is `SIGSTKFLT'. This suggests we can reduce the TARGET_SIGNAL_* set only to the 30 signals (for an easy compatibility with current GDB code) and introduce a new target specific field (similar to the abandoned siginfo field): typedef struct { enum target_signal_number sig; /* TARGET_SIGNAL_* 30 possibilities */ int host_signal; /* untranslated SIG* number for TARGET_SIGNAL_UNKNOWN. */ } target_signal; - Naming is kept compatible with current GDB naming. The reality is: s/target_signal/gdb_signal/ s/host_signal/target_signal/ Target could provide a number-name table for the `handle' command covering just the specific 64 signals available at the Linux target (instead of the 150 ones from the TARGET_SIGNAL_* list). I don't say I want to do it or that it should be done. It has just explained to me why target_signal_t does not need to contain the siginfo_t information. > Anyway, here it is at least for the archives. BTW I like this approach (when no dynamic information needs and as explained above probably never will need to get associated). I do not like the `target_signal' name used for a type but that is a nitpick. Is ChangeLog required only for the final check-in? Or are global maintainers excluded from the ChangeLog submit requirement? I have spent a whole day writing it and the review did not get past the basic idea of my patchset. Thanks, Jan