Bug#458745: arm-only miscompilation of alloca code
* Martin Michlmayr [EMAIL PROTECTED] [2008-01-21 18:33]: This address looks highly suspicious as it is not aligned while the type is a (void*). On ARM unaligned access are not guaranteed to work and actually depends on the CPU. On some of them it works as on i386, while usually you get the aligned word, but rotated depending on the mis-alignement. In short non-aligned accesses do not generate a SIGBUS, but rather return corrupted data, so here a wrong address that could lead to a segfault. If you look at the bug log, all tests with aligned address work. The others segfault or return (nil) as on tbm's machine. Any comments, Camm? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34652#c2 contains another good describing why this is not a bug in gcc but the test case. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458745: arm-only miscompilation of alloca code
On Wed, Jan 02, 2008 at 10:09:39AM -0500, Camm Maguire wrote:
Package: gcc-4.2
Version: 4.2.2-4
Severity: important
/tmp/foo.c:
=
#include stdio.h
#include alloca.h
#include stdarg.h
#define object void *
int VFUN_NARGS;
void *alloca_val;
struct cons {
object c_cdr;
object c_car;
};
#define Cnil 0
static void
foo(object first,...) {
va_list ap;
int narg = VFUN_NARGS;
struct cons *V1128;
object V1129;
va_start(ap,first);
V1129 =
!narg? Cnil : (alloca_val=alloca((narg)*sizeof(struct
cons)+sizeof(object)),
({object _b=(void *)alloca_val;if (((unsigned
long)_b)sizeof(_b)) _b++;
{register struct cons *_p=(void *)_b;
{struct cons *_e=_p+(narg-1);
for (;_p_e;_p++) {_p-c_car=({object
_t=first;first=va_arg(ap,object);_t;});_p-c_cdr=(object)(_p+1);}}
_p-c_car=first;_p-c_cdr=Cnil;}_b;}));
va_end(ap);
V1128= V1129;
for (;V1128!=Cnil;V1128=V1128-c_cdr)
printf(%p\n,V1128-c_car);
}
int
main(int argc,char * argv[]) {
VFUN_NARGS=4;
foo(argc,1,2,3);
return 0;
}
=
i386 sid:
=
cc -g /tmp/foo.c -o /tmp/foo
/tmp/foo
0xbf867bd0
0x1
0x2
0x3
=
leisner dchroot sid:
=
cc -g foo.c -o foo
./foo
0x18beed5d
This address looks highly suspicious as it is not aligned while the type
is a (void*).
On ARM unaligned access are not guaranteed to work and actually
depends on the CPU. On some of them it works as on i386, while usually
you get the aligned word, but rotated depending on the mis-alignement.
In short non-aligned accesses do not generate a SIGBUS, but rather
return corrupted data, so here a wrong address that could lead to a
segfault.
If you look at the bug log, all tests with aligned address work. The
others segfault or return (nil) as on tbm's machine.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458745: arm-only miscompilation of alloca code
* Camm Maguire [EMAIL PROTECTED] [2008-01-02 16:55]: Is EABI the old arm, or the new? Couldn't this make a difference? EABI is the new ABI. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458745: arm-only miscompilation of alloca code
* Camm Maguire [EMAIL PROTECTED] [2008-01-02 16:55]: Is EABI the old arm, or the new? Couldn't this make a difference? I can reproduce the problem with the old ABI (i.e. the current port in Debian). I'll open a bug report with GCC. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458745: arm-only miscompilation of alloca code
Greetings! Martin Michlmayr [EMAIL PROTECTED] writes: * Camm Maguire [EMAIL PROTECTED] [2008-01-02 16:55]: Is EABI the old arm, or the new? Couldn't this make a difference? I can reproduce the problem with the old ABI (i.e. the current port in Debian). I'll open a bug report with GCC. Thank you! Are we going to have two arm ports, or is the old one going away for lenny? Take care, -- Martin Michlmayr http://www.cyrius.com/ -- Camm Maguire[EMAIL PROTECTED] == The earth is but one country, and mankind its citizens. -- Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458745: arm-only miscompilation of alloca code
On Thu, 2008-01-03 at 17:44 -0500, Camm Maguire wrote: Greetings! Martin Michlmayr [EMAIL PROTECTED] writes: * Camm Maguire [EMAIL PROTECTED] [2008-01-02 16:55]: Is EABI the old arm, or the new? Couldn't this make a difference? I can reproduce the problem with the old ABI (i.e. the current port in Debian). I'll open a bug report with GCC. Thank you! Are we going to have two arm ports, or is the old one going away for lenny? There are a lot of devices that need support from the existing Debian arm port as well as newer devices that need the new ABI. There is a possible method for combining the two but both will be needed - and probably for some time after Lenny. Contact debian-arm for more info. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Bug#458745: arm-only miscompilation of alloca code
* Camm Maguire [EMAIL PROTECTED] [2008-01-03 17:44]: Are we going to have two arm ports, or is the old one going away for lenny? arm will be in lenny but it'll probably go away in the next release or the one after the next. armel will hopefully be in lenny, but it's not even part of unstable yet (i.e. they have their own separate archive). -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458745: arm-only miscompilation of alloca code
Package: gcc-4.2
Version: 4.2.2-4
Severity: important
/tmp/foo.c:
=
#include stdio.h
#include alloca.h
#include stdarg.h
#define object void *
int VFUN_NARGS;
void *alloca_val;
struct cons {
object c_cdr;
object c_car;
};
#define Cnil 0
static void
foo(object first,...) {
va_list ap;
int narg = VFUN_NARGS;
struct cons *V1128;
object V1129;
va_start(ap,first);
V1129 =
!narg? Cnil : (alloca_val=alloca((narg)*sizeof(struct cons)+sizeof(object)),
({object _b=(void *)alloca_val;if (((unsigned
long)_b)sizeof(_b)) _b++;
{register struct cons *_p=(void *)_b;
{struct cons *_e=_p+(narg-1);
for (;_p_e;_p++) {_p-c_car=({object
_t=first;first=va_arg(ap,object);_t;});_p-c_cdr=(object)(_p+1);}}
_p-c_car=first;_p-c_cdr=Cnil;}_b;}));
va_end(ap);
V1128= V1129;
for (;V1128!=Cnil;V1128=V1128-c_cdr)
printf(%p\n,V1128-c_car);
}
int
main(int argc,char * argv[]) {
VFUN_NARGS=4;
foo(argc,1,2,3);
return 0;
}
=
i386 sid:
=
cc -g /tmp/foo.c -o /tmp/foo
/tmp/foo
0xbf867bd0
0x1
0x2
0x3
=
leisner dchroot sid:
=
cc -g foo.c -o foo
./foo
0x18beed5d
Segmentation fault
=
Take care,
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.20-gen
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages gcc-4.2 depends on:
ii binutils2.18.1~cvs20071027-1 The GNU assembler, linker and bina
ii cpp-4.2 4.2.2-4 The GNU C preprocessor
ii gcc-4.2-base4.2.2-4 The GNU Compiler Collection (base
ii libc6 2.7-2GNU C Library: Shared libraries
ii libgcc1 1:4.2.2-4GCC support library
ii libgomp14.2.2-4 GCC OpenMP (GOMP) support library
Versions of packages gcc-4.2 recommends:
ii libc6-dev 2.7-2 GNU C Library: Development Librari
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458745: arm-only miscompilation of alloca code
I just tried foo.c on up-to-date arm-sid and armel-sid systems, both under qemu and on real hardware and I cannot reproduce the problem; all succeed the same way, for example: [EMAIL PROTECTED]:~$ /usr/bin/gcc-4.2 foo.c [EMAIL PROTECTED]:~$ ./a.out 0xbe92ec84 0x1 0x2 0x3 [EMAIL PROTECTED]:~$ gcc --version gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) So I can only suspect a leisner problem of some kind. If you would like to try reproducing the problem here, please get in touch and I'll arrange access. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458745: arm-only miscompilation of alloca code
Herbert, do you think you could take a quick long at this bug report
before I forward it upstream to the GCC folks?
* Camm Maguire [EMAIL PROTECTED] [2008-01-02 10:09]:
Package: gcc-4.2
Version: 4.2.2-4
Severity: important
/tmp/foo.c:
=
#include stdio.h
#include alloca.h
#include stdarg.h
#define object void *
int VFUN_NARGS;
void *alloca_val;
struct cons {
object c_cdr;
object c_car;
};
#define Cnil 0
static void
foo(object first,...) {
va_list ap;
int narg = VFUN_NARGS;
struct cons *V1128;
object V1129;
va_start(ap,first);
V1129 =
!narg? Cnil : (alloca_val=alloca((narg)*sizeof(struct
cons)+sizeof(object)),
({object _b=(void *)alloca_val;if (((unsigned
long)_b)sizeof(_b)) _b++;
{register struct cons *_p=(void *)_b;
{struct cons *_e=_p+(narg-1);
for (;_p_e;_p++) {_p-c_car=({object
_t=first;first=va_arg(ap,object);_t;});_p-c_cdr=(object)(_p+1);}}
_p-c_car=first;_p-c_cdr=Cnil;}_b;}));
va_end(ap);
V1128= V1129;
for (;V1128!=Cnil;V1128=V1128-c_cdr)
printf(%p\n,V1128-c_car);
}
int
main(int argc,char * argv[]) {
VFUN_NARGS=4;
foo(argc,1,2,3);
return 0;
}
=
i386 sid:
=
cc -g /tmp/foo.c -o /tmp/foo
/tmp/foo
0xbf867bd0
0x1
0x2
0x3
=
leisner dchroot sid:
=
cc -g foo.c -o foo
./foo
0x18beed5d
Segmentation fault
=
Take care,
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.20-gen
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages gcc-4.2 depends on:
ii binutils2.18.1~cvs20071027-1 The GNU assembler, linker and
bina
ii cpp-4.2 4.2.2-4 The GNU C preprocessor
ii gcc-4.2-base4.2.2-4 The GNU Compiler Collection
(base
ii libc6 2.7-2GNU C Library: Shared libraries
ii libgcc1 1:4.2.2-4GCC support library
ii libgomp14.2.2-4 GCC OpenMP (GOMP) support library
Versions of packages gcc-4.2 recommends:
ii libc6-dev 2.7-2 GNU C Library: Development
Librari
-- no debconf information
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458745: arm-only miscompilation of alloca code
On Wed, 2008-01-02 at 20:02 +0100, Martin Michlmayr wrote: Herbert, do you think you could take a quick long at this bug report before I forward it upstream to the GCC folks? well, I couldn't reproduce that on a Debian EABI system with ii gcc 4:4.2.2-1 The GNU C compiler ii libc6 2.7-5 GNU C Library: Shared libraries no segfaults here... :-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458745: arm-only miscompilation of alloca code
Greetings! May I add that eliminating this code resolved the issue present in http://buildd.debian.org/fetch.cgi?pkg=gclcvsver=2.7.0-82arch=armstamp=1198067608file=log as shown in http://buildd.debian.org/fetch.cgi?pkg=gclcvsver=2.7.0-83arch=armstamp=1199286999file=log Is EABI the old arm, or the new? Couldn't this make a difference? Take care, Herbert Valerio Riedel [EMAIL PROTECTED] writes: On Wed, 2008-01-02 at 20:02 +0100, Martin Michlmayr wrote: Herbert, do you think you could take a quick long at this bug report before I forward it upstream to the GCC folks? well, I couldn't reproduce that on a Debian EABI system with ii gcc 4:4.2.2-1 The GNU C compiler ii libc6 2.7-5 GNU C Library: Shared libraries no segfaults here... :-/ -- Camm Maguire[EMAIL PROTECTED] == The earth is but one country, and mankind its citizens. -- Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458745: arm-only miscompilation of alloca code
Greetings! Martin Guy [EMAIL PROTECTED] writes: I just tried foo.c on up-to-date arm-sid and armel-sid systems, both under qemu and on real hardware and I cannot reproduce the problem; all succeed the same way, for example: [EMAIL PROTECTED]:~$ /usr/bin/gcc-4.2 foo.c [EMAIL PROTECTED]:~$ ./a.out 0xbe92ec84 0x1 0x2 0x3 [EMAIL PROTECTED]:~$ gcc --version gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) So I can only suspect a leisner problem of some kind. If you would like to try reproducing the problem here, please get in touch and I'll arrange access. This would be very helpful, if convenient for you. I'm confused about the different versions of arm and Debian. Take care, -- Camm Maguire[EMAIL PROTECTED] == The earth is but one country, and mankind its citizens. -- Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458745: arm-only miscompilation of alloca code
* Herbert Valerio Riedel [EMAIL PROTECTED] [2008-01-02 22:13]: well, I couldn't reproduce that on a Debian EABI system with ii gcc 4:4.2.2-1 The GNU C compiler ii libc6 2.7-5 GNU C Library: Shared libraries no segfaults here... :-/ I get ./t(sid)[EMAIL PROTECTED]:~$ ./t2 0x18be8ebb (nil) on a box with EABI kernel an old ABI chroot. I see the segfault on leisner (the box Camm probably used). -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
