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