[Top][All Lists]
[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
- [Gcl-devel] Re: BFD relocations, Camm Maguire, 2002/06/03
- [Gcl-devel] Re: BFD relocations,
Daniel Jacobowitz <=
- Re: [Gcl-devel] Re: BFD relocations, Camm Maguire, 2002/06/04
- Re: [Gcl-devel] Re: BFD relocations, Geoff Keating, 2002/06/04
- Re: [Gcl-devel] Re: BFD relocations, Daniel Jacobowitz, 2002/06/04
- Re: [Gcl-devel] Re: BFD relocations, Camm Maguire, 2002/06/04
- Re: [Gcl-devel] Re: BFD relocations, Daniel Jacobowitz, 2002/06/04
- Re: [Gcl-devel] Re: BFD relocations, Camm Maguire, 2002/06/05
- Re: [Gcl-devel] Re: BFD relocations, Daniel Jacobowitz, 2002/06/05
- Re: [Gcl-devel] Re: BFD relocations, Camm Maguire, 2002/06/05
- Re: [Gcl-devel] Re: BFD relocations, Daniel Jacobowitz, 2002/06/05
- Re: [Gcl-devel] Re: BFD relocations, Camm Maguire, 2002/06/06