From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30786 invoked by alias); 26 Aug 2003 14:49:51 -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 30761 invoked from network); 26 Aug 2003 14:49:50 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 26 Aug 2003 14:49:50 -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 KAA15659 for ; Tue, 26 Aug 2003 10:01:16 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id KAA31180 for ; Tue, 26 Aug 2003 10:49:49 -0400 Message-ID: <095901c36be1$60dbd860$0202040a@catdog> From: "Kris Warkentin" To: "Gdb@Sources.Redhat.Com" Subject: Is QNX weird or is it just me? Date: Tue, 26 Aug 2003 14:49: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/msg00292.txt.bz2 I've discovered the source of some of our single stepping through shared libs problems. To remind anyone who hadn't seen my earlier threads, I was finding that doing a 'step' over a shared library call like printf() was single stepping all the way through which takes a hellishly long time on a remote target. I also discovered that the 'set step-mode on' command was only working on shared libs other than libc. This led me down the merry garden path to the realization that the check IN_SOLIB_DYNSYM_RESOLVE_CODE (which becomes svr4_in_dynsym_resolve_code in our case) was always returning true for libc. 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'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. cheers, Kris