From: James Cownie <jcownie@etnus.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: libc-alpha@sources.redhat.com, binutils@sources.redhat.com,
gdb@sources.redhat.com
Subject: Re: RFC: ELF prelinker - 0.1.1
Date: Thu, 05 Jul 2001 04:31:00 -0000 [thread overview]
Message-ID: <15I7Lu-0j2-00@etnus.com> (raw)
In-Reply-To: <20010705125600.Q737@sunsite.ms.mff.cuni.cz>
Jakub,
> I have to. Debugger relocates them too, but debugger relocates them
> by adding link_map->l_addr, which is load address, not base address.
> Load address is the difference between actual virtual addresses in
> library and virtual addresses stored in the library.
Ahh, so the point is that l_addr is zero for a pre-linked library in
the good case, or the offset of where you have to place the pre-linked
library from where you pre-linked it to in the bad case.
So you are right, the debugger won't do any relocation for you (well,
it will, but adding zero doesn't achieve anything !).
Previously (when shared libraries were all linked as though they would
be loaded at zero), l_addr _was_ the base address of the library.
After all, l_addr is declared like this :-
ElfW(Addr) l_addr; /* Base address shared object is loaded at. */
It seems a pity to have to do so much work in the linker, though,
especially since rewriting DWARF2 will be _very_ unpleasant and
fragile. Since many of the things in DWARF2 are encoded in "LEB128"
format, which basically means they're a byte-string of appropriate
length, _and_ there are inter-object offsets to worry about when you
change the lengths of things in the middle. DWARF2 is _not_ designed
for rewriting.
When other people (such as SGI) have encountered the need to rewrite
DWARF2 they've chosen to do it by adding additional translation
tables, rather than attempting the DWARF2 modification :-(
Although it requires support in more tools, I would strongly suggest
that the right solution here is to extend the struct link_map to
include a new field for the debugger which is the offset to be applied
to debug information.
Something like this :-
struct link_map
{
/* These first few members are part of the protocol with the debugger.
This is the same format used in SVR4. */
ElfW(Addr) l_addr; /* Base address shared object is loaded at. */
char *l_name; /* Absolute file name object was found in. */
ElfW(Dyn) *l_ld; /* Dynamic section of the shared object. */
struct link_map *l_next, *l_prev; /* Chain of loaded objects. */
+ ElfW(Addr) l_debug_relocation; /* Value to be added to debug entries */
... etc ...
the debugger would then add (l_addr + l_debug_relocation)
to the debug entries.
Somehow you'd need to get this information (which is basically the
preferred base address of the pre-linked library) through to the
dynamic linker. I assume that that's not too hard ?
The advantage of an approach like this is that
the pre-linker doesn't have to relocate the debug information.
So
It's faster
It's independent of the debug formats
Making the pre-linker dependent on debug formats is a very bad idea
IMHO...
-- Jim
James Cownie <jcownie@etnus.com>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
next parent reply other threads:[~2001-07-05 4:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20010705125600.Q737@sunsite.ms.mff.cuni.cz>
2001-07-05 4:31 ` James Cownie [this message]
2001-07-05 5:02 ` Jakub Jelinek
2001-07-05 6:08 ` James Cownie
2001-07-05 8:42 ` Daniel Berlin
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=15I7Lu-0j2-00@etnus.com \
--to=jcownie@etnus.com \
--cc=binutils@sources.redhat.com \
--cc=gdb@sources.redhat.com \
--cc=jakub@redhat.com \
--cc=libc-alpha@sources.redhat.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