From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32660 invoked by alias); 22 May 2012 16:02:31 -0000 Received: (qmail 32646 invoked by uid 22791); 22 May 2012 16:02:28 -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; Tue, 22 May 2012 16:02:07 +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 q4MG21GQ012972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 May 2012 12:02:01 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q4MG1xgo029221; Tue, 22 May 2012 12:02:00 -0400 Message-ID: <4FBBB877.8010109@redhat.com> Date: Tue, 22 May 2012 16:02: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: "Maciej W. Rozycki" , "gdb-patches@sourceware.org" Subject: Re: MIPS Linux signals References: <4FB850CA.7090701@eagerm.com> <4FBAB500.7010104@redhat.com> <4FBAB948.7000808@eagerm.com> <4FBB67AE.5090807@redhat.com> <4FBBB352.6080009@eagerm.com> In-Reply-To: <4FBBB352.6080009@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/msg00830.txt.bz2 On 05/22/2012 04:40 PM, Michael Eager wrote: > On 05/22/2012 03:17 AM, Pedro Alves wrote: > >> I agree that the current naming is confusing, but I'll point out why I think >> target_signal_from_host is actually correct, and then conclude with renaming >> suggestions to avoid the confusion, and fix the naming of the gdbarch hook, which >> I think is not correct. We have >> >> enum target_signal >> { >> ... >> TARGET_SIGNAL_FOO, >> TARGET_SIGNAL_BAR, >> ... >> }; >> >> which represents GDB's internal signal numbers.AFAIK, the "target_" prefix >> naming in this case is just a natural choice, given that that's how we name >> everything behind the target_ops abstraction -- target_read_memory, >> target_resume, etc., etc. (target.h) -- the mechanism that is mostly about >> abstracting the details of handling the target's debug interface API. > > As you say, these are GDB's internal values. They are not the values used on > (some) targets. They are not the values used by (some) host systems either. > > There's a difference between target_read_memory() which actually reads a > value from the memory on the target, and target_signal which is not the > value from the target, but a translated internal value. > >> So this explains the "target_signal_from_" part of the function's signature. > > Not for me. :-) Could it be you mean "I agree, but I think the naming of the enum could be clearer/better"? The enum is called "enum target_signal". So the function that converts an enum target_signal from something else is called "target_signal_from_...". That much seems clear enough to me. > >> The "from_host" part is really correct: this really is a host function -- think in >> terms of autoconf's notion of build vs host vs target. It only makes sense to call >> it in native code (native == host). And in fact, that's what happens. > > GDB tends to muddle host and target. Or perhaps the confusion is between the > host environment and GDB's internal data structures. Not sure what you're alluding to. > There is no need to translate signal numbers from the host system environment > to the target system environment. There is a need to translate from GDB's internal > numbering to the target numbering, and vice versa. There is nothing significant > about the host's signal numbering that should affect how GDB works with the target, > whether the target is a native process, remote system, or core file. Correct. Is that in disagreement with anything I said? It's just that GDB's internal signal numbering is called "enum target_signal". > > When target=host, translating from the target's signal numbering to GDB's > internal numbering should be identical to the case when target!=host. > > target_signal_from_host() makes no sense to me. It makes sense in the native/host-only parts of GDB. linux-nat.c and friends, etc. > I don't have a host core file; it's a target core file. Yes, that's why in corelow.c the conversion goes through the gdbarch method. corelow.c is not a native/host-only file (ideally anyway). We have the target_signal_from_host fallback for old ports that haven't yet bothered to convert to modern mechanisms, and can't cross-debug cores. > >> gdbserver is always native, so always host. > > That's the exception. So is all the native-debugger code within GDB; code which we want to actually split out of gdb and share/merge with gdbserver. > But that should still use the target to/from internal > translation function. Correct. > >> enum target_signal => enum gdb_signal >> >> target_signal_from_host => gdb_signal_from_host (or gdb_signal_from_host_signal) >> target_signal_to_host => gdb_signal_to_host (or gdb_signal_to_host_signal) >> >> gdbarch_target_signal_from_host => gdbarch_gdb_signal_from_target (or gdbarch_gdb_signal_from_target_signal) >> gdbarch_target_signal_to_host => gdbarch_gdb_signal_to_target (or gdbarch_gdb_signal_to_target_signal) > > OK, but I'd recommend > target_signal_from_host => gdb_signal_from_target > target_signal_to_host => gdb_signal_to_target > > This is symmetric with the gdbarch_ functions and clear that the function > translates to/from target system values, not the host system. But it's not what the functions do... They really convert from the host system signals, not the target's. I think the symmetry will only lead to people getting confused (which one to call in common/target-independent code?). -- Pedro Alves