From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22553 invoked by alias); 9 Jun 2003 21:40:32 -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 22504 invoked from network); 9 Jun 2003 21:40:31 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 9 Jun 2003 21:40:31 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3p2/8.9.3) with ESMTP id RAA26641; Mon, 9 Jun 2003 17:34:36 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id RAA01448; Mon, 9 Jun 2003 17:40:31 -0400 Message-ID: <037201c32ecf$cb8e1460$0202040a@catdog> From: "Kris Warkentin" To: "Kevin Buettner" , "Gdb@Sources.Redhat.Com" References: <020701c30dc3$bd8cf020$0202040a@catdog> <1030429150643.ZM6454@localhost.localdomain> <030401c30e63$9c270560$0202040a@catdog> <1030429162815.ZM6720@localhost.localdomain> <00e501c30e94$e285e400$0202040a@catdog> <033401c32ecd$07d8adc0$0202040a@catdog> <1030609213428.ZM18478@localhost.localdomain> Subject: Re: problem with fetch_link_map_offsets Date: Mon, 09 Jun 2003 21:40:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-06/txt/msg00123.txt.bz2 > > Say, for example, I go into arm-tdep.c and comment out the section that > > registers a gdbarch osabi sniffer. Now my arm port works fine: it uses > > GDB_OSABI_QNXNTO and everything is hunky-dory. So the problem is that the > > sniffer says, "Oh, it's GDB_OSABI_ARM_APCS, let's set that up." and then all > > of my init stuff is out the door. > > > > The question is, how do I deal with this? There is nothing to distinguish a > > Neutrino binary from any other elf file. I tried registering another > > sniffer that just returned GDB_OSABI_QNXNTO but then it squawked that it got > > two osabi results. I'm assuming that this is probably what I'm running into > > on all my targets. > > It sounds to me like the problem is with the sniffer(s). If the sniffer > is determining GDB_OSABI_ARM_APCS for a QNX binary, that's bad and the > sniffer ought to be fixed. Yeah but....a QNX binary is just an ordinary elf binary. There are no special sections or magic in there for the sniffer to catch. Hence my problem. Perhaps it should be returning unknown so that another sniffer (like my one liner) could get it? Kris