From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14945 invoked by alias); 13 Jul 2004 02:38:53 -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 14934 invoked from network); 13 Jul 2004 02:38:52 -0000 Received: from unknown (209.128.65.135) by sourceware.org with QMTP; 13 Jul 2004 02:38:52 -0000 Received: (qmail 31999 invoked by uid 10); 13 Jul 2004 02:38:52 -0000 Received: (qmail 14110 invoked by uid 500); 13 Jul 2004 02:38:44 -0000 Mail-Followup-To: binutils@sources.redhat.com, ac131313@redhat.com 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> Date: Tue, 13 Jul 2004 02:38:00 -0000 In-Reply-To: <40EAAF53.8070001@redhat.com> 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-07/txt/msg00164.txt.bz2 Andrew Cagney writes: > >>> The contents are organized differently. It's the in-memory runtime > >>> image so things are organized acccording to their load address and not > >>> their on-disk file offset. > > Sure. But it is still essentially an object-file/executable. At > > least, I thought that was the idea of the in-memory image: that it > > would look like an object-file/executable, it would have symbols and > > sections and segments, etc. > > It has symbols and sections and segments but is laid out very > differently. Things are accessed according to their in-memory rather > than on-disk offset. (however the current code doesn't do this, it > reverse engineers things back into what is kind of sort of an on disk > image). I understand that it is laid out differently. Since I don't think that is at all relevant, we are clearly failing to communicate. There are many different kinds of object files, ELF and otherwise. They are all laid out differently. They all have the same sorts of information. From BFD's perspective, anything with that sort of information is properly categorized as bfd_object. The information which you are describing has the sort of information which an object file has. From BFD's perspective, it seems to me that it should be bfd_object. If the layout is sufficiently different, then perhaps the problem is that is should use a different target vector--it should be "elfmem32-i386" rather than "elf32-i386". But I can not understand why a different layout would suggest not using bfd_object. Let me put it another way: can you explain what the difference is between bfd_object and bfd_runtime, in terms of the difference between bfd_object and bfd_archive and bfd_core. > >>>> > Thinking in terms of adding support for a new object file format to > >>>> > BFD, what would the entries for bfd_runtime be? How can you recognize > >>>> > a file as bfd_runtime rather than bfd_object? The concept of > >>>> > bfd_runtime seems to me to be orthogonal to the concept of bfd_format. > >> > >>> Do you need to differentiate between the two? > > I don't understand this question. > > Creating a new bfd is a two step process: > - open the raw file > - check the format creating a bfd from the raw file > The second step, using bfd_check_format, typically includes an > explicit format specifier. > > For this "runtime", the code needs to know that it is manipulating a > loaded, rather than on-disk image. Without that it won't know that > the load rather than file offsets need to be used. > > So given that the code needs to be explicitly told that it is a > runtime, why do you see the need to recognize a bfd_runtime rather > than bfd_object? I don't. My point was that even talking about the question doesn't make any sense. My implied conclusion was that bfd_runtime is not a proper format type. Ian