From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31284 invoked by alias); 18 Dec 2002 00:47:49 -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 31276 invoked from network); 18 Dec 2002 00:47:48 -0000 Received: from unknown (HELO pkoning.akdesign.com) (66.189.46.82) by 209.249.29.67 with SMTP; 18 Dec 2002 00:47:48 -0000 Received: from pkoning.akdesign.com.equallogic.com (IDENT:pkoning@localhost [127.0.0.1]) by pkoning.akdesign.com (8.11.6/8.9.3) with ESMTP id gBI0lXf01762; Tue, 17 Dec 2002 19:47:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15871.50596.942339.277490@pkoning.akdesign.com> Date: Tue, 17 Dec 2002 16:47:00 -0000 From: Paul Koning To: kevinb@redhat.com Cc: kewarken@qnx.com, gdb@sources.redhat.com Subject: Re: relocation of shared libs not based at 0 References: <032c01c2a60a$2368a6e0$0202040a@catdog> <1021218002802.ZM4459@localhost.localdomain> X-SW-Source: 2002-12/txt/msg00267.txt.bz2 >>>>> "Kevin" == Kevin Buettner writes: Kevin> ... Kevin> So, as I understand it, the "base address" is *not* an Kevin> absolute location, but is actually the difference between Kevin> where the segment ended up and the location assigned to it in Kevin> the executable file. Thus the "base address" is the proper Kevin> value to use to relocate the segment's start and end Kevin> addresses. That interpretation certainly matches the code. The document you quoted is not all that clearly worded, but it seems to take the same view of things. On the other hand, the shared library loader in NetBSD doesn't. It sets the "base address" in the link_map to the load address of the section, not the bias from the link address to the load address. That's why I changed solib-svr4.c in my copy of gdb. Perhaps a better fix is to change the loader in NetBSD to set "base address" to match gdb's expectations. Kevin> Now, it's possible that my understanding is flawed. If so, I Kevin> await enlightenment. I think it's also possible that the Kevin> shared library implementation that you're using might not Kevin> conform to the above definition of "base address". If that's Kevin> the case, then you can either attempt to get it fixed in the Kevin> code which implements the dynamic loader, or, if that's not Kevin> possible, create a new solib backend for gdb which implements Kevin> support for your shared library machinery. I suspect it would Kevin> be very similar to solib-svr4.c. Kevin> With regard to the two patches that have been posted for Kevin> fixing this problem, I don't think that either one is correct Kevin> in light of the above definition of "base address". It would be interesting to hear from a NetBSD wizard. I'd be happy with any fix that makes shared libs work in gdb for my platform. Part of the reason why I patched gdb rather than ldd.elf_so is so I could process coredumps from already shipped systems. Then again, there are few enough of those that this isn't a big consideration. paul