From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22991 invoked by alias); 8 Mar 2003 15:22:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22982 invoked from network); 8 Mar 2003 15:22:50 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 8 Mar 2003 15:22: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 KAA31241; Sat, 8 Mar 2003 10:09:41 -0500 Received: from dash ([192.168.20.28]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id KAA10634; Sat, 8 Mar 2003 10:22:49 -0500 Message-ID: <006601c2e587$36c4d490$2a00a8c0@dash> From: "Kris Warkentin" To: "Kris Warkentin" , "Mark Kettenis" Cc: References: <200303081344.h28DiNvi040785@elgar.kettenis.dyndns.org> <005a01c2e586$c0178360$2a00a8c0@dash> Subject: Re: [RFC] QNX Neutrino/i386 support Date: Sat, 08 Mar 2003 15:22: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.1106 X-SW-Source: 2003-03/txt/msg00189.txt.bz2 > > I'm still struggling with the shared library stuff. There's something > > fishy in there, but it seems that the comment in nto-tdep.c is wrong, > > or at least outdated. > > There have been some fairly long thread on the mailing list about the solib > issue. Look for threads 'relocation of shared libs not based at 0' starting > back in November/December and some more recently. You may be right about > the comment - I should take a look at it again but the long and the short of > it is that we have a slightly different interpretation of the way > relocations are done. Our chief architect can explain it better but it's > possible that neither interpretation is wrong - one treats two base > addresses as the same, the other doesn't. Either way, the override of > relocate_section_addresses is ABSOLUTELY required. If this is not done, > global data in shared objects will be off by a page. Aha. Found relevant explanation from our chief architect. http://sources.redhat.com/ml/gdb/2003-02/msg00202.html cheers, Kris