From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23789 invoked by alias); 21 May 2012 17:37:17 -0000 Received: (qmail 23439 invoked by uid 22791); 21 May 2012 17:37:13 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,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, 21 May 2012 17:36:55 +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.14.4/8.14.4) with ESMTP id q4LHaoCI003577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 May 2012 13:36:50 -0400 Received: from [127.0.0.1] (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 q4LHamw7007055; Mon, 21 May 2012 13:36:49 -0400 Message-ID: <4FBA7D30.50500@redhat.com> Date: Mon, 21 May 2012 17:37:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michael Eager CC: "gdb-patches@sourceware.org" Subject: Re: MIPS Linux signals References: <4FB850CA.7090701@eagerm.com> <4FBA2111.8010801@redhat.com> <4FBA5651.4070909@eagerm.com> In-Reply-To: <4FBA5651.4070909@eagerm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: 2012-05/txt/msg00779.txt.bz2 On 05/21/2012 03:50 PM, Michael Eager wrote: > On 05/21/2012 04:03 AM, Pedro Alves wrote: >> On 05/20/2012 03:02 AM, Michael Eager wrote: > >>> 4 -- Do the multiple layers of wrappers around target_ >>> signal_{to,from}_host in signals.c serve any purpose? >> >> Can you be more specific? What multiple layers? > > target_signal_to_host() is a wrapper around do_target_signal_to_host(). > > target_signal_to_host_p() is a wrapper around do_target_signal_to_host(). Yes, do_target_signal_to_host is a helper for both target_signal_to_host and target_signal_to_host_p. > This appears to be only used in gdbserver, where, on MIPS, it will > return the wrong result. Why will it return the wrong result on MIPS/gdbserver? The common/signals.c copy built into gdbserver will naturally be built with a MIPS headers, and should pick up the correct signal defines (SIGINT, etc.). > Incidentally, gdbserver on MIPS calls > the X86 target_signal_to_host() to translate signals. This seems > confused. Now I'm confused. What do you mean that MIPS gdbserver calls the X86 target_signal_to_host ? There's only one target_signal_to_host function AFAICS. > If gdb is translating internal signal numbers to the > target signal numbers, then this seems to be a second translation. gdbserver internally translates Linux signal numbers to the host independent internal signal numbers. We call the latter "target signals", like we call every method that goes through the "target abstraction" (target_ops vector) in gdb target_something. The native signals that are host dependent (host in the same sense as build vs host vs target on autoconf), we call them host signals. On the "wire", RSP packets should contain only the abstracted, internal, target signal numbers. So code on gdbserver that talks to ptrace will need to convert the (native) host signal numbers to target signals when pushing events to gdbserver common code, and ultimately to GDB. AFAIK, there's no such second internal signal numbers to target signal numbers translation in GDB. The remote target already works with GDB's own internal signal numbers. > default_target_signal_to_host() is a wrapper around target_signal_to_host(). > > default_target_signal_from_host() is a wrapper around target_signal_from_host(). Right. gdbarch_target_signal_from_host was invented long after target_signal_from_host already existed to solve the similar case you ran into. That is, of when cross debugging core files. In that case there's no gdbserver involved to do the host -> gdb/internal signal conversion for us, so GDB needs to do it, according to the core's gdbarch. If there's no such gdbarch callback installed, then we fallback to the host's default conversion, which with work when debugging native core files. So you do have the right fix, but the reason why nobody has tripped on this before is that this only affects cross core debugging, not live gdbserver debugging. -- Pedro Alves