From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25515 invoked by alias); 7 Mar 2012 14:26:52 -0000 Received: (qmail 25328 invoked by uid 22791); 7 Mar 2012 14:26:49 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from dns0.mips.com (HELO dns0.mips.com) (12.201.5.70) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Mar 2012 14:26:36 +0000 Received: from exchdb01.mips.com (exchhub01.mips.com [192.168.36.84]) by dns0.mips.com (8.13.8/8.13.8) with ESMTP id q27EQUlC011840; Wed, 7 Mar 2012 06:26:30 -0800 Received: from EXCHDB03.MIPS.com ([fe80::6df1:ae84:797e:9076]) by exchhub01.mips.com ([::1]) with mapi id 14.01.0270.001; Wed, 7 Mar 2012 06:26:29 -0800 From: "Simeonov, Aleksandar (c)" To: Ian Lance Taylor CC: "Fuhler, Rich" , "mips-compiler@rt-rk.com" , "binutils@sourceware.org" Subject: RE: Initial MIPS patch for GOLD - version 3 Date: Wed, 07 Mar 2012 14:26:00 -0000 Message-ID: References: In-Reply-To: x-ems-proccessed: 6LP3oGfGVdcdb8o1aBnt6w== x-ems-stamp: qVuZvUNxpQioor30o5GsPQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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/msg00070.txt.bz2 Hi Ian, Do you have any comments on proposals from my previous mail? Are there any other comments about patch or you think it is ready for trunk? Thanks in advance for your answers, Aleksandar ________________________________________ 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() =3D=3D 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 =3D=3D 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 >