From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Received: (qmail 23182 invoked from network); 9 Jan 2003 15:06:39 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 209.249.29.67 with SMTP; 9 Jan 2003 15:06:39 -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 JAA32485; Thu, 9 Jan 2003 09:58:22 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id KAA27909; Thu, 9 Jan 2003 10:06:26 -0500 Message-ID: <094301c2b7f0$a3867fd0$0202040a@catdog> From: "Kris Warkentin" To: "Colin Burgess" , "Kevin Buettner" Cc: "Paul Koning" , , "Peter van der Veen" References: Subject: Re: relocation of shared libs not based at 0 Date: Thu, 09 Jan 2003 15:06: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-01/txt/msg00129.txt.bz2 Well, there's certainly nothing to stop us from changing current_target_so_ops->relocate_section_addresses to point to our own function. The only issue with that is that initialization is then order dependent. We would just have to make sure that _initialize_svr4_solib() gets called before _initialize_some_qnx_specific_stuff(). I can certainly see the point of not wanting to break cross compilation so perhaps I'll just try to do it this way. cheers, Kris ----- Original Message ----- From: "Colin Burgess" To: "Kevin Buettner" Cc: "Kris Warkentin" ; "Paul Koning" ; ; "Peter van der Veen" Sent: Thursday, January 09, 2003 9:37 AM Subject: Re: relocation of shared libs not based at 0 > You already have architecture dependant code in fetch_link_map_offsets, couldn't > you do something similar for relocate_section_addresses? > > On Wed, 8 Jan 2003, Kevin Buettner wrote: > > > On Jan 8, 4:52pm, Kris Warkentin wrote: > > > > > This works fine on QNX and (I assume) NetBSD so it looks rather like we just > > > have a difference of opinion on how the shared object loader should fill > > > things in. We wanted to keep our linker's behaviour for some future > > > enhancements (pre-relocating shared objects on flash memory, etc.) so I was > > > hoping the fix below (Paul's code with some extra comments) might be > > > acceptable. That way Paul and I could just define LM_ADDR_IS_NOT_LOAD_BASE > > > in our tm-.h and we'd be off to the races. > > > > > > static void > > > svr4_relocate_section_addresses (struct so_list *so, > > > struct section_table *sec) > > > { > > > #if LM_ADDR_IS_NOT_LOAD_BASE > > > /* On some platforms, (ie. QNX, NetBSD) LM_ADDR is the assigned > > > address, not the offset. > > > The addresses are formed as follows: > > > LM_ADDR is the target address where the shared library file > > > is mapped, so the actual section start address is LM_ADDR plus > > > the section offset within the shared library file. The end > > > address is that plus the section length. Note that we pay no > > > attention to the section start address as recorded in the > > > library header. > > > */ > > > sec->endaddr = svr4_truncate_ptr (sec->endaddr - sec->addr + > > > sec->the_bfd_section->filepos + > > > LM_ADDR (so)); > > > sec->addr = svr4_truncate_ptr (sec->the_bfd_section->filepos + > > > LM_ADDR (so)); > > > #else > > > sec->addr = svr4_truncate_ptr (sec->addr + LM_ADDR (so)); > > > sec->endaddr = svr4_truncate_ptr (sec->endaddr + LM_ADDR (so)); > > > #endif > > > } > > > > The problem that I have with the above is that it's not possible to > > build a cross debugger that'll have shared library support for both > > Linux and NetBSD. > > > > If we could somehow detect (perhaps via the osabi mechanism) that we > > have one of the lm-addr-is-not-load-base platforms and enable that > > code at runtime, I wouldn't mind... > > > > Kevin > > > > -- > cburgess@qnx.com > >