Re: relocation of shared libs not based at 0

["Kris Warkentin" <kewarken at qnx dot com>]

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" <cburgess@qnx.com>
To: "Kevin Buettner" <kevinb@redhat.com>
Cc: "Kris Warkentin" <kewarken@qnx.com>; "Paul Koning"
<pkoning@equallogic.com>; <gdb@sources.redhat.com>; "Peter van der Veen"
<peterv@qnx.com>
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-<host>.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
>
>