WEIRD! div() broken on -CURRENT?
Okay, I must be losing my mind. Does anyone know why the following
program compiled with stock gcc-3.2.1, stock CFLAGS, and no CPUTYPE
produces:
ddy.quot = 1
ddy.rem = -1077937744
on -CURRENT, and:
ddy.quot = 8
ddy.rem = 0
On -stable?
#include
#include
main(void) {
div_t ddy;
int dy, dy_frac;
ddy = div (768, 96);
dy = ddy.quot;
dy_frac = ddy.rem;
printf("ddy.quot = %d\n", dy);
printf("ddy.rem = %d\n", dy_frac);
return 0;
}
> cc -O -pipe -o xxx xxx.c
I'm doing something wrong, right? I mean, this can't be right. I've
verified this now on a P4 running:
FreeBSD jclarke-pc.cisco.com 5.0-RC FreeBSD 5.0-RC #0: Mon Dec 16
02:54:55 EST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/JCLARKE-PC i386
And a PIII running:
FreeBSD sysinfo.mezzweb.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Dec
16 09:44:28 CST 2002
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/BSDROCKS i386
Both machines produce the same result, while my -stable machines produce
the correct result. Both machines have fresh -CURRENT headers. Oh, and
if I move the xxx binary from my -stable machine to my -CURRENT machine,
it produces the correct result. Both machines have WITNESS and
INVARIANTS disabled. The PIII has MATH_EMULATE compiled in, but the P4
does not. Any help would be most appreciated as I think this is causing
Nautilus crashes on -CURRENT. Thanks.
Joe
--
PGP Key : http://www.marcuscom.com/pgp.asc
signature.asc
Description: This is a digitally signed message part
Re: WEIRD! div() broken on -CURRENT?
On Fri, Dec 20, 2002 at 09:24:39PM -0500, Joe Marcus Clarke wrote:
> Okay, I must be losing my mind. Does anyone know why the following
> program compiled with stock gcc-3.2.1, stock CFLAGS, and no CPUTYPE
> produces:
>
> ddy.quot = 1
> ddy.rem = -1077937744
>
> on -CURRENT, and:
>
> ddy.quot = 8
> ddy.rem = 0
>
> On -stable?
>
> #include
> #include
>
> main(void) {
> div_t ddy;
> int dy, dy_frac;
>
> ddy = div (768, 96);
> dy = ddy.quot;
> dy_frac = ddy.rem;
>
> printf("ddy.quot = %d\n", dy);
> printf("ddy.rem = %d\n", dy_frac);
>
> return 0;
> }
>
> > cc -O -pipe -o xxx xxx.c
>
> I'm doing something wrong, right? I mean, this can't be right. I've
> verified this now on a P4 running:
[...]
I can reproduce it here. It looks like gcc is using a strange calling
convention that the i386 div.S does not understand (MI div.c seems to, though).
It's generating the following code:
0x8048541 : mov$0x0,%eax
0x8048546 :sub%eax,%esp
0x8048548 :lea0xfff8(%ebp),%eax
0x804854b :sub$0x4,%esp
0x804854e :push $0x60
0x8048550 :push $0x300
0x8048555 :push %eax
0x8048556 :call 0x80483ec
0x804855b :add$0xc,%esp
At the time of the call to div():
(gdb) x/4w $esp
0xbfbffbbc: 0x0804855b 0xbfbffbe8 0x0300 0x0060
It looks like gcc might be pushing the address of "ddy" and expecting div()
to put the result in there.
Microsoft C 12 generates this code:
sub esp, 8
push96 ; 0060H
push768 ; 0300H
call_div
add esp, 8
mov DWORD PTR [ebp], eax
mov DWORD PTR [ebp+4], edx
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: WEIRD! div() broken on -CURRENT?
* De: Tim Robbins <[EMAIL PROTECTED]> [ Data: 2002-12-20 ] [ Subjecte: Re: WEIRD! div() broken on -CURRENT? ] > On Fri, Dec 20, 2002 at 09:24:39PM -0500, Joe Marcus Clarke wrote: > > I'm doing something wrong, right? I mean, this can't be right. I've > > verified this now on a P4 running: > [...] > > I can reproduce it here. It looks like gcc is using a strange calling > convention that the i386 div.S does not understand (MI div.c seems to, though). TenDRA and GCC3 use a different struct return format than we used to use (see http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01783.html) and we never had a flag day for the old format, and there's no UPDATING or whatnot notes about this AFAIK. This means at least div has to change to use the new calling convention. Of course, this only applies to things in assembly, as everything else returning a struct (in C) already uses the format of the compiler that compiled it. Sure changing div will break dynamically linked programs using the old calling convention, but anything else returning a struct has already gone through this. This will only affect non-native compilers generating code on a running FreeBSD 5 system which use the old struct return format. Older FreeBSD programs will of course use the old format with an old libc using the old format, and so it will work if compatability libraries are used. What we need now is a belated UPDATING, HEADS UP, as surely this will affect some edge case, much like the __sF hiding did, though certainly not that exact same edge case. More likely someone calling div() in libc from assembly (though why they'd do that is beyond me). Thanx, juli. -- Juli Mallett <[EMAIL PROTECTED]> OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WEIRD! div() broken on -CURRENT?
On Fri, Dec 20, 2002 at 08:43:25PM -0800, Juli Mallett wrote: > * De: Tim Robbins <[EMAIL PROTECTED]> [ Data: 2002-12-20 ] > [ Subjecte: Re: WEIRD! div() broken on -CURRENT? ] > > On Fri, Dec 20, 2002 at 09:24:39PM -0500, Joe Marcus Clarke wrote: > > > I'm doing something wrong, right? I mean, this can't be right. I've > > > verified this now on a P4 running: > > [...] > > > > I can reproduce it here. It looks like gcc is using a strange calling > > convention that the i386 div.S does not understand (MI div.c seems to, though). > > TenDRA and GCC3 use a different struct return format than we used to > use (see http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01783.html) and > we never had a flag day for the old format, and there's no UPDATING or > whatnot notes about this AFAIK. This means at least div has to change > to use the new calling convention. [...] I've imported the versions of div.S and ldiv.S from NetBSD HEAD which work properly with the new calling convention. Thanks for mentioning (on IRC) that the pcc struct return convention had something to do with it. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WEIRD! div() broken on -CURRENT?
On Sat, 21 Dec 2002, Tim Robbins wrote: > On Fri, Dec 20, 2002 at 08:43:25PM -0800, Juli Mallett wrote: > > > * De: Tim Robbins <[EMAIL PROTECTED]> [ Data: 2002-12-20 ] > > [ Subjecte: Re: WEIRD! div() broken on -CURRENT? ] > > > On Fri, Dec 20, 2002 at 09:24:39PM -0500, Joe Marcus Clarke wrote: > > > > I'm doing something wrong, right? I mean, this can't be right. I've > > > > verified this now on a P4 running: > > > [...] > > > > > > I can reproduce it here. It looks like gcc is using a strange calling > > > convention that the i386 div.S does not understand (MI div.c seems to, though). > > > > TenDRA and GCC3 use a different struct return format than we used to > > use (see http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01783.html) and > > we never had a flag day for the old format, and there's no UPDATING or > > whatnot notes about this AFAIK. This means at least div has to change > > to use the new calling convention. > [...] > > I've imported the versions of div.S and ldiv.S from NetBSD HEAD which > work properly with the new calling convention. Thanks for mentioning (on IRC) > that the pcc struct return convention had something to do with it. Did we really mean to change this? It is a relatively recent change. From cvs history: % RCS file: /home/ncvs/src/contrib/gcc/config/freebsd.h,v % Working file: freebsd.h % head: 1.37 % ... % % revision 1.37 % date: 2002/04/30 17:22:42; author: obrien; state: Exp; lines: +34 -460 % MI bits for Gcc 3.1. % This contains mounds changes, one of which breaks 5-10 (?) years of binary compatibility within gcc-compiled objects: % Index: freebsd.h % === % RCS file: /home/ncvs/src/contrib/gcc/config/freebsd.h,v % retrieving revision 1.36 % retrieving revision 1.37 % diff -u -2 -r1.36 -r1.37 % --- freebsd.h 14 May 2001 22:45:26 - 1.36 % +++ freebsd.h 30 Apr 2002 17:22:42 - 1.37 % ... % -/* Don't default to pcc-struct-return, because gcc is the only compiler, and % - we want to retain compatibility with older gcc versions % - (even though the SVR4 ABI for the i386 says that records and unions are % - returned in memory). */ % -#undef DEFAULT_PCC_STRUCT_RETURN % -#define DEFAULT_PCC_STRUCT_RETURN 0 I think gcc didn't override its default of DEFAULT_PCC_STRUCT_RETURN = 1 on i386's meany years ago, since bcc uses this method of returning structs and ISTR copying the gcc behaviour. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WEIRD! div() broken on -CURRENT?
On Sun, Dec 22, 2002 at 10:40:33AM +1100, Bruce Evans wrote: > > that the pcc struct return convention had something to do with it. > > Did we really mean to change this? It is a relatively recent change. From > cvs history: > > % RCS file: /home/ncvs/src/contrib/gcc/config/freebsd.h,v > % Working file: freebsd.h > % head: 1.37 > % ... > % > % revision 1.37 > % date: 2002/04/30 17:22:42; author: obrien; state: Exp; lines: +34 -460 > % MI bits for Gcc 3.1. > % > > This contains mounds changes, one of which breaks 5-10 (?) years of binary > compatibility within gcc-compiled objects: Actually only a 4 years -- the a.out->ELF cut over broke the "5-10 years of binary compatibility". As mentioned at http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01783.html we really made a mistake when we did the a.out->ELF cut over thus resulting in us breaking the i386 ELF ABI. I have wondered in the past how this affects is with sharing XFree86 binary modules with Linux. That said, the ABI change was not intentional. It was a GCC bug. > % RCS file: /home/ncvs/src/contrib/gcc/config/freebsd.h,v ... > % -#undef DEFAULT_PCC_STRUCT_RETURN > % -#define DEFAULT_PCC_STRUCT_RETURN 0 I moved this setting from the MI file to the i386 MD file. > I think gcc didn't override its default of DEFAULT_PCC_STRUCT_RETURN = 1 > on i386's meany years ago, since bcc uses this method of returning structs > and ISTR copying the gcc behaviour. AFAIK, stock GCC always used DEFAULT_PCC_STRUCT_RETURN=1 for i386 ELF. DEFAULT_PCC_STRUCT_RETURN=0 was the a.out default, as there wasn't a standard one had to adhear to. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WEIRD! div() broken on -CURRENT?
> Actually only a 4 years -- the a.out->ELF cut over broke the "5-10 years > of binary compatibility". As mentioned at > http://gcc.gnu.org/ml/gcc-patches/2002-01/msg01783.html we really made a > mistake when we did the a.out->ELF cut over thus resulting in us breaking > the i386 ELF ABI. I have wondered in the past how this affects is with > sharing XFree86 binary modules with Linux. Hmm, I've been running GATOS binary modules built for Linux to provide XV support for an ATI Mobility Pro LY for some time (at least 6-8 months and some 4-5 different "experimental" versions so far, all have worked great): andy@tureg[39]-> xvinfo X-Video Extension version 2.2 screen #0 Adaptor #0: "ATI mach64 Video Overlay" number of ports: 1 port base: 55 operations supported: PutImage supported visuals: depth 16, visualID 0x23 depth 16, visualID 0x24 depth 16, visualID 0x25 depth 16, visualID 0x26 number of attributes: 17 "XV_DEVICE_ID" (range 0 to -1) client gettable attribute (current value is 86) "XV_LOCATION_ID" (range 0 to -1) client gettable attribute (current value is 87) "XV_INSTANCE_ID" (range 0 to -1) client gettable attribute (current value is 88) "XV_SET_DEFAULTS" (range 0 to 1) client settable attribute "XV_AUTOPAINT_COLORKEY" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) "XV_COLORKEY" (range 0 to -1) client settable attribute client gettable attribute (current value is 6208) "XV_DOUBLE_BUFFER" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) "XV_ENCODING" (range 0 to 12) client settable attribute client gettable attribute (current value is 1) "XV_FREQ" (range 0 to -1) client settable attribute client gettable attribute (current value is 1000) "XV_TUNER_STATUS" (range -1000 to 1000) client gettable attribute (current value is 4) "XV_MUTE" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) "XV_VOLUME" (range -1000 to 1000) client settable attribute client gettable attribute (current value is -1000) "XV_BRIGHTNESS" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_SATURATION" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 16) "XV_COLOR" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 16) "XV_HUE" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 2048 x 2048 Number of image formats: 4 id: 0x32595559 (YUY2) guid: 59555932--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x59565955 (UYVY) guid: 55595659--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) Seems to work pretty well from a stability POV, no issues that I could point at the module for. And certainly the hardware scaling and color transforms work way better than they do without the module ;-) Cheers, AS msg49272/pgp0.pgp Description: PGP signature
Re: WEIRD! div() broken on -CURRENT?
Andy Sparrow ([EMAIL PROTECTED]) napisał(a): > > Hmm, I've been running GATOS binary modules built for Linux to provide > XV support for an ATI Mobility Pro LY for some time (at least 6-8 months > and some 4-5 different "experimental" versions so far, all have worked > great): Btw. GATOS compiles from source fine for me (I use extracted X server port for that). I use driver compiled from GATOS CVS two months ago fine on my VAIO FX-604 without any problems. -- << Marcin Cieslak // [EMAIL PROTECTED] >> msg49352/pgp0.pgp Description: PGP signature
