From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22133 invoked by alias); 12 Mar 2002 04:01:02 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22011 invoked from network); 12 Mar 2002 04:00:58 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.135.44) by sources.redhat.com with SMTP; 12 Mar 2002 04:00:58 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 565873E0D; Mon, 11 Mar 2002 23:00:56 -0500 (EST) Message-ID: <3C8D7D78.10805@cygnus.com> Date: Mon, 11 Mar 2002 20:01:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] Always define all of TARGET_SIGNAL_* References: <20020227221148.A30753@nevyn.them.org> <3C7E456C.6090605@cygnus.com> <20020228115139.A8496@nevyn.them.org> <3C7E6634.4010209@cygnus.com> <20020310192038.A14083@nevyn.them.org> <3C8D68D8.8050403@cygnus.com> <20020311214925.C462@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00176.txt.bz2 > On Mon, Mar 11, 2002 at 09:32:56PM -0500, Andrew Cagney wrote: > >> > >> >Now that we've got a "gdb/signals.h", there's a place to fix this >> >properly in the trunk. How does this patch look? > >> >> Can I suggest sitting on this until after 5.2 is out! If the change is >> put on hold, then it will be easier to refresh the branch gdbserver from >> the trunk. >> >> The addition of things like a src/include/gdb/ directory to the branch >> shouldn't be an issue provided GDB proper doesn't try (get modified) to >> use it. > > > I think you're thinking of my other pending signals patch? This is the > one that has nothing to do with gdbserver, and I was just waiting for > the branch to be cut. If you'd rather I just hold it a bit longer > that's fine by me, though. I'm thinking of the net effect pulling both this patch and the other pending signal patch onto the 5.1 would have. (I'm not sure if you ment this or that I was confusing this patch with the other pending patches :-) Changing this enum scares me! -- Anyway, looking at the change: > -#if defined(MACH) || defined(__MACH__) > /* Mach exceptions */ > TARGET_EXC_BAD_ACCESS, > TARGET_EXC_BAD_INSTRUCTION, > @@ -216,7 +216,7 @@ enum target_signal > TARGET_EXC_EMULATION, > TARGET_EXC_SOFTWARE, > TARGET_EXC_BREAKPOINT, > -#endif > + > TARGET_SIGNAL_INFO, I think the code formally wrapped in #if should be moved to after TARGET_SIGNAL_INFO. Try sketching out all the possible combinations of mach X host X target X mach (I got confused after two but a guess is 8). I think you find that either we scramble (fix and break) some of the mach cases xor we break everything else. Hmm, no wonder that enum scares me :-) enjoy, Andrew -- Ex: Hardwired remote target built for GNU/Linux but with signals numbered to include the MACH values. It only works with a MACH host. GDB.