public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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

  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).