IRC channel logs


back to list of logs

***drakonis1 is now known as drakonis
<civodul>wingo: you missed the Guile 2.0 birthday this week-end ;-)
<wingo>so it seems :)
<civodul>wingo: so does Cygwin follow a different ABI?
<civodul>i didn't understand why libghtening needed an #ifdef
<wingo>civodul: i was actually not able to find the reference specifying that the 64-bit windows ABI had to reserve an additional 32 stack bytes
***dsmith-w` is now known as dsmith-work
<dsmith-work>Tuesday Greetings, Guilers
<wingo>i would like to see that link
<wingo>but if it fixes things for cygwin64 users, then great, i guess? :P
<wingo>basically i trust whatever mike gran says ;)
<str1ngs>hello dsmith-work
<weinholt>sounds similar to the "red zone" in the x86-64 ABI, but iirc that's 128 bytes
<civodul>what's the "red zone"?
<weinholt>... and it appears to be 128 bytes reserved for the application, not the other way around :)
<civodul>it's great if it fixes things for Cygwin users, but i was wondering then if it would also help on regular SysV x86_64?
<weinholt>gcc says: "The red zone is mandated by the x86-64 ABI; it is a 128-byte area beyond the location of the stack pointer that is not modified by signal or interrupt handlers and therefore can be used for temporary data without adjusting the stack pointer."
<civodul>so it's up to the signal handling implementation to respect that?
<weinholt>yes, it would have to be
<wingo> mentions the 32-byte thing
<wingo>describes the 32-byte region as "home areas" for the register arguments
<wingo>sounds strange to me but whatever
<civodul>so the Wikipedia page suggests it's a Microsoft-specific thing
<civodul>oh well
<dsmith-work>Reminds me of having to leave space on the stack for saving the SI and DI regs.
<wingo>civodul: i don't know of codegen bugs on sysv x86_64 fwiw
<wingo>maybe one...
<jcowan>civodul: Cygwin doesn't share anybody's ABI, more or less by definition
<civodul>quizz: what does that return: (select (list (open-fdes "/dev/null" O_WRONLY)) '() '()) ?
<civodul>hint: not what i thought
<jcowan>civodul: That's exactly right. A port at EOF is always ready to be read from.
<jcowan>because reading from it will never hang you, it will just give you an eof-object.
<civodul>yeah, having reread the libc manual, it makes perfect sense
<civodul>i'm just showing my ignorance :-)
<civodul>though (select (list (socket AF_UNIX SOCK_STREAM 0)) '() '()) is more surprising
<civodul>well, a read on that socket would not block, it would just fail
<jcowan>Yes, select is about blocking and only blocking.
<jcowan>select-not-blocked might be a better name
<civodul>wingo: did you have a chance to look at the weak-table issue: ?
<civodul>i've spent some time on it without much success so far
<civodul>if we could fix it, that'd unlock Guix on AArch64 and a Guix release :-)
<rlb>looks like srfi-64 might actually pass a test-equal test that has an assertion failure...
<rlb>if I'm reading it right
<rlb>Test end:
<rlb> result-kind: pass
<rlb> actual-value: #f
<rlb> actual-error: (%exception #<&assertion-failure>)
<rlb> expected-value: #f
***sneek_ is now known as sneek
<dsmith-work>sneek: botsnack