From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12480 invoked by alias); 28 Jul 2009 11:03:54 -0000 Received: (qmail 12224 invoked by uid 22791); 28 Jul 2009 11:03:52 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_42,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Jul 2009 11:03:41 +0000 Received: (qmail 17109 invoked from network); 28 Jul 2009 11:03:39 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Jul 2009 11:03:39 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] nto-tdep.c - adjust addr_low addr_high Date: Tue, 28 Jul 2009 11:29:00 -0000 User-Agent: KMail/1.9.10 Cc: Aleksandar Ristovski References: <200907241425.45805.pedro@codesourcery.com> <4A6E141E.1080006@qnx.com> In-Reply-To: <4A6E141E.1080006@qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907281203.37720.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00671.txt.bz2 On Monday 27 July 2009 21:54:54, Aleksandar Ristovski wrote: > Pedro Alves wrote: > > On Wednesday 08 July 2009 15:26:55, Aleksandar Ristovski wrote: > > > >> This adjusts so->addr_low and so->addr_high for proper "info > >> sahredlibrary" output. > > > >> Index: gdb/nto-tdep.c > >> =================================================================== > >> RCS file: /cvs/src/src/gdb/nto-tdep.c,v > >> retrieving revision 1.34 > >> @@ -315,6 +316,10 @@ nto_relocate_section_addresses (struct s > >> > >> sec->addr = nto_truncate_ptr (sec->addr + LM_ADDR (so) - vaddr); > >> sec->endaddr = nto_truncate_ptr (sec->endaddr + LM_ADDR (so) - vaddr); > >> + if (so->addr_low == 0) > >> + so->addr_low = LM_ADDR (so); > > > > Isn't LM_ADDR an offset, not an absolute address? > > In our case, it's absolute address of .text (that is why we > subtract vaddr as read from phdr). Ah, I see. You always get l_addr from the link map. I take it you mean absolute address of the lowest segment -- if .text isn't the lowest loaded section, then LM_ADDR will be lower than the .text's virtual address in memory, IIUC. Patch is OK. I see now that 'nto-tdep.c:struct lm_info' is a 100% copy of the solib-svr4.c version --- and it has to be so to keep binary compatibility between the modules (why isn't this structure in a shared header, hasn't this been a headache before?) --- but it's comments end up being inaccurate for NTO: /* Amount by which addresses in the binary should be relocated to match the inferior. This could most often be taken directly from lm, but when prelinking is involved and the prelink base address changes, we may need a different offset, we want to warn about the difference and compute it only once. */ CORE_ADDR l_addr; IIUC, you won't reach solib-svr4.c:LM_ADDR_CHECK's offset computing, or it's warning on nto. lm_info->lm_addr ends up unused too, IIUC. This makes me wonder if there's no better way of implementing (and getting rid of) this NTO overriding of svr4_so_ops, e.g., with a gdbarch property that would be checked on solib-svr4.c:LM_ADDR_CHECK. Anyway, I'm diverging now. > > > >> + if (so->addr_high < sec->endaddr) > >> + so->addr_high = sec->endaddr; > >> } > >> > >> /* This is cheating a bit because our linker code is in libc.so. If we > > -- Pedro Alves