gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: BFD relocations


From: Daniel Jacobowitz
Subject: [Gcl-devel] Re: BFD relocations
Date: Mon, 3 Jun 2002 18:29:17 -0400
User-agent: Mutt/1.3.28i

On Mon, Jun 03, 2002 at 06:08:03PM -0400, Camm Maguire wrote:
> 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?

No.  It was only for resolving symbols in debug information.

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

Yep.

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

Not PowerPC; Alpha does, and PPC64 I think.

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

Should suffice for simple relocation, yes.

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



reply via email to

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