From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29822 invoked by alias); 27 Jul 2002 07:06:44 -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 29814 invoked from network); 27 Jul 2002 07:06:43 -0000 Received: from unknown (HELO mta03ps.bigpond.com) (144.135.25.135) by sources.redhat.com with SMTP; 27 Jul 2002 07:06:43 -0000 Received: from bubble.local ([144.135.25.87]) by mta03ps.bigpond.com (Netscape Messaging Server 4.15 mta03ps May 23 2002 23:53:28) with SMTP id GZWBR400.DVL for ; Sat, 27 Jul 2002 17:06:40 +1000 Received: from CPE-144-136-176-14.sa.bigpond.net.au ([144.136.176.14]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0n 125/19656738); 27 Jul 2002 17:06:40 Received: (qmail 29744 invoked by uid 179); 27 Jul 2002 07:06:39 -0000 Date: Sat, 27 Jul 2002 09:08:00 -0000 From: Alan Modra To: Camm Maguire Cc: Daniel Jacobowitz , Paul Koning , binutils@sources.redhat.com, gcl-devel@gnu.org Subject: Re: [Gcl-devel] Re: BFD relocations Message-ID: <20020727070639.GS26054@bubble.sa.bigpond.net.au> Mail-Followup-To: Camm Maguire , Daniel Jacobowitz , Paul Koning , binutils@sources.redhat.com, gcl-devel@gnu.org References: <20020604223014.GA7579@nevyn.them.org> <547kldpbu0.fsf@intech19.enhanced.com> <20020605230537.GA4336@nevyn.them.org> <54g001xnnf.fsf@intech19.enhanced.com> <20020606010956.GA7291@nevyn.them.org> <547klbixuk.fsf@intech19.enhanced.com> <15616.47945.929255.781190@pkoning.dev.equallogic.com> <54elfeu5ih.fsf@intech19.enhanced.com> <20020610230608.GA15617@nevyn.them.org> <54ofctahrb.fsf@intech19.enhanced.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54ofctahrb.fsf@intech19.enhanced.com> User-Agent: Mutt/1.3.25i X-SW-Source: 2002-07/txt/msg00715.txt.bz2 On Sat, Jul 27, 2002 at 12:59:04AM -0400, Camm Maguire wrote: > Greetings! > > When called to retrieve non-relocatable output (i.e. with the > output_bfd parameter set to 0), bfd_get_relocated_section_contents > works on the following platforms: > > elf: i386 ppc s390 m68k arm sparc > > The following platforms fail: > > elf: mips alpha ia64 hppa > coff: i386 > > 1) Is it intended to support this routine on all platforms eventually? What itch will it scratch? > 2) Are patches enabling this function likely to be accepted rather > easily, or are they likely to break other currently used > routines? Implementing this function likely won't break anything. > 3) Are there recommended guidelines for such patches? I.e. relatively > safe places for modifications? You'll likely need to implement missing special_function entries for reloc howto structures. It may work out easier in some cases to implement a new get_relocated_section_contents function rather than trying to use bfd_generic_get_relocated_section_contents. -- Alan Modra IBM OzLabs - Linux Technology Centre