From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8440 invoked by alias); 26 Jun 2003 14:46:28 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8422 invoked from network); 26 Jun 2003 14:46:27 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 26 Jun 2003 14:46:27 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19VY1h-0002ja-00; Thu, 26 Jun 2003 09:47:05 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19VY0l-000574-00; Thu, 26 Jun 2003 10:46:07 -0400 Date: Thu, 26 Jun 2003 14:46:00 -0000 From: Daniel Jacobowitz To: Kris Warkentin Cc: "Gdb@Sources.Redhat.Com" Subject: Re: [RFC] target defined OSABI sniffer Message-ID: <20030626144607.GA19638@nevyn.them.org> Mail-Followup-To: Kris Warkentin , "Gdb@Sources.Redhat.Com" References: <040001c33bf1$4ed98060$0202040a@catdog> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <040001c33bf1$4ed98060$0202040a@catdog> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-06/txt/msg00488.txt.bz2 On Thu, Jun 26, 2003 at 10:43:29AM -0400, Kris Warkentin wrote: > It seems that a lot of effort has been put into the multi-arch stuff but > most of it centers around recognizing a binary and setting things up based > on that. I'm pondering whether that is the right approach in all cases. > Shouldn't the target be telling gdb what it should be doing rather than the > other way around? I've been looking at different ways of getting gdb to > recognize a QNX binary so that it can set the OSABI properly but shouldn't > the fact that I'm connected to a remote neutrino machine be sufficient? > > One possible solution that I'm considering is to put something like a > TARGET_SNIFF_OSABI() type function in the generic sniffer. That way, when > I'm connected to a remote machine, I can just set the osabi and arch to > match that machine. Then, if the binary isn't compatable, we can error out. > > In the native case, my current_target should KNOW that it's on a Neutrino > box and be able to respond with the appropriate osabi. > > Can anyone comment on some possible downsides of this? Our chief architect > is fairly insistent that we shouldn't need a way to recognize a Neutrino > binary and I'm not having a lot of luck convincing him otherwise. Just from > my experience chasing these osabi problems, it looks like there are LOTS of > places where the arch can shift under my feet. I'm thinking that maybe core > files or simulators might be a problem. The other problem might be that You're quite right. How do you expect to take a binary and a core dump and realize they are QNX? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer