sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<sb0> whitequark, what binding feature do you need and is not there?
<whitequark> landingpad, invoke, blockaddress, indirectbr
<whitequark> well, i have already implemented all of them
<whitequark> and.... also implemented all the EH bits in ARTIQ. what's left is the ARTIQ personality function.
<sb0> what about putting a patch in artiq/misc? there are a few already
<whitequark> then i'll just keep it in whitequark/llvmlite for the time being
<sb0> and upstream answered me in a few days last time
<GitHub22> [artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vYRdv
<GitHub22> artiq/new-py2llvm c581af2 whitequark: Merge remote-tracking branch 'origin/master' into new-py2llvm
<GitHub22> artiq/new-py2llvm ece5206 whitequark: Implement code generation for exception handling.
<GitHub115> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vY0ez
<GitHub115> artiq/new-py2llvm 692791f whitequark: Make sure a landing pad returns {i8*} to soothe LLVM codegen.
<whitequark> ok, now I find the resulting assembly (x86_64 so far) adequate
<whitequark> let's write the personality fn
<GitHub161> [artiq] sbourdeauducq pushed 4 new commits to master: http://git.io/vY0fC
<GitHub161> artiq/master 5979f85 Sebastien Bourdeauducq: gui: use monospace font in log
<GitHub161> artiq/master 9fe6576 Sebastien Bourdeauducq: gui: add console description
<GitHub161> artiq/master 8bc1dd9 Sebastien Bourdeauducq: test/serialization: remove redundant test since Quantity was removed
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#324 (master - 05dd11a : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
kyak has quit []
kyak has joined #m-labs
<GitHub145> [artiq] sbourdeauducq pushed 5 new commits to master: http://git.io/vY0Bt
<GitHub145> artiq/master 61f45f5 Sebastien Bourdeauducq: gui/short_format: show string values
<GitHub145> artiq/master 696bceb Sebastien Bourdeauducq: gui: feedback on run deletion
<GitHub145> artiq/master 3c6a4b8 Sebastien Bourdeauducq: examples/ddb: use LED channel for KC705 QC1
bentley` has quit [Ping timeout: 264 seconds]
bentley` has joined #m-labs
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#325 (master - aba2d3f : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
<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
<whitequark> even works with PIC
<whitequark> okay, wonderful, I can link a shared object, that looks sane, and includes PT_GNU_EH_FRAME
mumptai has quit [Ping timeout: 264 seconds]