This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [rfa] Add bfd_runtime
- From: Ian Lance Taylor <ian at wasabisystems dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: binutils at sources dot redhat dot com, cagney at gnu dot org
- Date: 07 Oct 2004 11:52:59 -0400
- Subject: Re: [rfa] Add bfd_runtime
- References: <40E1FF7A.10405@redhat.com> <m3smcdajcg.fsf@gossamer.airs.com><40E2CB85.2030607@redhat.com> <m33c4d6rki.fsf@gossamer.airs.com><40EAAF53.8070001@redhat.com> <m3hdsc1vij.fsf@gossamer.airs.com><414F63A3.2050009@redhat.com> <m3acvkzbff.fsf@gossamer.airs.com><41647E0E.2010409@gnu.org> <m33c0rw1kc.fsf@gossamer.airs.com><20041007151520.GA16154@nevyn.them.org>
Daniel Jacobowitz <drow@false.org> writes:
> > > So how would you solve this problem? Given a memory access method and
> > > a starting offset, construct a bfd containing a list of sections
> > > constructed using both the segment and section information in the
> > > inferior?
> >
> > I would write a new BFD target vector; e.g., elf32-i386-runtime.
>
> Ugh, is that really necessary? It would mean architecture-specific
> code to support this generic ELF concept, and I don't see any useful
> hooks in the elf backend vector anyway...
I'm not arguing for architecture-specific code. The code should be
written in a generic way to support any architecture, and
elf32-i386-runtime would just be a modification of elf32-i386 which
called this new generic code to dig up the runtime information.
My argument is just that we should have a different target vector for
this type of thing. I'm basing this on Andrew's description of what
is needed, and on his arguments for introducing bfd_runtime as a
parallel to bfd_object, et. al.
Ian