From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9236 invoked by alias); 5 Feb 2003 22:24:38 -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 9186 invoked from network); 5 Feb 2003 22:24:36 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by 172.16.49.205 with SMTP; 5 Feb 2003 22:24:36 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6/8.12.5) with ESMTP id h15MO32H000402; Wed, 5 Feb 2003 23:24:03 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6/8.12.6) with ESMTP id h15MO2Ar001582; Wed, 5 Feb 2003 23:24:02 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6/8.12.6/Submit) id h15MO2rl001579; Wed, 5 Feb 2003 23:24:02 +0100 (CET) Date: Wed, 05 Feb 2003 22:24:00 -0000 Message-Id: <200302052224.h15MO2rl001579@elgar.kettenis.dyndns.org> From: Mark Kettenis To: kewarken@qnx.com CC: kewarken@qnx.com, gdb-patches@sources.redhat.com In-reply-to: <1e0d01c2cd5f$7d69d430$0202040a@catdog> (kewarken@qnx.com) Subject: Re: patch to add QNX NTO i386 support References: <1c3601c2cbc1$72eac3b0$0202040a@catdog> <86d6m6e9p7.fsf@elgar.kettenis.dyndns.org> <1dfb01c2cd5c$b2cf98b0$0202040a@catdog> <1e0d01c2cd5f$7d69d430$0202040a@catdog> X-SW-Source: 2003-02/txt/msg00200.txt.bz2 From: "Kris Warkentin" Date: Wed, 5 Feb 2003 16:42:32 -0500 > > You'll also need to find a way to distinguish QNX binaries from other > > OS'es. The hardware breakpoint stuff will have to be moved to the > > nm.h. Most of the other stuff shouldn't be necessary or should be > > moved there too. > > Okay. Not sure how but I'll look into it. Once I've done that, do I > register an osabi_sniffer to determine the binary? I don't think this is going to work. Our binaries are very generic elf with no special sections or anything to distinguish them. In that case you'll have to provide a default OS/ABI for your target. Add something like: *-*-nto*) gdb_osabi=GDB_OSABI_QNX ;; to the appropriate case-statement at the end of configure.tgt. The only way to tell that we're targetting a qnx binary will be when someone types 'target qnx ...'. Is it acceptable to have the gdbarch stuff come into play when someone does that targetting? I'm not sure. If the "qnx" protocol implies that the OS/ABI is QNX, this would make sense to me, but there are other people on this list that could judge better. Mark