From: Richard Sandiford <rdsandiford@googlemail.com>
To: "Moore\, Catherine" <Catherine_Moore@mentor.com>
Cc: "binutils\@sourceware.org" <binutils@sourceware.org>
Subject: Re: [Patch] Gas support for MIPS Compact EH
Date: Thu, 06 Mar 2014 22:18:00 -0000 [thread overview]
Message-ID: <874n3bezt7.fsf@talisman.default> (raw)
In-Reply-To: <FD3DCEAC5B03E9408544A1E416F1124201497E00EC@NA-MBX-04.mgc.mentorg.com> (Catherine Moore's message of "Thu, 6 Mar 2014 17:44:14 +0000")
"Moore, Catherine" <Catherine_Moore@mentor.com> writes:
> Hi Richard,
>
>> -----Original Message-----
>> From: Richard Sandiford [mailto:rdsandiford@googlemail.com]
>>
>> > "Moore, Catherine" <Catherine_Moore@mentor.com> 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
next prev parent reply other threads:[~2014-03-06 22:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-31 18:56 Moore, Catherine
2013-06-01 11:07 ` Richard Sandiford
2014-02-04 21:56 ` Moore, Catherine
2014-02-05 22:38 ` Maciej W. Rozycki
2014-02-08 16:34 ` Richard Sandiford
2014-02-08 18:48 ` Bernd Schmidt
2014-02-09 11:11 ` Richard Sandiford
2014-02-19 23:13 ` Moore, Catherine
2014-02-20 11:36 ` Richard Sandiford
2014-02-20 21:24 ` Moore, Catherine
2014-02-20 22:39 ` Richard Sandiford
2014-02-24 20:54 ` Moore, Catherine
2014-02-24 20:48 ` Moore, Catherine
2014-02-25 8:29 ` Richard Sandiford
2014-03-17 13:22 ` Moore, Catherine
2014-03-17 13:52 ` Richard Sandiford
2014-03-19 21:12 ` Moore, Catherine
2014-03-19 23:45 ` Richard Sandiford
2014-03-20 14:29 ` Moore, Catherine
2014-03-20 21:19 ` Richard Sandiford
2014-03-06 17:44 ` Moore, Catherine
2014-03-06 22:18 ` Richard Sandiford [this message]
2014-03-25 13:50 ` Moore, Catherine
2014-03-25 14:06 ` Richard Sandiford
2014-11-17 16:10 ` Moore, Catherine
2014-11-22 14:42 ` Richard Sandiford
2015-02-08 16:59 ` Moore, Catherine
2015-02-08 17:00 ` Moore, Catherine
2015-04-16 13:28 ` Moore, Catherine
2015-05-01 13:54 ` FW: " Moore, Catherine
2015-05-05 10:04 ` Matthew Fortune
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874n3bezt7.fsf@talisman.default \
--to=rdsandiford@googlemail.com \
--cc=Catherine_Moore@mentor.com \
--cc=binutils@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).