Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Kris Warkentin" <kewarken@qnx.com>
To: "Colin Burgess" <cburgess@qnx.com>, "Kevin Buettner" <kevinb@redhat.com>
Cc: "Paul Koning" <pkoning@equallogic.com>, <gdb@sources.redhat.com>,
	"Peter van der Veen" <peterv@qnx.com>
Subject: Re: relocation of shared libs not based at 0
Date: Thu, 09 Jan 2003 15:06:00 -0000	[thread overview]
Message-ID: <094301c2b7f0$a3867fd0$0202040a@catdog> (raw)
In-Reply-To: <Pine.NTO.4.21.0301090936550.18522153-100000@node109.ott.qnx.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
>
>


  reply	other threads:[~2003-01-09 15:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-17 12:23 Kris Warkentin
2002-12-17 12:31 ` Paul Koning
2002-12-17 13:36   ` Kris Warkentin
2002-12-17 16:28 ` Kevin Buettner
2002-12-17 16:47   ` Paul Koning
2003-01-08 21:52     ` Kris Warkentin
2003-01-08 22:24       ` Kevin Buettner
2003-01-09 14:35         ` Colin Burgess
2003-01-09 15:06           ` Kris Warkentin [this message]
2003-02-05 18:40       ` Paul Koning
2003-02-05 19:08         ` Kris Warkentin
2003-02-05 19:11         ` Kevin Buettner
2003-02-10 21:45           ` Paul Koning
2003-02-12 18:06             ` Kevin Buettner
2003-02-12 18:19               ` Kris Warkentin
2002-12-17 13:39 David Anderson
2003-02-12 18:37 Peter van der Veen
2004-01-05 17:39 Paul Koning
2004-01-09 22:48 ` Kevin Buettner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='094301c2b7f0$a3867fd0$0202040a@catdog' \
    --to=kewarken@qnx.com \
    --cc=cburgess@qnx.com \
    --cc=gdb@sources.redhat.com \
    --cc=kevinb@redhat.com \
    --cc=peterv@qnx.com \
    --cc=pkoning@equallogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox