<sb0>
whitequark, libunwind is taking care of this horrendous DWARF mess, right?
<sb0>
it almost looks as bad as ACPI
<sb0>
and what do we do if this piece of shit has bugs? back to the current system and ad-hoc stack traces?
nickjohnson has left #m-labs [#m-labs]
<larsc>
fix the bugs
aeris has quit [Quit: en a pas]
aeris has joined #m-labs
ylamarre has joined #m-labs
<whitequark>
sb0: yes, libunwind is taking care of it
<whitequark>
I wouldn't really call it shit, it's a reasonable way to do it if you don't want to inhibit optimizations or slow down the hot path
<whitequark>
don't take my twitter rants literally. they're optimized for amusement value, not fair judgement :]
<whitequark>
sb0: one very convenient part I have discovered yesterday is that the way OR1K (and probably LM32) codegen works bypasses most of this
<whitequark>
it uses either sp, fp or bp-relative addressing, and only spills callee-saved regs, which means that it uses, like, three directives. .cfi_def_cfa_register, .cfi_def_cfa_offset, and .cfi_offset
<whitequark>
.cfi_def_* tell the unwinder where the frame begins, given the current state, and .cfi_offset tells it where the callee-saved register is spilled
<whitequark>
the part that *is* shitty is the language-specific data area, that basically states which pc values correspond to which exception landing pads
<whitequark>
which gcc originally invented for its own purposes, did not document, and did not use a sane format, and then clang/llvm took up for compatibility
<whitequark>
but fortunately, there is a very elaborate example in LLVM sources on how to parse that.
ylamarre has quit [Read error: Connection reset by peer]
ylamarre has joined #m-labs
<cr1901_modern>
Without having read the whole spec: It FEELS like the Itanium ABI for exception-handling was carefully design as a nice medium between speed an complexity. But perhaps a certain someone writing a Python-to-LLVM converter can refute that :P.
<whitequark>
no, it's not a medium
<whitequark>
it's designed to have absolutely no cost on the fast path
<whitequark>
which is actually completely fine. I mean, V8, TraceMonkey, Flash, Java, .NET have zero-cost fast path
<whitequark>
by employing more or less the same techniques as Itanium EHABI
<whitequark>
the complication here is that those VMs define EH on level of something like bytecode that mostly resembles their surface semantics
<whitequark>
and in fact many, like V8, don't optimize the functions with EH frames much
<whitequark>
and none of these want cleanup clauses (destructors)
<whitequark>
Itanium EHABI has to handle all that, and without adding any restrictions on the source language. so it is necessarily quite generic
<cr1901_modern>
(and none of these want cleanup clauses (destructors))- Could you elaborate (I'm guessing you mean that it's a bad idea to allocate objects in an EH block in these langs?)
<whitequark>
no, they just have a GC
<cr1901_modern>
Oh, I see. So there's no NEED for cleanup clauses XD- so why would you WANT them? (Sorry, I misread)
<whitequark>
ok, so or1k backend did not emit .cfi directives and was not able to even do it correctly because of broken fixup code
<whitequark>
i implemented all of that. yay, i guess