From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30831 invoked by alias); 7 Mar 2012 14:54:31 -0000 Received: (qmail 30822 invoked by uid 22791); 7 Mar 2012 14:54:30 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-iy0-f169.google.com (HELO mail-iy0-f169.google.com) (209.85.210.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Mar 2012 14:54:14 +0000 Received: by iajr24 with SMTP id r24so10603195iaj.0 for ; Wed, 07 Mar 2012 06:54:14 -0800 (PST) Received: by 10.50.154.169 with SMTP id vp9mr1947268igb.61.1331132053992; Wed, 07 Mar 2012 06:54:13 -0800 (PST) Received: by 10.50.154.169 with SMTP id vp9mr1947247igb.61.1331132053811; Wed, 07 Mar 2012 06:54:13 -0800 (PST) Received: from coign.google.com ([67.218.110.43]) by mx.google.com with ESMTPS id cx9sm17855267igc.12.2012.03.07.06.54.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Mar 2012 06:54:13 -0800 (PST) From: Ian Lance Taylor To: "Simeonov\, Aleksandar \(c\)" Cc: "Fuhler\, Rich" , "mips-compiler\@rt-rk.com" , "binutils\@sourceware.org" Subject: Re: Initial MIPS patch for GOLD - version 3 References: Date: Wed, 07 Mar 2012 14:54:00 -0000 In-Reply-To: (Aleksandar Simeonov's message of "Wed, 7 Mar 2012 14:26:28 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Gm-Message-State: ALoCoQleU2DpT+zPQoMB8Fi2/r7xDOie7dAFbsd0rOlCL3Umpo3OA6SdnyjVMNyZR/CN5cC4C8b2ecBF+bu1/MseE5w9jNpGJpIpc+h+EZJa2RtXp3mUwz5nACss6tDMGBA+kNM07F5lz2atEj/fansBzyx3cJl4BDHdA3zH6LbkBiAJnAX5M8k= X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00071.txt.bz2 "Simeonov, Aleksandar (c)" writes: > Do you have any comments on proposals from my previous mail? I'm not crazy about those proposals, because they in effect add highly specialized cases to the Target structure. One of the problems with the GNU linker is the function pointers in the elf_backend_data structure. Many of the function pointers are very specific and hard to understand and use correctly, which becomes an issue when the code changes. Unfortunately I have to some extent recreated that in gold's Target structure. I'm not sure what to do in this area. I've been postponing more serious consideration of your patch until the coypright issues are sorted out. Also I'm in the middle of overlapping release cycles and simply haven't had time to do any gold work. Sorry. Ian > ________________________________________ > From: Simeonov, Aleksandar (c) > Sent: Friday, February 03, 2012 4:40 PM > To: Ian Lance Taylor > Cc: Fuhler, Rich; mips-compiler@rt-rk.com; binutils@sourceware.org > Subject: Re: Initial MIPS patch for GOLD - version 3 > > Hi Ian, > I agree with you that processor specific stuff should be in CPU.cc. Because of that I would like to suggest following: > > - reloc.cc (Sized_relobj_file::write_sections) > > Instead of having direct compare of section types in code: > // For MIPS .reginfo section there is no need to do anything > if (shdr.get_sh_type() == elfcpp::SHT_MIPS_REGINFO) > continue; > > To have something like: > // Sections that need special handling (target specific) > if(parameters->target().section_needs_spec_handling(shdr.get_sh_type())) > continue; > > Where section_needs_spec_handling should be defined in Target as a virtual function that returns false by default and can be implemented as needed. > > > - layout.cc (Layout::segment_precedes) > > Instead of having function segment_precedes in Layout class, to move it to Target class. Make virtual default implementation as it was originally and allow different architectures to make their own implementation. > > Maybe some other proposals? > > Greetings, > Aleksandar > > On 28/01/2012 02:54, Ian Lance Taylor wrote: >> Aleksandar Simeonov writes: >> >>> * reloc.cc (Sized_relobj_file::write_sections): Special >>> handling of MIPS .reginfo section. >>> - .reginfo section is generated by linker and needs special handling. >> >> I haven't thought about everything, but I can see that this patch is not >> going to work as is. It will fail when linking a non-MIPS object which >> happens to have a section type == SHT_MIPS_REGINFO. We can't use >> processor-specific values like SHT_MIPS_REGINFO outside of the CPU.cc >> file. >> >>> * layout.cc (Layout::segment_precedes): Fixed order of MIPS specific >>> segments. >>> - MIPS needs to have PT_MIPS_REGINFO segment before any loadable segment. >> >> This is similarly troubling, though probably less serious. >> >>> - MIPS needs to have PT_NULL segment to be last in list of segments. >> >> Why would we ever have a PT_NULL segment? >> >> Ian >>