From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16342 invoked by alias); 22 May 2012 15:40:24 -0000 Received: (qmail 16193 invoked by uid 22791); 22 May 2012 15:40:23 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from shell4.bayarea.net (HELO shell4.bayarea.net) (209.128.82.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 May 2012 15:40:04 +0000 Received: (qmail 10856 invoked from network); 22 May 2012 08:40:03 -0700 Received: from c-76-102-3-160.hsd1.ca.comcast.net (HELO redwood.eagercon.com) (76.102.3.160) by shell4.bayarea.net with SMTP; 22 May 2012 08:40:03 -0700 Message-ID: <4FBBB352.6080009@eagerm.com> Date: Tue, 22 May 2012 15:40:00 -0000 From: Michael Eager User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Pedro Alves 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> In-Reply-To: <4FBB67AE.5090807@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: 2012-05/txt/msg00828.txt.bz2 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. :-) > 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. 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. 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. I don't have a host core file; it's a target core file. > gdbserver is always native, so always host. That's the exception. But that should still use the target to/from internal translation function. > 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. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077