[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Mac OS X binary release
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] Mac OS X binary release |
Date: |
14 Nov 2003 17:50:27 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings!
Aurelien Chanudet <address@hidden> writes:
> > Great! Don't know if you saw the link I posted
> > some time ago describing the alternate
> > relocation pathways through the bfd library.
> > Very enlightening. Apparently there is a 'new'
> > preferred route which sidesteps
> > bfd_get_relocated_section_contents and does
> > something like a ..._final_link, as shown in
> > elflink.h if I recall. This is likely why
> > the newer Linux platforms don't have a working
> > bfd_get_relocated_section_contents. At some
> > point it would be fruitful to try making a
> > sfaslbfd_new.c following elflink.h instead,
> > though the code is a bit more complex than what
> > we have now. We may find that the low level
> > relocation information is already in the
> > library both for macosx and these linux
> > platforms (hppa ia64 alpha mips(el)). As you
> > and I are perhaps the only two people who've
> > looked at this part of GCL, if this ever gets
> > done its likely going to be one of us :-).
>
> I'm afraid I might have missed what you've posted
> some time ago about this 'new' and preferred
> relocation mechanism. Could you provide me a pointer
> ?
>
Here was the original note:
http://mail.gnu.org/archive/html/gcl-devel/2003-10/msg00189.html
> I didn't knew that bfd_get_relocated_section_contents
> was broken on some architectures. As I understand it,
> the ..._final_link routine you're referring to handles
> much more than what's needed for GCL, which basically
> is what bfd_get_relocated_section_contents provides.
> bfd_final_link not only handles loading the properly
> relocated section contents in memory, but is also
> responsible for creating the output symbol table and
> other stuff that we might not be interested in. But
> this is just my present thought on it.
>
You are right, I believe. Extracting just what we need from this
heavyweight, yet apparently universally working path through bfd might
prove to be a challenge. At worst we could just discard unneeded
dummy structures built along the way. This would of course make our
load about as heavyweight as a call to ld.
> I haven't had a chance to look at elflink.h yet.
> Maybe you could tell me what the logic in there is. I
> believe this could save me a great deal of time if I'm
> ever to look at this file.
>
Alas, I haven't had time to go through all the logic myself. The
'business' end of the code is, I believe, this call:
if (! (*relocate_section) (output_bfd, finfo->info,
input_bfd, o, contents,
internal_relocs,
isymbuf,
finfo->sections))
return false;
in
static boolean
elf_link_input_bfd (finfo, input_bfd)
in
binutils/bfd/elflink.h.
> > Here is the redirection page:
>
> And what did you do to get this error message ?
>
I just requested the top url (i.e. the url without the final filename)
in a browser.
Take care,
> ___________________________________________________________
> Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
> Yahoo! Mail : http://fr.mail.yahoo.com
>
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah