From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7528 invoked by alias); 31 Jan 2005 16:38:24 -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 7010 invoked from network); 31 Jan 2005 16:38:13 -0000 Received: from unknown (HELO iris1.csv.ica.uni-stuttgart.de) (129.69.118.2) by sourceware.org with SMTP; 31 Jan 2005 16:38:13 -0000 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp id 1CveYy-0003Nt-00; Mon, 31 Jan 2005 17:38:08 +0100 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 1CveYy-0005Cj-00; Mon, 31 Jan 2005 17:38:08 +0100 Date: Mon, 31 Jan 2005 16:38:00 -0000 To: Richard Sandiford Cc: Ben Elliston , binutils@sources.redhat.com Subject: Re: bfd cleanups Message-ID: <20050131163808.GH15265@rembrandt.csv.ica.uni-stuttgart.de> References: <20050131052731.GA16841@namadgi> <20050131151244.GG15265@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: Thiemo Seufer X-SW-Source: 2005-01/txt/msg00555.txt.bz2 Richard Sandiford wrote: > Thiemo Seufer writes: > >> @@ -8187,47 +8092,6 @@ _bfd_mips_elf_final_link (bfd *abfd, str [snip] > > Richard, is this code obsolete for IRIX? > > Well, PT_MIPS_REGINFO is supposed to be mandatory in 32-bit objects > and DT_MIPS_OPTIONS is mandatory in NewABI objects, so I can see why > the status quo makes sense for IRIX. I certainly don't know of any > reason why we'd want to re-enable the code. > > The comment for the first hunk claims that we don't merge .reginfo > correctly, but I think we try to do that in _bfd_mips_elf_final_link, > so maybe it's simply out of date. I think that bit can probably go. > > On the other hand, I suppose the second hunk is one of those cases where > the #if 0'd code is acting as commentary. "We don't merge .MIPS.options > sections correctly, but it doesn't seem to matter, and we've decided to > keep the section anyway." (Note that the comment is saying what we > do now, not what would happen if we re-enable the code.) No opinion > either way on whether it's worth keeping. Well, then I'm in favour of removing that hunk. Thiemo