Re: [Gcl-devel] Mac OS X binary release

[Camm Maguire]

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