From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11134 invoked by alias); 17 Jun 2013 16:59:53 -0000 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 Received: (qmail 11121 invoked by uid 89); 17 Jun 2013 16:59:51 -0000 X-Spam-SWARE-Status: No, score=-8.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 17 Jun 2013 16:59:50 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5HGxgCt000727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 12:59:42 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r5HGxe4L004777; Mon, 17 Jun 2013 12:59:41 -0400 Message-ID: <51BF407C.3040905@redhat.com> Date: Mon, 17 Jun 2013 17:02:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sergio Durigan Junior CC: Pierre Muller , "'GDB Patches'" Subject: Re: [RFC/PATCH] Add new internal variable $_signo References: <002801ce68dd$845cd2e0$8d1678a0$@muller@ics-cnrs.unistra.fr> <51BB7B58.9030007@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00383.txt.bz2 On 06/14/2013 09:35 PM, Sergio Durigan Junior wrote: > On Friday, June 14 2013, Pedro Alves wrote: > >> gdb_signal_to_host is the fallback (and having a fallback is sort of a >> hack). The right signal number is the target's not the host's. We >> have gdbarch_gdb_signal_from_target for the opposite direction, but not >> gdbarch_gdb_signal_to_target... Having to bake the target OS's signal >> numbers into GDB is a bit unfortunate, though we could get around it >> at some point if we wanted by extending the RSP, and/or adding a python >> hook. > > I was looking for a target variant but found none. I'm not sure what > you mean with your comment. The right signal conversion is gdb signal <-> target signal. gdb_signal_to_HOST only works for native debugging, because in that case target == host. See in corelow.c: /* If we don't have a CORE_GDBARCH to work with, assume a native core (map gdb_signal from host signals). If we do have CORE_GDBARCH to work with, but no gdb_signal_from_target implementation for that gdbarch, as a fallback measure, assume the host signal mapping. It'll be correct for native cores, but most likely incorrect for cross-cores. */ enum gdb_signal sig = (core_gdbarch != NULL && gdbarch_gdb_signal_from_target_p (core_gdbarch) ? gdbarch_gdb_signal_from_target (core_gdbarch, siggy) : gdb_signal_from_host (siggy)); The same comment applies for reverse conversions (gdb -> target). We just don't do any in GDB at present. These new convenience variables would be the first such uses. > Are you suggesting that I take care of this as well? I'm suggesting that using gdb_signal_to_host only does the right thing with native debugging, and that the proper conversion involves adding a gdbarch_gdb_signal_to_target hook. Given it doesn't exist, it needs to be written... (This actually negates my previous comment on $_signo existing for all targets...) Then I mumbled that this target signal -> gdb signal -> target signal conversions are unfortunate, and that we could consider bypassing them, by either (or both) extending the target interfaces to pass along the original target signal (the signal numbers that pass around in the remote protocol are GDB signal numbers, not the target signals), and/or adding a python hook to aid in the conversion (so support for random embedded RTOSs would be added without changing gdb). > In the meantime, I will leave the code as-is, i.e., without doing any > kind of conversion on infrun.c -- Pedro Alves