Re: libffi - updates needed?
* Steve McIntyre (steve@einval.com) 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 |_______/
Reply to: