From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30596 invoked by alias); 28 Aug 2003 01:10:35 -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 30588 invoked from network); 28 Aug 2003 01:10:34 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 28 Aug 2003 01:10:34 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h7S1AYl17424 for ; Wed, 27 Aug 2003 21:10:34 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h7S1AXs03322; Wed, 27 Aug 2003 21:10:33 -0400 Received: from localhost.localdomain (vpn50-17.rdu.redhat.com [172.16.50.17]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h7S1AWTN012729; Wed, 27 Aug 2003 21:10:33 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h7S1ARw11135; Wed, 27 Aug 2003 18:10:27 -0700 Date: Thu, 28 Aug 2003 01:10:00 -0000 From: Kevin Buettner Message-Id: <1030828011027.ZM11134@localhost.localdomain> In-Reply-To: "Kris Warkentin" "Is QNX weird or is it just me?" (Aug 26, 10:50am) References: <095901c36be1$60dbd860$0202040a@catdog> To: "Kris Warkentin" , "Gdb@Sources.Redhat.Com" Subject: Re: Is QNX weird or is it just me? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-08/txt/msg00303.txt.bz2 On Aug 26, 10:50am, Kris Warkentin wrote: > Judging by the code for svr4_in_dynsym_resolve_code, I believe that the > issue is the fact that all our dynamic linker code is stored in our libc. > In fact, ld-qnx.so is just a link to libc.so. Is this weird or are there > other systems that do this? I've worked on at least one other system in the past which put the dynamic linker in libc.so. (I can only remember one at the moment. That one was weird.) > I'm just wondering if anyone can think of some way to write a replacement > for svr4_in_dynsym_resolve_code that would actually work properly in this > case. I suppose I could use the bfd to check and see if we're within the > bounds of the object where our ldd() function is but even that doesn't work > perfectly. After all, ldd() calls out to other objects as well. > > In some respects this isn't a critical issue because we do all our library > loading at startup (got to keep it real time deterministic don't you > know...) but there is still the dlopen/dlsym thing. I suppose I could just > cheat and define the function to always return false. This solves the > majority of the problems and I don't think will create many (if any) new > ones. > > I'm thinking that we might be stuck with actually needing to separate > ld-qnx.so from libc.so to get it working right but perhaps there are some > clever ideas about. Separating the dynamic linker out of libc.so seems like the most straightforward route to go. Another idea though: if your dynamic linker could set some flag when it's working and reset it when it's not, perhaps you could have gdb read the memory associated with the flag? Of course, that'd mean doing a target memory read every time qnx_in_dynsym_resolve_code() is called... Kevin