08:01 <sb0> http://fitzgeraldnick.com/2017/02/22/cpp-demangle.html "the canonical C++ demangler in libiberty (used by c++filt and gdb) has had tons of classic C bugs [...] there were so many of these issues that gdb went so far as to install a signal handler to catch SIGSEGVs during demangling. It “recovered” from the segfaults by longjmping out of the signal handler and printing a warning message before moving along and pretending that nothing happened"

08:24 <whitequark> typical GNU code

08:24 <whitequark> GDB does the same with its unwinder

08:25 <ohsix> typical? huhu

08:27 <ohsix> the binutils & gdb stuff is in one tree now

08:27 <ohsix> and nerd points, not actually gnu code https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=libiberty/cp-demangle.c;h=15ef3b48785f0ef49408cabbacb1f1352fbaef9e;hb=HEAD

08:28 <ohsix> looks uniquely gross though

08:28 <ohsix> something that should probably be formalized and generated from rule files

08:28 <ohsix> woooooow it is really bad

08:31 <GitHub> [artiq] sbourdeauducq commented on issue #407: @r-srinivas ping https://github.com/m-labs/artiq/issues/407#issuecomment-281927667

08:34 <sb0> whitequark, if you want to change the analyzer to include DMA, you should simply edit MessageEncoder to take the CRI signals (after the arbiter) instead of the CSRs

08:34 <sb0> it should be a rather simple change

08:34 <sb0> we may actually want to do that, since 1) we have quite a bit of memory bandwidth and 2) the DMA buffers may change so tracing them is tricky

08:36 <sb0> this doesn't play well with the "distributed DMA" plan though (but this is a very long-term feature, if it lands at all)

08:41 <whitequark> sb0: can you just make that change? sounds like you already have all the context for it

08:42 <GitHub> [artiq] sbourdeauducq pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/016743f079e5...b34c6ba6b946

08:42 <GitHub> artiq/master b34c6ba Sebastien Bourdeauducq: satman: process moninj packets

08:42 <GitHub> artiq/master 45ac0dc Sebastien Bourdeauducq: drtioaux: add moninj packets

08:53 <whitequark> sb0: the "better way to write that" is `as u8`

08:54 <whitequark> (or nothing)

08:54 <whitequark> mostly because as you write it, it's impossible to see looking at the code where the high byte gets cut off and where it isn't

08:57 <sb0> yes, that's the intended result

08:58 <sb0> what is going on is sometimes there are more than 256 rtio channels, in which case the function takes u16

08:58 <sb0> otherwise it takes u8

08:58 <whitequark> oh, I see

08:58 <whitequark> then just `as _`.

09:00 <GitHub> [artiq] whitequark pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/623a605d3b9c6b5de9f653e8ab8abce2a8bad5de

09:00 <GitHub> artiq/master 623a605 whitequark: satman: refactor type conversions.

09:00 <sb0> thanks

09:07 <bb-m-labs> build #419 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/419

09:15 <bb-m-labs> build #426 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/426

09:15 <bb-m-labs> build #1336 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1336

09:40 <bb-m-labs> build #420 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/420

09:48 <bb-m-labs> build #427 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/427

09:48 <bb-m-labs> build #1337 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1337

15:56 <sb0> whitequark, I don't really understand the thread code in session.rs. is there at most one thread that runs check_magic at any given time?

15:57 <sb0> if the magic isn't sent, doesn't this block new connections?

15:57 <whitequark> I believe it does

15:57 <whitequark> I haven't really considered that case

15:58 <whitequark> that could be fixed by pulling the body of if can_accept() into its own thread, I guess

16:00 <sb0> yes

16:37 <sb0> what is respawn doing exactly?

16:37 <whitequark> killing the old thread

16:37 <sb0> joins any previous thread

16:38 <whitequark> then joins

16:38 <whitequark> interrupts it first

16:38 <sb0> ah, terminates it too, yes