From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4281 invoked by alias); 9 Jun 2003 21:20:53 -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 4062 invoked from network); 9 Jun 2003 21:20:44 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 9 Jun 2003 21:20:44 -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 RAA25925; Mon, 9 Jun 2003 17:14:49 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id RAA08367; Mon, 9 Jun 2003 17:20:43 -0400 Message-ID: <033401c32ecd$07d8adc0$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> Subject: Re: problem with fetch_link_map_offsets Date: Mon, 09 Jun 2003 21:20: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/msg00120.txt.bz2 Okay, I think I've found the problem but I'm not sure what to do about it. 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. Is there any way to make my osabi "stick"? cheers, Kris > > > I also observe that svr4_have_link_map_offsets is called three times in > the > > > process of attaching to the remote proces. The first two are fine - > flmo is > > > still pointing to the qnx version. The third time it's pointing to the > > > legacy_flmo though. I can't figure out why. > > > > When you figure it out, let me know why too... > > Interesting. I've been doing a refactor of our gdb port and, for no > particular reason, I started with sh4. Just for chuckles, I finished our > i386 port and I'm not getting the same "No shared library support" error. I > wonder if there's something specific in the sh4 version that's overriding my > settings. I was watching current_gdbarch and it did seem to be changing > quite a bit. Perhaps you're right and the problem lies in there. > > cheers, > > Kris > >