From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10916 invoked by alias); 20 Sep 2004 23:14:05 -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 10904 invoked from network); 20 Sep 2004 23:14:03 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 20 Sep 2004 23:14:03 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8KNE3B2011026 for ; Mon, 20 Sep 2004 19:14:03 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8KNDqr16786; Mon, 20 Sep 2004 19:13:58 -0400 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0258328D2; Mon, 20 Sep 2004 19:11:31 -0400 (EDT) Message-ID: <414F63A3.2050009@redhat.com> Date: Mon, 20 Sep 2004 23:14:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: Ian Lance Taylor Cc: binutils@sources.redhat.com Subject: Re: [rfa] Add bfd_runtime References: <40E1FF7A.10405@redhat.com> <40E2CB85.2030607@redhat.com> <40EAAF53.8070001@redhat.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00209.txt.bz2 [back to this thread, sorry] > 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. In terms of the relationships between various so called "format"s, I view things along the lines of: objfile is-a object is-a bfd runtime is-a object is-a bfd corefile is-a object is-a bfd yet: bfd_archive is-a bfd bfd_archive has-a 1:N so BFD's currrent structure doesn't show real consistency :-/ (Relationships such as bfd_core is-a bfd_runtime don't hold.) When it comes to how it should fit in, I think it can be viewed as: elf-target has-a runtime-object elf-target has-a corefile-object elf-target has-a objfile-object and: elf32-i386 is-a elf-target Hence, I think runtime fits better into the "format" vector as that makes that relationship possible. Yes, it is also possible to brute-force this using "elfmem32-i386" et.al. targets. Andrew > >>>>>>>> >>>> > 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