From: Camm Maguire <camm@enhanced.com>
To: Alan Modra <amodra@bigpond.net.au>
Cc: Daniel Jacobowitz <drow@mvista.com>,
Paul Koning <pkoning@equallogic.com>,
binutils@sources.redhat.com, gcl-devel@gnu.org,
debian-alpha@lists.debian.org
Subject: Re: BFD relocations -- alpha
Date: Sun, 11 Aug 2002 09:26:00 -0000 [thread overview]
Message-ID: <54znvticpa.fsf_-_@intech19.enhanced.com> (raw)
In-Reply-To: Alan Modra's message of "Tue, 30 Jul 2002 16:45:00 +0930"
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
next prev parent reply other threads:[~2002-08-11 16:26 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-02 20:42 BFD relocations Camm Maguire
2002-06-02 22:06 ` Daniel Jacobowitz
2002-06-03 15:08 ` Camm Maguire
2002-06-03 15:29 ` Daniel Jacobowitz
2002-06-04 14:34 ` [Gcl-devel] " Camm Maguire
2002-06-04 14:42 ` Geoff Keating
2002-06-04 14:44 ` Daniel Jacobowitz
2002-06-04 15:06 ` Camm Maguire
2002-06-04 15:33 ` Daniel Jacobowitz
2002-06-05 16:03 ` Camm Maguire
2002-06-05 16:09 ` Daniel Jacobowitz
2002-06-05 17:21 ` Camm Maguire
2002-06-05 18:13 ` Daniel Jacobowitz
2002-06-06 20:14 ` Camm Maguire
2002-06-06 21:00 ` Daniel Jacobowitz
2002-06-06 22:03 ` Jason R Thorpe
2002-06-07 6:55 ` Paul Koning
2002-06-10 15:35 ` Camm Maguire
2002-06-10 16:10 ` Daniel Jacobowitz
2002-06-14 8:51 ` Flushing the d-cache (was Re: BFD relocations) Camm Maguire
2002-06-14 9:16 ` Philip Blundell
2002-06-14 12:22 ` [Gcl-devel] " Camm Maguire
2002-06-14 12:34 ` Philip Blundell
2002-06-14 13:10 ` Andreas Schwab
2002-06-17 15:37 ` Richard Zidlicky
2002-06-17 20:09 ` [Gcl-devel] " Camm Maguire
2002-06-19 11:25 ` MIPS bfd_get_relocated_section_contents broken Camm Maguire
2002-07-27 0:06 ` [Gcl-devel] Re: BFD relocations Camm Maguire
2002-07-27 9:08 ` Alan Modra
2002-07-27 12:23 ` Camm Maguire
2002-07-30 0:46 ` Alan Modra
2002-08-11 9:26 ` Camm Maguire [this message]
2002-06-05 20:09 ` Geoff Keating
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54znvticpa.fsf_-_@intech19.enhanced.com \
--to=camm@enhanced.com \
--cc=amodra@bigpond.net.au \
--cc=binutils@sources.redhat.com \
--cc=debian-alpha@lists.debian.org \
--cc=drow@mvista.com \
--cc=gcl-devel@gnu.org \
--cc=pkoning@equallogic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).