From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3056 invoked by alias); 31 Jan 2005 16:11:14 -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 27139 invoked from network); 31 Jan 2005 16:07:17 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 31 Jan 2005 16:07:17 -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.11) with ESMTP id j0VG7HT1008103 for ; Mon, 31 Jan 2005 11:07:17 -0500 Received: from talisman.cambridge.redhat.com (talisman.cambridge.redhat.com [172.16.18.81]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0VG7AO01783; Mon, 31 Jan 2005 11:07:10 -0500 Received: from talisman.cambridge.redhat.com (localhost.localdomain [127.0.0.1]) by talisman.cambridge.redhat.com (8.13.1/8.12.10) with ESMTP id j0VG73wK030790; Mon, 31 Jan 2005 16:07:03 GMT Received: (from rsandifo@localhost) by talisman.cambridge.redhat.com (8.13.1/8.12.10/Submit) id j0VG6uWM030789; Mon, 31 Jan 2005 16:06:56 GMT X-Authentication-Warning: talisman.cambridge.redhat.com: rsandifo set sender to rsandifo@redhat.com using -f To: Thiemo Seufer Cc: Ben Elliston , binutils@sources.redhat.com Subject: Re: bfd cleanups References: <20050131052731.GA16841@namadgi> <20050131151244.GG15265@rembrandt.csv.ica.uni-stuttgart.de> From: Richard Sandiford Date: Mon, 31 Jan 2005 16:11:00 -0000 In-Reply-To: <20050131151244.GG15265@rembrandt.csv.ica.uni-stuttgart.de> (Thiemo Seufer's message of "Mon, 31 Jan 2005 16:12:44 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-01/txt/msg00551.txt.bz2 Thiemo Seufer writes: >> @@ -8187,47 +8092,6 @@ _bfd_mips_elf_final_link (bfd *abfd, str >> - g->global_gotsym->dynindx) >> <= g->global_gotno); >> } >> - >> -#if 0 >> - /* We want to set the GP value for ld -r. */ >> - /* On IRIX5, we omit the .options section. On IRIX6, however, we >> - include it, even though we don't process it quite right. (Some >> - entries are supposed to be merged.) Empirically, we seem to be >> - better off including it then not. */ >> - if (IRIX_COMPAT (abfd) == ict_irix5 || IRIX_COMPAT (abfd) == ict_none) >> - for (secpp = &abfd->sections; *secpp != NULL; secpp = &(*secpp)->next) >> - { >> - if (strcmp ((*secpp)->name, MIPS_ELF_OPTIONS_SECTION_NAME (abfd)) == 0) >> - { >> - for (p = (*secpp)->link_order_head; p != NULL; p = p->next) >> - if (p->type == bfd_indirect_link_order) >> - p->u.indirect.section->flags &= ~SEC_HAS_CONTENTS; >> - (*secpp)->link_order_head = NULL; >> - bfd_section_list_remove (abfd, secpp); >> - --abfd->section_count; >> - >> - break; >> - } >> - } >> - >> - /* We include .MIPS.options, even though we don't process it quite right. >> - (Some entries are supposed to be merged.) At IRIX6 empirically we seem >> - to be better off including it than not. */ >> - for (secpp = &abfd->sections; *secpp != NULL; secpp = &(*secpp)->next) >> - { >> - if (strcmp ((*secpp)->name, ".MIPS.options") == 0) >> - { >> - for (p = (*secpp)->link_order_head; p != NULL; p = p->next) >> - if (p->type == bfd_indirect_link_order) >> - p->u.indirect.section->flags &=~ SEC_HAS_CONTENTS; >> - (*secpp)->link_order_head = NULL; >> - bfd_section_list_remove (abfd, secpp); >> - --abfd->section_count; >> - >> - break; >> - } >> - } >> -#endif > > 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. Richard