> -----Original Message-----
> From: Richard Henderson [mailto:r...@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.
>
