09:16 <fijal> cfbolz, mattip: ping, want to help with libffi a bit?

09:16 <fijal> seems like new version of libffi does not have ffi_prep_closure, but has ffi_prep_closure_loc

09:17 <fijal> which makes me wonder if we want to maintain our own free list of closures, probably not, but does that mean we can't really do anything on old libffi? do we care?

09:18 <cfbolz> fijal: so they deprecated some api that we're using?

09:19 <fijal> they removed it, it seems

09:19 <fijal> You may see old code referring to ffi_prep_closure. This function is deprecated, as it cannot handle the need for separate writable and executable addresses.

09:20 <fijal> http://www.chiark.greenend.org.uk/doc/libffi-dev/html/The-Closure-API.html

09:20 <fijal> should I just port stuff to new API?

09:21 <fijal> https://github.com/racket/racket/issues/2985

09:25 <fijal> just calling it _loc works

09:25 <fijal> (I'll have to work around the policy here, but that will take a second)

09:26 <cfbolz> fijal: hm, it feels weird if the difference is just the name and the behavior the same

09:27 <fijal> I think the idea is that you can pass different pointers

09:27 <fijal> for two different arguments

09:28 <fijal> I'm pretty sure it'll be soon evident why this is the case, do we have some PAX support somewhere? I'm sure we do

09:33 <fijal> do we care about cross-compiling on the M1 architecture? The general rule we've been applying has been "no", like python version should match the cpu version, I would think

09:38 <cfbolz> fijal: yes, agreed

09:38 <cfbolz> Ah, I see, it's not completely the same signature

09:38 <cfbolz> It takes another argument too

09:38 <fijal> not completely, but it seems to work with just the same argument passed twice

09:38 <fijal> (work)

09:38 <fijal> but I think we need to be a bit more careful

09:38 <cfbolz> ORacket did it too'

09:39 <cfbolz> Racket

09:39 <fijal> I'm fixing translator/c tests, seems like a good start

09:39 <cfbolz> Great

09:39 <fijal> annotator and rtyper pass

09:39 <fijal> plan is to fix the whole of rpython, or maybe with some exceptions then merge

09:46 <cfbolz> fijal: right, rlib is probably also a good target

09:46 <cfbolz> (jit in any case)

09:46 <fijal> yep

09:47 <fijal> I think I found the first real issue, which is PAX

09:47 <fijal> I'm not sure yet if it's real or not in this case

10:50 <mattip> is anyone using old libffi? The linux64, linux32, aarch64, win64 are all libffi3.2 or later, and I think the macos one is too

10:50 <mattip> buildbots

10:51 <mattip> maybe the s390x one, which seems broken anyway

10:52 <mattip> fijal: great that there is progress, I guess that means your hardware arrived

10:57 <arigato> fijal: I don't know the current status for libffi allocating closures, but I *think* the major security issue is still not fixed everywhere (https://cffi.readthedocs.io/en/latest/using.html#callbacks-old-style). But using ffi_prep_closure_loc() instead of ffi_prep_closure() is safe

11:14 <fijal> On Mac OS X, you need to give your application the entitlement com.apple.security.cs.allow-unsigned-executable-memory

11:14 <fijal> arigato: can this be fixed by being more clever about the way we allocate memory?

11:15 <fijal> oh I see

11:15 <fijal> kinda

13:02 <fijal> arigato: do we have any mechanism for PAX in pypy?