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.
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.
r~
