From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11302 invoked by alias); 28 Aug 2003 11:43:26 -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 11292 invoked from network); 28 Aug 2003 11:43:25 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 28 Aug 2003 11:43:25 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id GAA00499; Thu, 28 Aug 2003 06:54:40 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id HAA23718; Thu, 28 Aug 2003 07:43:24 -0400 Message-ID: <0e4501c36d59$a9f99950$0202040a@catdog> From: "Kris Warkentin" To: "Kevin Buettner" , "Gdb@Sources.Redhat.Com" References: <095901c36be1$60dbd860$0202040a@catdog> <1030828011027.ZM11134@localhost.localdomain> Subject: Re: Is QNX weird or is it just me? Date: Thu, 28 Aug 2003 11:43: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-08/txt/msg00311.txt.bz2 > > 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... Well, I tested the override of qnx_in_dynsym_resolve_code() to just return 0 and it doesn't seem to have any ill effects that I can see. We don't do lazy linking and aren't planning to any time in the future. The dlopen/dlsym thing didn't seem to have any trouble either so I'm just taking the easy solution for now and leaving a note to myself to re-examine it if we ever implement late binding. The flag idea is not bad but you're right about the inefficiency. Considering that the IN_DYNSYM_CODE is called for every step, it could slow things down a fair bit if I had to make an extra call. I bet if I encapsulated the flag in one of our packets that needs to go across the wire every step anyway, and just check it as it comes in; that would work though. Thanks. cheers, Kris