* Re: libffi 3.1-rc1 needs testing!
2014-03-25 21:11 ` libffi 3.1-rc1 " Anthony Green
@ 2014-03-27 12:23 ` Dominik Vogt
2014-03-27 12:25 ` Dominik Vogt
2014-03-27 12:31 ` Dominik Vogt
` (5 subsequent siblings)
6 siblings, 1 reply; 24+ messages in thread
From: Dominik Vogt @ 2014-03-27 12:23 UTC (permalink / raw)
To: libffi-discuss
Host: s390x-unknown-linux-gnu
Toolchain: gcc-4.8.3 20140221 (prerelease), binutils-2.23.52.20130314
Failures: 0
Host: s390-unknown-linux-gnu
Toolchain: gcc-4.7.2 20120921, binutils-2.22.52.0.1-10.fc17 2012013
Failures: 0
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: libffi 3.1-rc1 needs testing!
2014-03-27 12:23 ` Dominik Vogt
@ 2014-03-27 12:25 ` Dominik Vogt
0 siblings, 0 replies; 24+ messages in thread
From: Dominik Vogt @ 2014-03-27 12:25 UTC (permalink / raw)
To: libffi-discuss
On Thu, Mar 27, 2014 at 01:23:10PM +0100, Dominik Vogt wrote:
> Host: s390x-unknown-linux-gnu
Ups: ^^^^^^^
ibm
> Toolchain: gcc-4.8.3 20140221 (prerelease), binutils-2.23.52.20130314
> Failures: 0
>
> Host: s390-unknown-linux-gnu
^^^^^^^
ibm
> Toolchain: gcc-4.7.2 20120921, binutils-2.22.52.0.1-10.fc17 2012013
> Failures: 0
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: libffi 3.1-rc1 needs testing!
2014-03-25 21:11 ` libffi 3.1-rc1 " Anthony Green
2014-03-27 12:23 ` Dominik Vogt
@ 2014-03-27 12:31 ` Dominik Vogt
2014-03-27 12:40 ` Samuli Suominen
` (4 subsequent siblings)
6 siblings, 0 replies; 24+ messages in thread
From: Dominik Vogt @ 2014-03-27 12:31 UTC (permalink / raw)
To: libffi-discuss
Host: x86_64-unknown-linux-gnu
Toolchain: gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
binutils (GNU Binutils for Ubuntu) 2.22
Failures: 0
Comment: Ubuntu 12.04.4
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: libffi 3.1-rc1 needs testing!
2014-03-25 21:11 ` libffi 3.1-rc1 " Anthony Green
2014-03-27 12:23 ` Dominik Vogt
2014-03-27 12:31 ` Dominik Vogt
@ 2014-03-27 12:40 ` Samuli Suominen
2014-03-27 12:45 ` Samuli Suominen
2014-03-27 12:55 ` Samuli Suominen
` (3 subsequent siblings)
6 siblings, 1 reply; 24+ messages in thread
From: Samuli Suominen @ 2014-03-27 12:40 UTC (permalink / raw)
To: libffi-discuss, hardened, zorry
[-- Attachment #1: Type: text/plain, Size: 248 bytes --]
On 25/03/14 23:10, Anthony Green wrote:
> It's here: ftp://sourceware.org/pub/libffi/libffi-3.1-rc1.tar.gz
>
>
This patch is missing from the 3.1-rc1 release:
https://sourceware.org/ml/libffi-discuss/2013/msg00130.html
I'll attach it here too.
[-- Attachment #2: libffi-3.0.13-emutramp_pax_proc.patch --]
[-- Type: text/x-patch, Size: 911 bytes --]
2013-05-22 Magnus Granberg <zorry@gentoo.org>
#457194
* src/closuer.c (emutramp_enabled_check): Check with /proc.
--- a/src/closures.c 2013-03-17 23:27:11.000000000 +0100
+++ b/src/closures.c 2013-04-29 23:26:02.279022022 +0200
@@ -181,10 +181,26 @@ static int emutramp_enabled = -1;
static int
emutramp_enabled_check (void)
{
- if (getenv ("FFI_DISABLE_EMUTRAMP") == NULL)
- return 1;
- else
+ char *buf = NULL;
+ size_t len = 0;
+ FILE *f;
+ int ret;
+ f = fopen ("/proc/self/status", "r");
+ if (f == NULL)
return 0;
+ ret = 0;
+
+ while (getline (&buf, &len, f) != -1)
+ if (!strncmp (buf, "PaX:", 4))
+ {
+ char emutramp;
+ if (sscanf (buf, "%*s %*c%c", &emutramp) == 1)
+ ret = (emutramp == 'E');
+ break;
+ }
+ free (buf);
+ fclose (f);
+ return ret;
}
#define is_emutramp_enabled() (emutramp_enabled >= 0 ? emutramp_enabled \
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: libffi 3.1-rc1 needs testing!
2014-03-25 21:11 ` libffi 3.1-rc1 " Anthony Green
` (2 preceding siblings ...)
2014-03-27 12:40 ` Samuli Suominen
@ 2014-03-27 12:55 ` Samuli Suominen
2014-03-28 15:43 ` Anthony Green
2014-03-28 15:05 ` James Greenhalgh
` (2 subsequent siblings)
6 siblings, 1 reply; 24+ messages in thread
From: Samuli Suominen @ 2014-03-27 12:55 UTC (permalink / raw)
To: libffi-discuss
On 25/03/14 23:10, Anthony Green wrote:
> It's here: ftp://sourceware.org/pub/libffi/libffi-3.1-rc1.tar.gz
>
>
Another missing patch from the release:
https://sourceware.org/ml/libffi-discuss/2014/msg00028.html
It's an important one, at least for distributions building for multiple
different arch's (like 32bit vs. 64bit)
at the same time, important for eg. Gentoo's libffi
Otherwise flags like eg. -m32 will be skipped and
-print-multi-os-directory gives wrong value
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: libffi 3.1-rc1 needs testing!
2014-03-25 21:11 ` libffi 3.1-rc1 " Anthony Green
` (3 preceding siblings ...)
2014-03-27 12:55 ` Samuli Suominen
@ 2014-03-28 15:05 ` James Greenhalgh
2014-03-28 17:33 ` Anthony Green
2014-03-28 20:37 ` Andreas Tobler
2014-03-28 20:39 ` Matthias Klose
6 siblings, 1 reply; 24+ messages in thread
From: James Greenhalgh @ 2014-03-28 15:05 UTC (permalink / raw)
To: Anthony Green; +Cc: libffi-discuss
Hi,
I'm seeing issues with libffi.call/float2.c on GCC 4.9 toolchains across
ARM, AArch64, x86_64. I guess GCC 4.9 is more aggressive in warning for
unused values:
FAIL: libffi.call/float2.c -W -Wall -O0 (test for excess errors)
FAIL: libffi.call/float2.c -W -Wall -O2 (test for excess errors)
FAIL: libffi.call/float2.c -W -Wall -O3 (test for excess errors)
FAIL: libffi.call/float2.c -W -Wall -Os (test for excess errors)
FAIL: libffi.call/float2.c -W -Wall -O2 -fomit-frame-pointer (test for excess errors)
In file included from ../../testsuite/libffi.call/float2.c:10:0:
../../testsuite/libffi.call/float2.c: In function 'main':
../../testsuite/libffi.call/ffitest.h:18:39: warning: right-hand operand of comma expression has no effect [-Wunused-value]
#define CHECK(x) (!(x) ? (abort(), 1) : 0)
^
../../testsuite/libffi.call/float2.c:55:5: note: in expansion of macro 'CHECK'
CHECK(0);
^
output is:
In file included from ../../testsuite/libffi.call/float2.c:10:0:
../../testsuite/libffi.call/float2.c: In function 'main':
../../testsuite/libffi.call/ffitest.h:18:39: warning: right-hand operand of comma expression has no effect [-Wunused-value]
#define CHECK(x) (!(x) ? (abort(), 1) : 0)
^
../../testsuite/libffi.call/float2.c:55:5: note: in expansion of macro 'CHECK'
CHECK(0);
^
Thanks,
James
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: libffi 3.1-rc1 needs testing!
2014-03-28 15:05 ` James Greenhalgh
@ 2014-03-28 17:33 ` Anthony Green
2014-04-24 12:47 ` Marcus Shawcroft
0 siblings, 1 reply; 24+ messages in thread
From: Anthony Green @ 2014-03-28 17:33 UTC (permalink / raw)
To: James Greenhalgh; +Cc: libffi-discuss
James Greenhalgh <james.greenhalgh@arm.com> writes:
> Hi,
>
> I'm seeing issues with libffi.call/float2.c on GCC 4.9 toolchains across
> ARM, AArch64, x86_64. I guess GCC 4.9 is more aggressive in warning for
> unused values:
Thanks James. I just committed a fix for this.
AG
>
> FAIL: libffi.call/float2.c -W -Wall -O0 (test for excess errors)
> FAIL: libffi.call/float2.c -W -Wall -O2 (test for excess errors)
> FAIL: libffi.call/float2.c -W -Wall -O3 (test for excess errors)
> FAIL: libffi.call/float2.c -W -Wall -Os (test for excess errors)
> FAIL: libffi.call/float2.c -W -Wall -O2 -fomit-frame-pointer (test for excess errors)
>
> In file included from ../../testsuite/libffi.call/float2.c:10:0:
> ../../testsuite/libffi.call/float2.c: In function 'main':
> ../../testsuite/libffi.call/ffitest.h:18:39: warning: right-hand operand of comma expression has no effect [-Wunused-value]
> #define CHECK(x) (!(x) ? (abort(), 1) : 0)
> ^
> ../../testsuite/libffi.call/float2.c:55:5: note: in expansion of macro 'CHECK'
> CHECK(0);
> ^
> output is:
> In file included from ../../testsuite/libffi.call/float2.c:10:0:
> ../../testsuite/libffi.call/float2.c: In function 'main':
> ../../testsuite/libffi.call/ffitest.h:18:39: warning: right-hand operand of comma expression has no effect [-Wunused-value]
> #define CHECK(x) (!(x) ? (abort(), 1) : 0)
> ^
> ../../testsuite/libffi.call/float2.c:55:5: note: in expansion of macro 'CHECK'
> CHECK(0);
> ^
>
> Thanks,
> James
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: libffi 3.1-rc1 needs testing!
2014-03-28 17:33 ` Anthony Green
@ 2014-04-24 12:47 ` Marcus Shawcroft
0 siblings, 0 replies; 24+ messages in thread
From: Marcus Shawcroft @ 2014-04-24 12:47 UTC (permalink / raw)
To: Anthony Green; +Cc: James Greenhalgh, libffi-discuss
On 28 March 2014 17:33, Anthony Green <green@moxielogic.com> wrote:
> James Greenhalgh <james.greenhalgh@arm.com> writes:
>
>> Hi,
>>
>> I'm seeing issues with libffi.call/float2.c on GCC 4.9 toolchains across
>> ARM, AArch64, x86_64. I guess GCC 4.9 is more aggressive in warning for
>> unused values:
>
> Thanks James. I just committed a fix for this.
>
> AG
>> FAIL: libffi.call/float2.c -W -Wall -O0 (test for excess errors)
>> FAIL: libffi.call/float2.c -W -Wall -O2 (test for excess errors)
>> FAIL: libffi.call/float2.c -W -Wall -O3 (test for excess errors)
>> FAIL: libffi.call/float2.c -W -Wall -Os (test for excess errors)
>> FAIL: libffi.call/float2.c -W -Wall -O2 -fomit-frame-pointer (test for excess errors)
>>
>> In file included from ../../testsuite/libffi.call/float2.c:10:0:
>> ../../testsuite/libffi.call/float2.c: In function 'main':
>> ../../testsuite/libffi.call/ffitest.h:18:39: warning: right-hand operand of comma expression has no effect [-Wunused-value]
>> #define CHECK(x) (!(x) ? (abort(), 1) : 0)
>> ^
>> ../../testsuite/libffi.call/float2.c:55:5: note: in expansion of macro 'CHECK'
>> CHECK(0);
>> ^
>> output is:
>> In file included from ../../testsuite/libffi.call/float2.c:10:0:
>> ../../testsuite/libffi.call/float2.c: In function 'main':
>> ../../testsuite/libffi.call/ffitest.h:18:39: warning: right-hand operand of comma expression has no effect [-Wunused-value]
>> #define CHECK(x) (!(x) ? (abort(), 1) : 0)
>> ^
>> ../../testsuite/libffi.call/float2.c:55:5: note: in expansion of macro 'CHECK'
>> CHECK(0);
>> ^
Hi Anthony, I'm still seeing these failures on master. I'm currently
looking at version:
commit 31e0d4ecff6dc2a6c75a066ee099b52a43f6ba27
Merge: 1c0e9a7 99909eb
Author: Anthony Green <green@moxielogic.com>
Date: Wed Apr 23 19:24:47 2014 -0400
did the fix you applied make it to master?
Cheers
/Marcus
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: libffi 3.1-rc1 needs testing!
2014-03-25 21:11 ` libffi 3.1-rc1 " Anthony Green
` (4 preceding siblings ...)
2014-03-28 15:05 ` James Greenhalgh
@ 2014-03-28 20:37 ` Andreas Tobler
2014-03-28 20:39 ` Matthias Klose
6 siblings, 0 replies; 24+ messages in thread
From: Andreas Tobler @ 2014-03-28 20:37 UTC (permalink / raw)
To: Anthony Green, libffi-discuss
- powerpc64-unknown-freebsd11.0 ok
- powerpc-unknown-freebsd11.0 ok
- x86_64-unknown-freebsd11.0 ok
All with gcc48.
Thanks!
Andreas
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: libffi 3.1-rc1 needs testing!
2014-03-25 21:11 ` libffi 3.1-rc1 " Anthony Green
` (5 preceding siblings ...)
2014-03-28 20:37 ` Andreas Tobler
@ 2014-03-28 20:39 ` Matthias Klose
2014-03-28 21:56 ` Anthony Green
2014-03-29 14:25 ` ABI breakage (Was: libffi 3.1-rc1 needs testing!) Anthony Green
6 siblings, 2 replies; 24+ messages in thread
From: Matthias Klose @ 2014-03-28 20:39 UTC (permalink / raw)
To: Anthony Green, libffi-discuss
Am 25.03.2014 22:10, schrieb Anthony Green:
> I am still hoping to get a release out before April, but I'll need
> plenty of help with the testing...
the good news is that the testsuite passes on every Debian and Ubuntu
architecture without test failures. The bad news is that it is broken on x86
(not x86_64).
running the python, ruby-ffi, cffi testsuites against the newly built libffi, it
breaks with segfaults.
A small reproducer is (taken from https://launchpad.net/bugs/1298824):
sudo apt-get install python3-gi gir1.2-gtk-3.0 xvfb
xvfb-run python3 -c 'from gi.repository import GLib, Gtk;
GLib.timeout_add_seconds(1, Gtk.main_quit, None); Gtk.main()'
It is pointed out that rebuilding the depending packages fixes the segfaults.
Signal: 11
SourcePackage: python3.4
StacktraceTop:
g_callable_info_free_closure (callable_info=0x9e8a5b0, closure=0xb6b43008) at
girepository/girffi.c:426
_pygi_invoke_closure_free (data=0x9efdd50) at ../../gi/pygi-closure.c:638
_pygi_destroy_notify_callback_closure (cif=0x9efddbc, result=0xbfaec770,
args=0xbfaec710, data=0x0) at ../../gi/pygi-closure.c:703
ffi_closure_SYSV_inner (closure=0xb6b43030, respp=0xbfaec77c, args=0xbfaec790)
at ../src/x86/ffi.c:503
ffi_closure_SYSV () at ../src/x86/sysv.S:199
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: libffi 3.1-rc1 needs testing!
2014-03-28 20:39 ` Matthias Klose
@ 2014-03-28 21:56 ` Anthony Green
2014-03-28 22:31 ` Anthony Green
2014-03-29 14:25 ` ABI breakage (Was: libffi 3.1-rc1 needs testing!) Anthony Green
1 sibling, 1 reply; 24+ messages in thread
From: Anthony Green @ 2014-03-28 21:56 UTC (permalink / raw)
To: Matthias Klose; +Cc: libffi-discuss
Matthias Klose <doko@ubuntu.com> writes:
> Am 25.03.2014 22:10, schrieb Anthony Green:
>> I am still hoping to get a release out before April, but I'll need
>> plenty of help with the testing...
>
> the good news is that the testsuite passes on every Debian and Ubuntu
> architecture without test failures. The bad news is that it is broken
> on x86 (not x86_64).
>
> running the python, ruby-ffi, cffi testsuites against the newly built
> libffi, it breaks with segfaults.
>
> A small reproducer is (taken from https://launchpad.net/bugs/1298824):
>
> sudo apt-get install python3-gi gir1.2-gtk-3.0 xvfb
> xvfb-run python3 -c 'from gi.repository import GLib, Gtk;
> GLib.timeout_add_seconds(1, Gtk.main_quit, None); Gtk.main()'
>
> It is pointed out that rebuilding the depending packages fixes the
> segfaults.
Ok, this suggests ABI breakage. There were recent changes in 32-bit
Linux support that may be to blame (additional ABI support). I can look
into this.
Thanks for the pointer!
AG
>
> Signal: 11
> SourcePackage: python3.4
> StacktraceTop:
> g_callable_info_free_closure (callable_info=0x9e8a5b0,
> closure=0xb6b43008) at girepository/girffi.c:426
> _pygi_invoke_closure_free (data=0x9efdd50) at ../../gi/pygi-closure.c:638
> _pygi_destroy_notify_callback_closure (cif=0x9efddbc,
> result=0xbfaec770, args=0xbfaec710, data=0x0) at
> ../../gi/pygi-closure.c:703
> ffi_closure_SYSV_inner (closure=0xb6b43030, respp=0xbfaec77c,
> args=0xbfaec790) at ../src/x86/ffi.c:503
> ffi_closure_SYSV () at ../src/x86/sysv.S:199
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: libffi 3.1-rc1 needs testing!
2014-03-28 21:56 ` Anthony Green
@ 2014-03-28 22:31 ` Anthony Green
0 siblings, 0 replies; 24+ messages in thread
From: Anthony Green @ 2014-03-28 22:31 UTC (permalink / raw)
To: Matthias Klose; +Cc: libffi-discuss
Anthony Green <green@moxielogic.com> writes:
> Ok, this suggests ABI breakage. There were recent changes in 32-bit
> Linux support that may be to blame (additional ABI support). I can look
> into this.
I had a look at the code changes and nothing jumped out at me. Then I
built a 32-bit 3.0.13 libffi on x86-64 Linux with "-m32". I did the
same thing with 3.1 from github. Then I replaced the 3.0.14 libffi
libraries in the build tree with the 3.1 libraries and ran 'make check'.
Everything passed. So if there is any ABI breakage, it must be very
subtle.
Unless you have any other good ideas (and I'm hoping you do), we're
going to have to reproduce this the hard way.
AG
>
>
>>
>> Signal: 11
>> SourcePackage: python3.4
>> StacktraceTop:
>> g_callable_info_free_closure (callable_info=0x9e8a5b0,
>> closure=0xb6b43008) at girepository/girffi.c:426
>> _pygi_invoke_closure_free (data=0x9efdd50) at ../../gi/pygi-closure.c:638
>> _pygi_destroy_notify_callback_closure (cif=0x9efddbc,
>> result=0xbfaec770, args=0xbfaec710, data=0x0) at
>> ../../gi/pygi-closure.c:703
>> ffi_closure_SYSV_inner (closure=0xb6b43030, respp=0xbfaec77c,
>> args=0xbfaec790) at ../src/x86/ffi.c:503
>> ffi_closure_SYSV () at ../src/x86/sysv.S:199
^ permalink raw reply [flat|nested] 24+ messages in thread
* ABI breakage (Was: libffi 3.1-rc1 needs testing!)
2014-03-28 20:39 ` Matthias Klose
2014-03-28 21:56 ` Anthony Green
@ 2014-03-29 14:25 ` Anthony Green
2014-05-30 12:21 ` Matthias Klose
1 sibling, 1 reply; 24+ messages in thread
From: Anthony Green @ 2014-03-29 14:25 UTC (permalink / raw)
To: Matthias Klose; +Cc: libffi-discuss, josh
Matthias Klose <doko@ubuntu.com> writes:
> Am 25.03.2014 22:10, schrieb Anthony Green:
>> I am still hoping to get a release out before April, but I'll need
>> plenty of help with the testing...
>
> the good news is that the testsuite passes on every Debian and Ubuntu
> architecture without test failures. The bad news is that it is broken
> on x86 (not x86_64).
Thanks for your help today on IRC to reproduce this. This is definitely
ABI breakage. I've filed a bug here....
https://github.com/atgreen/libffi/issues/113
I won't have much time to think about it this weekend, but hopefully
there's a solution that lets us preserve the ABI.
AG
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ABI breakage (Was: libffi 3.1-rc1 needs testing!)
2014-03-29 14:25 ` ABI breakage (Was: libffi 3.1-rc1 needs testing!) Anthony Green
@ 2014-05-30 12:21 ` Matthias Klose
0 siblings, 0 replies; 24+ messages in thread
From: Matthias Klose @ 2014-05-30 12:21 UTC (permalink / raw)
To: Anthony Green; +Cc: libffi-discuss, josh
Am 29.03.2014 15:24, schrieb Anthony Green:
> Matthias Klose <doko@ubuntu.com> writes:
>
>> Am 25.03.2014 22:10, schrieb Anthony Green:
>>> I am still hoping to get a release out before April, but I'll need
>>> plenty of help with the testing...
>>
>> the good news is that the testsuite passes on every Debian and Ubuntu
>> architecture without test failures. The bad news is that it is broken
>> on x86 (not x86_64).
>
> Thanks for your help today on IRC to reproduce this. This is definitely
> ABI breakage. I've filed a bug here....
>
> https://github.com/atgreen/libffi/issues/113
>
> I won't have much time to think about it this weekend, but hopefully
> there's a solution that lets us preserve the ABI.
it looks like this is fixed in 3.1, but the issue is still open, and I can't see
this fix mentioned in the ChangeLog-3.1, nor the git changes list.
Matthias
^ permalink raw reply [flat|nested] 24+ messages in thread