From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23083 invoked by alias); 8 Oct 2004 02:04:14 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 23057 invoked from network); 8 Oct 2004 02:04:12 -0000 Received: from unknown (HELO outbound0.sv.meer.net) (205.217.152.13) by sourceware.org with SMTP; 8 Oct 2004 02:04:12 -0000 Received: from yosemite.airs.com (yosemite.airs.com [209.128.65.135]) by outbound0.sv.meer.net (8.12.10/8.12.6) with SMTP id i9823fvr091898 for ; Thu, 7 Oct 2004 19:03:41 -0700 (PDT) (envelope-from ian@airs.com) Received: (qmail 13959 invoked by uid 10); 8 Oct 2004 02:03:40 -0000 Received: (qmail 11091 invoked by uid 500); 8 Oct 2004 02:03:15 -0000 Mail-Followup-To: binutils@sources.redhat.com, cagney@gnu.org From: Ian Lance Taylor To: Andrew Cagney Cc: binutils@sources.redhat.com Subject: Re: [rfa] Add bfd_runtime References: <40E1FF7A.10405@redhat.com> <40E2CB85.2030607@redhat.com> <40EAAF53.8070001@redhat.com> <414F63A3.2050009@redhat.com> <41647E0E.2010409@gnu.org> <416594EE.70605@gnu.org> Date: Fri, 08 Oct 2004 02:04:00 -0000 In-Reply-To: <416594EE.70605@gnu.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-10/txt/msg00101.txt.bz2 Andrew Cagney 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