From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4562 invoked by alias); 6 Mar 2014 22:18:39 -0000 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 Received: (qmail 4551 invoked by uid 89); 6 Mar 2014 22:18:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f52.google.com Received: from mail-wg0-f52.google.com (HELO mail-wg0-f52.google.com) (74.125.82.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 06 Mar 2014 22:18:37 +0000 Received: by mail-wg0-f52.google.com with SMTP id k14so4008579wgh.11 for ; Thu, 06 Mar 2014 14:18:34 -0800 (PST) X-Received: by 10.194.2.168 with SMTP id 8mr13987971wjv.8.1394144314578; Thu, 06 Mar 2014 14:18:34 -0800 (PST) Received: from localhost ([2.28.235.12]) by mx.google.com with ESMTPSA id xt1sm23813532wjb.17.2014.03.06.14.18.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Mar 2014 14:18:33 -0800 (PST) From: Richard Sandiford To: "Moore\, Catherine" Mail-Followup-To: "Moore\, Catherine" ,"binutils\@sourceware.org" , rdsandiford@googlemail.com Cc: "binutils\@sourceware.org" Subject: Re: [Patch] Gas support for MIPS Compact EH References: <87k3me9jia.fsf@talisman.default> <8738jt5zt1.fsf@talisman.default> Date: Thu, 06 Mar 2014 22:18:00 -0000 In-Reply-To: (Catherine Moore's message of "Thu, 6 Mar 2014 17:44:14 +0000") Message-ID: <874n3bezt7.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-03/txt/msg00058.txt.bz2 "Moore, Catherine" writes: > Hi Richard, > >> -----Original Message----- >> From: Richard Sandiford [mailto:rdsandiford@googlemail.com] >> >> > "Moore, Catherine" writes: >> > @@ -1433,6 +1441,7 @@ struct bfd_elf_section_data >> >> > +/* Add a .eh_frame_entry section. */ >> > + >> > +static void >> > +bfd_elf_remember_eh_frame_entry (struct eh_frame_hdr_info >> *hdr_info, >> > + asection *sec) >> > +{ >> > + if (hdr_info->array_count == hdr_info->allocated_entries) >> > + { >> > + if (hdr_info->allocated_entries == 0) >> > + { >> > + hdr_info->allocated_entries = 2; >> > + hdr_info->entries = bfd_malloc (hdr_info->allocated_entries >> > + * sizeof(hdr_info->entries[0])); >> > + } >> > + else >> > + { >> > + hdr_info->allocated_entries *= 2; >> > + hdr_info->entries = bfd_realloc (hdr_info->entries, >> > + hdr_info->allocated_entries * sizeof(hdr_info->entries[0])); >> >> Space before "sizeof" (both times). >> >> > + } >> > + >> > + BFD_ASSERT (hdr_info->entries); >> > + } >> > + >> > + hdr_info->entries[hdr_info->array_count++] = sec; } >> > + >> > +/* Parse a .eh_frame_entry section. Figure out which text section it >> > + references. */ >> > + >> > +void >> > +_bfd_elf_parse_eh_frame_entry (bfd *abfd, struct bfd_link_info *info, >> > + asection *sec, struct elf_reloc_cookie *cookie, >> > + bfd_boolean remember) >> >> This does more than the comment says and the name implies; the >> REMEMBER stuff isn't mentioned. >> >> The patch tries to do the parsing during bfd_elf_discard_info, but since the >> parsing wants to be able to fail with an error, I think we need to do it in an >> earlier pass. We can then return a bfd_boolean success code and propagate >> error returns up, which the current patch doesn't do. >> Ideally we'd put the pass somewhere before GC, so that both the GC and >> bfd_elf_discard_info stages can assume parsed .eh_frame_entry sections. >> > It looks like the legacy dwarf code parse .eh_frame sections during both > GC and bfd_elf_discard_info. Right. But that parsing is allowed to fail, in which case we just concatenate the input .eh_frames together as normal. The parsing for the compact scheme can't fail since the linker needs to understand the incoming .eh_frame_entry sections in order to sort them correctly. > There is some shared code between the legacy and compact parsing and it > feels awkward to keep legacy eh frame parsing as is and move compact eh > frame parsing to an earlier pass. I think it's OK. The schemes really are significantly different in terms of what the linker has to do. > I could post a patch that moves legacy parsing to an earlier pass to > address this. Do you think that's reasonable? > The other option is to remove the compact eh_frame_entry parsing only > (as you suggested). WDYT? Yeah, I think we should leave the current EH scheme as it is now and only parse .eh_frame_entry sections in advance, so that the data structures are already available at GC and bfd_elf_discard_info time. Thanks, Richard