* Steve McIntyre ([email protected]) wrote: > Hi David! > <snip>
> >As I remember most other archs 'get away with it' often > >because they do silly things like pass values in registers and > >on the stack and still offset the stack for the ones passed in > >registers. I don't know if anyone has got around to doing > >other backends other than armhf since I touched it, but > >I think we knew there were some of the MIPS varients that could > >do with it. > > Right. Are these the newer mips ABI variants like n32/n64, do you > know? If so, I'm not so worried just yet! Looking through my notes I've got a mention that a test failed on MIPS n32 (although there was some thinking that it might be fixable by passing stuff both on stack and in registers), I also have a vague memory about someone asking on the ffi list about it on MIPS but can't find it. There is the 6 year old gcc bug ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26744 ) for PPC MacOS (!). > >> Looking at gcc-4.6 and gcc-4.7, I can see that the embedded copies of > >> libffi are too old for this fix. I don't see a build-dep on > >> libffi-dev, whish suggests that they're using these embedded copies > >> rather than the system version. A couple of questions here: I'm > >> curious why this is? If it's definitely necessary, could we update > >> those embedded copies to a more recent libffi with the change > >> included? > >> > >> Even beyond that, there are quite likely to be changes that would need > >> to be made in the gcc source to use the new ffi_prep_cif_var() > >> function. My scan of the archive shows ffi_prep_cif() shows up / is > >> used in: > >> > >> gcc-4.6 > >> gcc-snapshot > >> gcj-4.[467] > >> > >> at least. Can you help please? > > > >However, it's pretty rare for things to actually use variadics with > >libffi, it's even rarer for them to pass floats; although someone had > >asked for libffi to be fixed for armhf, I could never find someone to > >say what app was broken; there were some mumblings about Java, but even > >there I didn't actually find someone with a test. I think some Python > >ctype examples looked broken. > > Yes, I've seen that too. > > >The other nasty to keep in mind is that where the libffi > >calls come from some scripting language glue, it's not clear > >that the languages/glue have the syntax to express that they're calling > >a variadic function, so it might need language changes. > >(I never managed to get any response out of the CType list). > > Yes. I looked for a response to your original mail there and couldn't > find any in list archives; I'm guessing that's because you didn't get > one? Correct, no response. > The Haskell packages that showed up in my scan of the Debian archive > are apparently all OK; ghc has a habit of embedding large chunks of > the core in everything it builds, and the ffi calls there are expected > to be safe (no variadics). Ah, I hadn't been brave enough to open the Haskell stuff up. > Otherwise, as you say: I'm looking at a number of language > implementations where it's (a) not clear if they'll ever do variadics > (b) if they *might* use variadics, it'll be because somebody is > calling through a generic helper function with no current way of > determining if the callee is variadic or not. Yay... :-/ There was a GCJ failure on armhf that was blamed on libffi for a while until we spoke to aph and he found the real cause. The other one to look at is there are a lot of examples of using libffi for variadic that are wrong, even if no one uses it in anger; eg. http://www.swig.org/Doc1.3/Varargs.html#Varargs_nn7 Have fun, Dave -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ gro.gilbert @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/20120417084022.GA10623@gallifrey
