gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] BFD relocations


From: Camm Maguire
Subject: [Gcl-devel] BFD relocations
Date: Sun, 02 Jun 2002 23:52:40 -0400
User-agent: WEMI/1.13.7 (Shimada) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386-debian-linux-gnu) MULE/4.0 (HANANOEN)

Greetings!  Just to announce that I've gotten a pure bfd sfasl
relocation working on x86.  No rsym_elf used, nor any elf-specific
structures invoked.  Thought this could help with portability.  With
this file set in the config, gcl should compile on any arch having
bfd, and should work in principle the same way on all.

Unfortunately, I've only gotten the thing to work on x86 so far.  It
appears as though the ideal function that I need in the lib,
bfd_get_relocated_section_contents, has not been adequately tested in
the library, as the linker uses the bfd through a different, more
arch-specific, and much more involved, likely slower path.   Choices: 
1) To ape the linker path in all its complexity, 2) to ask the
binutils developers for help/fixes, 3) to forget about bfd and add our
own solutions one step at a time.

It appears as though sfasldlsym will work pretty much everywhere, but
will not allow one to save an image after fasloading.  (From the faq
Dr. Schelter left in the main directory.)  I have not confirmed this.  

Here is my note to the bfd upstream.

Take care,
=============================================================================

Greetings!  I saw your post about bfd_get_relocated_section_contents
usage in gdb, and was pleasantly surprised that you had found the same
approach I've been trying to implement over the past few days in gcl
for loading, relocating, and executing objects at runtime in Lisp.  

Problem is, it only seems to work in x86 :-(, at least as far as I can
tell.  Kind of defeats the purpose of using bfd for portability :-).
I've gone through the mips case in detail, and one cannot even call
this routine unless one sets the relocateable argument to true, as it
will result in trying to call _bfd_get_gp_value with a null
argument.  Likewise on ppc, the relocation apparently succeeds, but
the source is not correctly relocated. I've noticed that ld doesn't
seem to actually use this routine, but rather uses a variety of
backend specific routines ...._relocate_section.  Arguments to this no
longer seem canonical, alas.

Just wanted to tap your experience.  Have you tested your gdb patch on
other archs?  Any work beside x86?  Is there another path through the
bfd labyrinth that would simply allow one to load a correctly relocated
section at an arbitrary address, after defining the symbols of course?

Any help most appreciated!

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]