From: "Moore, Catherine" <Catherine_Moore@mentor.com>
To: Richard Henderson <rth@redhat.com>,
Jason Merrill <jason@redhat.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: Matthew Fortune <Matthew.Fortune@imgtec.com>,
Ian Lance Taylor <iant@google.com>,
"Sidwell, Nathan" <Nathan_Sidwell@mentor.com>
Subject: RE: [RFA] Compact EH Patch
Date: Mon, 14 Sep 2015 19:32:00 -0000 [thread overview]
Message-ID: <FD3DCEAC5B03E9408544A1E416F112420192C9CE2C@NA-MBX-04.mgc.mentorg.com> (raw)
In-Reply-To: <55F0C4D5.6080507@redhat.com>
> -----Original Message-----
> From: Richard Henderson [mailto:rth@redhat.com]
> Sent: Wednesday, September 09, 2015 7:46 PM
> To: Jason Merrill; Moore, Catherine; gcc-patches@gcc.gnu.org
> Cc: Matthew Fortune; Ian Lance Taylor
> Subject: Re: [RFA] Compact EH Patch
>
> On 09/09/2015 01:35 PM, Jason Merrill wrote:
> > On 07/30/2015 04:14 PM, Moore, Catherine wrote:
> >> This patch implements a more compact format for exception handling
> data.
> >> Although I don't have recent numbers for the amount of compression
> >> achieved, an earlier measurement showed a 30% reduction in the size
> >> of EH data for
> >> libstdc++.
> >>
> >> A design document detailing the new format is available
> >> (https://github.com/MentorEmbedded/cxx-
> abi/blob/master/MIPSCompactEH.pdf).
> >>
> >> This implementation enables the new format for MIPS targets only, but
> >> the generic pieces to enable the new format for other architectures is in
> place.
> >
> > Hi, sorry for the slow response.
> >
> > I'm surprised that there was no mention of this design on the ABI
> > list, especially since you've decided to post the design document to its git
> repository.
> >
> > I'm skeptical about the explicit rejection of asynchronous
> > backtracing; this is an important capability for debug traces on
> > hosted systems, which is why the compiler flag is on by default in
> > many linux distributions. The document mentions using libunwind
> > instead, but that wouldn't help, as libunwind relies on the same
> > unwind information. So it seems to me that the objective in 1.2 of
> supporting both unhosted and Linux-hosted programs isn't sufficiently met.
The support of asynchronous unwinding was not a requirement for our customer and wasn't addressed in the design.
As Richard points out, it is certainly possible to extend the scheme to support it, although I don't think such support should be a requirement for acceptance of the patch.
>
> Indeed. Though that is certainly fixable.
>
> Let us suppose for the moment that the note on page 17 becomes true --
> use some of the currently unused encoding space for push/pop of state, and
> advancing the pc, so that one can represent asynchronous data.
>
> At that point what's present there in section 10.1 looks plausible for use on
> MIPS. With appropriate scheduling barriers in the mips prologue, it would in
> all likelyhood only add a single byte to the unwind info.
>
> For instance, suppose
>
> 0101 1011 akin to DW_CFA_remember_state
> 0101 1111 akin to DW_CFA_restore_state
> 0111 0000 uleb128 akin to DW_CFA_advance_loc, of uleb128 * CALIGN
> 0111 xxxx akin to DW_CFA_advance_loc, of xxxx * CALIGN
>
> where CALIGN is 4 for mips32 and 2 for mips16/micromips. This allows one to
> advance 15 insns with 1 byte, and 127 insns with 2 bytes.
>
> For the first example in 10.2.1 is instructive, in that it would take 5 bytes to
> encode: pc += 1*4, sp += 56, pc += 8*4, push {16-22,31}, finish. Given that
> most functions that allocate a stack frame will do so in the first insn, and
> indeed cannot do anything useful in zero instructions, one could make that
> first pc adjustment implicit, reducing the size of the unwind to 4 bytes, which
> does fit into your inline unwind info.
>
> Anyway, the exact encodings of this are something for the mips maintainers,
> since it isn't applicable generically.
>
> Of more interest to me is the rest of the proposal, particularly section 10.4.
> I like that there's more locality to the unwind data than the current
> .gcc_except_table contents. I like that there's less pointer chasing.
>
> Looking at the contents of my desktop, the vast majority of binaries have no
> .gcc_except_table, or a trivially small amount. But I do have 102 binaries with
> a table larger than 64k, with a maximum size of 705k. So I also like the
> potential size savings of 25-40%.
>
> The spec in section 10.4 looks good. I can't see any issues with it off-hand.
>
> The spec in section 8.2 out to be extended to handle 64-bit offsets instead of
> 32-bit offsets, even if only by reserving version 3 for the purpose. While
> MIPS may want to restrict the size of the elf object to 2GB, and that's the
> common case for most files on all systems, we cannot restrict the size on all
> systems.
>
> Anyway, that's having read the referenced document only, and nothing yet
> of the code. I'll try to get to that tomorrow.
>
next prev parent reply other threads:[~2015-09-14 19:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 21:07 Moore, Catherine
2015-08-14 19:58 ` Moore, Catherine
2015-09-09 20:45 ` Jason Merrill
2015-09-09 23:53 ` Richard Henderson
2015-09-14 19:32 ` Moore, Catherine [this message]
2015-09-18 19:34 ` Richard Henderson
2015-10-05 23:14 ` Moore, Catherine
2015-10-06 16:12 ` Richard Henderson
2015-11-25 17:13 ` Moore, Catherine
2015-12-01 21:32 ` Moore, Catherine
2015-12-01 21:33 ` Jason Merrill
2015-12-02 13:39 ` Jonathan Wakely
2015-12-13 22:12 ` Moore, Catherine
2015-10-28 16:44 ` 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=FD3DCEAC5B03E9408544A1E416F112420192C9CE2C@NA-MBX-04.mgc.mentorg.com \
--to=catherine_moore@mentor.com \
--cc=Matthew.Fortune@imgtec.com \
--cc=Nathan_Sidwell@mentor.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=iant@google.com \
--cc=jason@redhat.com \
--cc=rth@redhat.com \
/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).