From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30964 invoked by alias); 25 Mar 2004 17:22:11 -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 30950 invoked from network); 25 Mar 2004 17:22:10 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 25 Mar 2004 17:22:10 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id MAA26947; Thu, 25 Mar 2004 12:35:54 -0500 Received: from qnx.com ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with ESMTP id MAA14443; Thu, 25 Mar 2004 12:22:05 -0500 Message-ID: <406315A6.5000207@qnx.com> Date: Thu, 25 Mar 2004 17:22:00 -0000 From: Kris Warkentin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Andrew Cagney CC: "Gdb-Patches@Sources.Redhat.Com" Subject: Re: [patch] Bring QNX Neutrino support forward. References: <4060A9C0.1090906@qnx.com> <4060C665.6010405@gnu.org> <40618FCD.5010802@qnx.com> <40619CB3.90001@gnu.org> <4061B878.6010209@qnx.com> In-Reply-To: <4061B878.6010209@qnx.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00625.txt.bz2 Andrew, given that the core_fns are not deprecated yet, is this patch otherwise okay? It looks like I might be able to add some BFD support for our cores (perhaps a qnx_nto_core_flavour?) but I wouldn't mind getting this patch out of my sandbox for now. cheers, Kris Kris Warkentin wrote: > Andrew Cagney wrote: > >> Ulgh, one of those (if you remember any more details :-). I'll need >> to investigate - these race conditions are a royal pain. > > > I'll just temporarily move the signal setup stuff to my > _init....okay. It's this line of code in my init function: > > signal_stop_update (target_signal_from_name ("SIG45"), 0); > > The array 'signal_stop' in signal_stop_update has not been initialized > so we blow up. > >> There are no deprecated markers so there's no hint. A grep of >> add_core_fns reveals that the i386/amd64 and GNU/Linux PPC do not >> make the call so I'm pretty sure that I'm not talking theory here >> (notably 32x64 GNU/Linux debugging works on those systems -- that >> needs regsets). > > > > I think I'm failing to understand you here. If I don't use the > regset_core_functions, how do I sniff out a Neutrino core using > > if (bfd_get_section_by_name (abfd, ".qnx_core_info")) > you_have_core(); > ? > > Should I be adding that to the default_core_sniffer? > > cheers, > > Kris >