RE: [RFA] Compact EH Patch

["Moore, Catherine" <Catherine_Moore at mentor dot 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.
>