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: Andrew Cagney <cagney at gnu dot org>
- Cc: binutils at sources dot redhat dot com
- Date: 07 Oct 2004 22:03:15 -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><416594EE.70605@gnu.org>
Andrew Cagney <cagney@gnu.org> writes:
> But what of this:
>
> > For runtime, bfd_map_over_sections needs to do something different again create a list of sections using offset information obtained from the segment table.
> > That can either be done in two stages; reverse map in-memory
> > segments to on-disk image, open pseudo on-disk image as an object
> > file; or a single direct stage where the "sections" describe the in
> > memory offsets.
> > The latter, which I think is an operation unlike any of the above,
> > is what I'm trying to implement.
>
> Do you concure that the operation is unlike any of the above?
In terms of how the information is obtained, sure. In terms of how
the information is used, no.
> > 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.
>
> How? Without adding to BFD's existing macro #include hell? This is
> needed for all elf object formats.
You can use the pre-existing #include hell; you just need to add a
bfd_target at the end of elfxx-target.h.
Ian