This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: BFD relocations -- alpha
- From: Camm Maguire <camm at enhanced dot com>
- To: Alan Modra <amodra at bigpond dot net dot au>
- Cc: Daniel Jacobowitz <drow at mvista dot com>, Paul Koning <pkoning at equallogic dot com>, binutils at sources dot redhat dot com, gcl-devel at gnu dot org, debian-alpha at lists dot debian dot org
- Date: 11 Aug 2002 12:26:25 -0400
- Subject: Re: BFD relocations -- alpha
- References: <20020605230537.GA4336@nevyn.them.org> <54g001xnnf.fsf@intech19.enhanced.com> <20020606010956.GA7291@nevyn.them.org> <547klbixuk.fsf@intech19.enhanced.com> <15616.47945.929255.781190@pkoning.dev.equallogic.com> <54elfeu5ih.fsf@intech19.enhanced.com> <20020610230608.GA15617@nevyn.them.org> <54ofctahrb.fsf@intech19.enhanced.com> <20020727070639.GS26054@bubble.sa.bigpond.net.au> <54wurh5f36.fsf@intech19.enhanced.com> <20020730071500.GK26054@bubble.sa.bigpond.net.au>
Greetings! OK, I'm starting to work on this a bit, first with the
alpha. I have a hunch that all I need to do is call _bfd_set_gp_value
on the input bfd with the destination address of the .text section or
some such, and then bfd_get_relocated_section_contents should work.
I would be most grateful if anyone knows ahead of time what this gp
value should be. It will save me considerable time reading the
sources.
Take care,
Alan Modra <amodra@bigpond.net.au> writes:
> On Sat, Jul 27, 2002 at 12:07:57PM -0400, Camm Maguire wrote:
> > > > 3) Are there recommended guidelines for such patches? I.e. relatively
> > > > safe places for modifications?
> > >
> > > You'll likely need to implement missing special_function entries for
> > > reloc howto structures. It may work out easier in some cases to
> > > implement a new get_relocated_section_contents function rather than
> > > trying to use bfd_generic_get_relocated_section_contents.
> > >
> >
> > OK. A standalone get_relocated_section_contents function per arch
> > seems the way to go. I was contemplating modifying the lower level
> > functions on the order of mips_elf_hi16_reloc, etc., but this does
> > seem more dangerous.
>
> If you can do so, use the lower level functions. The per-arch
> get_relocated_section_contents is really for weird cases. Hmm, like
> mips. If you can get mips working properly, any other target will be
> a breeze.
>
> > The way I'd go about this is to follow what ld does in a debugger. Is
> > there a better source of information somewhere?
>
> Some of the ELF processor supplements are available on the web.
> They will help in figuring out how vairous relocations should be
> handled.
>
> > Also, is there a reason why some arches currently work and others
> > don't? I.e., is it just oversight thus far due to the fact that no
> > one uses the get_relocated_section_contents, or are there arch
> > specific difficulties which make such a function hard on certain
> > platforms, e.g. the gp_disp, etc.?
>
> Well, ELF RELA targets generally don't need those special_function
> handlers in order to have a working assembler, and the linker
> relocate_section function is often not any easier to write using
> bfd_perform_relocation. One of the problems is that the howto
> functions weren't designed for relocs that depend on the value of
> other relocs, or on extraneous data like segment base addresses.
> gp relative relocs are easy enough as the gp base is stashed away
> in the bfd.
>
> --
> Alan Modra
> IBM OzLabs - Linux Technology Centre
>
> _______________________________________________
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah