gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: BFD relocations


From: Camm Maguire
Subject: [Gcl-devel] Re: BFD relocations
Date: 03 Jun 2002 18:08:03 -0400

Greetings, and thanks for your reply!

Daniel Jacobowitz <address@hidden> writes:

> On Sun, Jun 02, 2002 at 11:42:37PM -0400, Camm Maguire wrote:
> > 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?
> 
> I used it on PPC, which is where it was originally targetted.  Worked
> fine.  I'm going to clean up parts of the GDB support for that and move

Wonderful!  Did you execute the relocated code in your test?

> them into BFD this week if I can find a cleaner way.  If you search the
> gdb-patches archive for (I believe) April, you can find the way I
> invoke this.

OK, I found the mail in April.  This is the most current, right?

> 
> As for the GP bits, MIPS may need an additional hack.  BFD is not layed

But doesn't ppc, alpha,others? use a gp register too?

> out to do what we are doing; I had to fake a great number of callbacks.

Indeed.  But the callbacks would be needed in any routine of this
nature, I'd think.  You really do want access to individual relocation
errors, and such a routine will loop ever them in processing the
section.   What it seems is unnecessary is the hash table.  Mips
needed it, so I implemented it as you did.  x86 does not care.

> Be sure to have output sections and output VMAs for every section set.
> 

I also did as you did:

s->output_section=s;
s->vma=my_target_memory_address

Need I actually create an output_section, or should this suffice?

Take care,

> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 

-- 
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]