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
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?
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?
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 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?
* 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 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