Re: RFC Marking private symbols in XFree86 shared libraries as private
On Thu, Oct 09, 2003 at 09:01:15PM -0400, David Dawes wrote: Well, both version script and __attribute__((visibility (hidden))) can be used at the same time. Anonymous version script works in 2001-12-18 and later binutils and AFAIK in Solaris linker. No idea about other arches. If you think we should list all exported symbols, then maybe we could introduce .sym (or .api) files for each library which would list exported symbols one per line and Imakefile hacks to generate version scripts/whatever else on the fly and use it during linking. That sounds like a good approach. There are two ways that this is already done for some platforms. OS/2 and Cygwin use files like X11-def.cpp to list the exported symbols. Those lists might be a good starting point, but I suspect that more symbols are exported than are documented in the API specs. Also, X11R6.3 added export description files (like libX11.elist), together with scripts for a few platforms like Solaris, HPUX and AIX to process them. The .elist files are only provided for libX11 and libXt, and they simply export all globals. I don't know if the basic mechanism is worth reusing -- you should look at it and see what you think. They don't provide any useful information about what symbols should be exported for each library though. I'd say it would be better to reuse *-def.cpp files (didn't know something like that existed). They are preprocessed, so it is easy to add __linux__, whatever else, also arch specific symbols, whatever necessary. Transforming *-def.cpp files to anonymous version scripts should be trivial, whether done in lnxLib.rules, sunLib.rules or some special script. Given that there are just a handful of -shared links in whole XFree86 build, perhaps the rule can (in lnxLib.rules) first check whether ld actually supports anynymous version scripts and only use them if it does. Second thing is how to define Imakefile macros which will enable __attribute__((visibility (hidden))) and/or version scripts. Should they be just user settable, defaulting to no, or should imake do the autodetection (for that it needs an autoconf like test, since e.g. even when you have GCC 3.3 and later, still visibility attribute doesn't have to be supported if that GCC was compiled against old binutils, etc.)? What happens if you use the visibility attribute with a gcc 3.3 that doesn't have it enabled? If it's simply ignored, then it shouldn't be an issue. Otherwise, is there no pre-defined macro so that you can test for it in the source? There is no predefined macro, the attribute is ignored if not supported, but with a warning: If it is GCC which has visibility attribute support but that attribute is not supported in its particular configuration (linked against old binutils, not using binutils or architectire which doesn't support it), you get: visibility attribute not supported in this configuration; ignored warning, if it is GCC without visibility attribute support (e.g. older releases), you get: `visibility' attribute directive ignored warning. I don't know how much XFree86 relies on being warning free. GCC 3.3+ on Linux will typically be configured such that this attribute is supported and give no warning (dunno about *BSD etc.), so it would issue warnings just in a few configurations. Jakub ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RFC Marking private symbols in XFree86 shared libraries as private
Jakub, I just noticed this thread today. If this will have problems, then they will definitely be visible on Cygwin. So, I ask that I please be included in the testing process before this is committed, if it ever is. I would gladly do test builds under Cygwin to confirm that the new scheme works. Harold Jakub Jelinek wrote: On Thu, Oct 09, 2003 at 09:01:15PM -0400, David Dawes wrote: Well, both version script and __attribute__((visibility (hidden))) can be used at the same time. Anonymous version script works in 2001-12-18 and later binutils and AFAIK in Solaris linker. No idea about other arches. If you think we should list all exported symbols, then maybe we could introduce .sym (or .api) files for each library which would list exported symbols one per line and Imakefile hacks to generate version scripts/whatever else on the fly and use it during linking. That sounds like a good approach. There are two ways that this is already done for some platforms. OS/2 and Cygwin use files like X11-def.cpp to list the exported symbols. Those lists might be a good starting point, but I suspect that more symbols are exported than are documented in the API specs. Also, X11R6.3 added export description files (like libX11.elist), together with scripts for a few platforms like Solaris, HPUX and AIX to process them. The .elist files are only provided for libX11 and libXt, and they simply export all globals. I don't know if the basic mechanism is worth reusing -- you should look at it and see what you think. They don't provide any useful information about what symbols should be exported for each library though. I'd say it would be better to reuse *-def.cpp files (didn't know something like that existed). They are preprocessed, so it is easy to add __linux__, whatever else, also arch specific symbols, whatever necessary. Transforming *-def.cpp files to anonymous version scripts should be trivial, whether done in lnxLib.rules, sunLib.rules or some special script. Given that there are just a handful of -shared links in whole XFree86 build, perhaps the rule can (in lnxLib.rules) first check whether ld actually supports anynymous version scripts and only use them if it does. Second thing is how to define Imakefile macros which will enable __attribute__((visibility (hidden))) and/or version scripts. Should they be just user settable, defaulting to no, or should imake do the autodetection (for that it needs an autoconf like test, since e.g. even when you have GCC 3.3 and later, still visibility attribute doesn't have to be supported if that GCC was compiled against old binutils, etc.)? What happens if you use the visibility attribute with a gcc 3.3 that doesn't have it enabled? If it's simply ignored, then it shouldn't be an issue. Otherwise, is there no pre-defined macro so that you can test for it in the source? There is no predefined macro, the attribute is ignored if not supported, but with a warning: If it is GCC which has visibility attribute support but that attribute is not supported in its particular configuration (linked against old binutils, not using binutils or architectire which doesn't support it), you get: visibility attribute not supported in this configuration; ignored warning, if it is GCC without visibility attribute support (e.g. older releases), you get: `visibility' attribute directive ignored warning. I don't know how much XFree86 relies on being warning free. GCC 3.3+ on Linux will typically be configured such that this attribute is supported and give no warning (dunno about *BSD etc.), so it would issue warnings just in a few configurations. Jakub ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Info Membangun ASSET
Yth Bapak/Ibu/Sdr/i Salam Sejahtera, Perkenalkan nama saya Felix, ingin mengajak anda untuk bekerja sama dalam bisnis yang sedang saya tekuni saat ini. Saya mengetahui email address anda dari salah satu web di internet dan saya berpikir bahwa anda menyenangi komunikasi lewat internet. Oleh karenannya, saya ingin membagi kesempatan ini kepada sesama rekan, kesempatan untuk melakukan kerjasama usaha melalui internet. Info bonus : http://visibaru.wnetwork.biz/show.cgi/fcitrajaya/respons/bonus.html Mungkin tawaran ini tidak sesuai bidangnya dengan apa yang anda harapkan, namun tidak ada salahnya bila anda mengetahui informasi mengenai bidang pekerjaan lain yang bisa memberikan penghasilan bagi anda dan keluarga anda. Bisnis yang saya tawarkan ini bahkan bisa anda lakukan walaupun saat ini anda sedang bekerja. Anda tidak perlu meninggalkan pekerjaan anda saat ini. Untuk INFO dan PENDAFTARAN free member anda bisa buka website berikut : http://visibaru.wnetwork.biz/show.cgi/fcitrajaya Terimakasih atas perhatiannya, mohon maaf jika saya mengganggu waktu anda. Salam Sukses, Felix Citrajaya Associate Distributor ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: What about a kernel module?
Mark Vojkovich wrote: On Wed, 8 Oct 2003, Emmanuel ALLAUD wrote: Juliusz Chroboczek wrote: I'd like to suggest that you implement device-specific code as a kernel module. Well, that won't happen; we already have working portable driver code in userspace, and there's no chance we'll port that to the Linux kernel. On the other hand, I do think that we'll end up using more kernel-side functionality than we currently do; perhaps someday we'll have enough of that to be able to run non-root servers, at least on hardware that does memory-mapped I/O (the iopl system call is for root only). TR The key problem with this is that kernel modules are Linux-specific, and TR further often need to be kernel-version specific. XFree86 runs quite well TR in many non-Linux environments today. But that doesn't prevent it from using features specific to Linux when needed. Notice for example the use of the vm86old syscall in the Linux/i386 version of the int10 module, or the (optional) use of fbdev in quite a few drivers, or the future use of the /dev/input/event devices (hint, hint). Let alone the DRI. Implementing a kernel module might give access to more resources, like tighter console control, asynchronous accelerations, TR No, I don't think any of that is true. DMA? Smarter polling of FIFO status? Retrace interrupt? For this specific problem : I talked with M. Vojkovich about the yielding problem in that case, then we brought this to linux kernel guys (R. Russel and R. Love), both agreed to say that using sched_yield() will be really incorrect in 2.6, certainly to too much latency. They also both agreed to say that the solution is to use futex to sync the user space driver with the help of a kernel side which would poll the FIFO status (or whatever other conditions we want to wait for). They seemed to be interested in supporting that, so perhaps a joint effort could be successful on both sides so kernel can provide new services the X server could use. Bye Manu This is more of a hack than a solution. I still see little utility in a kernel module. I agree that we have to think of the usefullness of a kernel module. But I am pretty sure there are other problems which can be solved using it, moreover if the implementation is good, it could give us a clean API for hardware things (like DMA or whatever), think of the /dev/rtc as pointed earlier in this thread. Anyways I think it is worth to try and see what it can achieve (by the way does anybody know if DRI people have the same problem with FIFO/DMA?). Bye Manu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Compile failure CVS with DRI/DRM=NO
Ave I've got a error when I build CVS with #define BuildXF86DRINO #define BuildXF86DRMNO Full host.def below the error message. Distro : debian stable Error: make[6]: Entering directory `/home/mp3project/cvs-build/XFree86-CVS/xc/programs/Xserver/hw/xfree86/drivers/ati' rm -f radeon_driver.o gcc -O2 -march=i686 -pipe -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I. -I../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../programs/Xserver/hw/xfree86/os-support -I../../../../../../programs/Xserver/hw/xfree86 -I../../../../../../programs/Xserver/hw/xfree86/vbe -I../../../../../../programs/Xserver/hw/xfree86/int10 -I../../../../../../programs/Xserver/hw/xfree86/ddc -I../../../../../../programs/Xserver/hw/xfree86/i2c -I../../../../../../programs/Xserver/hw/xfree86/rac -I../../../../../../programs/Xserver/hw/xfree86/ramdac -I../../../../../../programs/Xserver/hw/xfree86/shadowfb -I../../../../../../programs/Xserver/hw/xfree86/xaa -I../../../../../../programs/Xserver/hw/xfree86/xf4bpp -I../../../../../../programs/Xserver/hw/xfree86/xf1bpp -I../../../../../../programs/Xserver/hw/xfree86/vgahw -I../../../../../../programs/Xserver/hw/xfree86/fbdevhw -I../../../../../../programs/Xserver/mfb -I../../../../../../programs/Xserver/fb -I../../../../../../programs/Xserver/mi -I../../../../../../programs/Xserver/miext/shadow -I../../../../../../programs/Xserver/render -I../../../../../../programs/Xserver/Xext -I../../../../../../programs/Xserver/include -I../../../../../../include/fonts -I../../../../../../include/extensions -I../../../../../../exports/include/X11 -I../../../../../.. -I../../../../../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPANORAMIX -DRENDER -DRANDR -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DIN_MODULE -DXFree86Module -c radeon_driver.c radeon_driver.c: In function `RADEONPreInitConfig': radeon_driver.c:1972: warning: unused variable `s' radeon_driver.c: In function `RADEONInitDispBandwidth': radeon_driver.c:5727: structure has no member named `directRenderingEnabled' radeon_driver.c:5728: structure has no member named `agpMode' make[6]: *** [radeon_driver.o] Error 1 Full host.def #define ProjectRoot /usr/X11R6-CVS #define NothingOutsideProjectRoot YES #define BootstrapCFlags -O2 -march=i686 -pipe #define DefaultGcc2i386Opt -O2 -march=i686 -pipe #define DefaultGcc2AxpOpt -O2 -march=i686 -pipe #define DefaultGcc2DebugOpt -O2 -march=i686 -pipe #define OptimizedCDebugFlags-O2 -march=i686 -pipe #define BuildFontServer NO #define BuildFonts NO #define MakeLocalFontDirNO #define FontencCompatibilityYES #define BuildSpeedo NO #define BuildType1 NO #define BuildCIDNO #define BuildFreeType NO #define BuildXTrueType NO #define Build75DpiFonts NO #define Build100DpiFontsNO #define BuildSpeedoFontsNO #define BuildType1Fonts NO #define BuildCIDFonts NO #define BuildCyrillicFonts NO #define BuildLatin2FontsNO #define BuildXAudio NO #define BuildXAServer NO #define XprtServer NO #define XnestServer NO #define XVirtualFramebufferServer NO #define BuildXF86DRINO #define BuildXF86DRMNO #define BuildServersOnlyNO #define XF86CardDrivers dummy v4l nv s3 s3virge vesa vga i740 ati savage sis #define XInputDrivers mouse keyboard wacom void #define HasAgpGart YES #define HasZlib YES #define HasMMXSupport YES #define Has3DNowSupport YES #define HasKatmaiSupportYES ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Compile failure CVS with DRI/DRM=NO
On Fre, 2003-10-10 at 20:56, Martijn Uffing wrote:
radeon_driver.c: In function `RADEONPreInitConfig':
radeon_driver.c:1972: warning: unused variable `s'
radeon_driver.c: In function `RADEONInitDispBandwidth':
radeon_driver.c:5727: structure has no member named
`directRenderingEnabled'
radeon_driver.c:5728: structure has no member named `agpMode'
make[6]: *** [radeon_driver.o] Error 1
Fixed in CVS with this patch.
--
Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
Index: programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.108
diff -p -u -r1.108 radeon_driver.c
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 7 Oct 2003 22:47:12 - 1.108
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 11 Oct 2003 00:28:10 -
@@ -1969,7 +1969,9 @@ static Bool RADEONPreInitConfig(ScrnInfo
GDevPtrdev= pEnt-device;
MessageTypefrom;
unsigned char *RADEONMMIO = info-MMIO;
+#ifdef XF86DRI
const char *s;
+#endif
/* Chipset */
from = X_PROBED;
@@ -5724,9 +5726,11 @@ static void RADEONInitDispBandwidth(Scrn
/* DDR64 SCLK_EFF = SCLK for analysis */
sclk_eff = info-sclk;
} else {
+#ifdef XF86DRI
if (info-directRenderingEnabled)
sclk_eff = info-sclk - (info-agpMode * 50.0 / 3.0);
else
+#endif
sclk_eff = info-sclk;
}
Re: [Dri-devel] Deadlock with radeon DRI
The locking problem is solved, my original analysis was incorrect. The
problem was that DRM_CAS was not correctly implemented on IA64. Thus
this was an IA64 issue only, this is consistent with others who showed
up in a google search describing the problem, all were on IA64.
I have filed an XFree86 bug report on this. I could not find a DRI
specific bug reporting mechanism other than the dri-devel list.
The IA64 implementation of CAS was this:
#define DRM_CAS(lock,old,new,__ret) \
do { \
unsigned int __result, __old = (old); \
__asm__ __volatile__( \
mf\n\
mov ar.ccv=%2\n \
;;\n\
cmpxchg4.acq %0=%1,%3,ar.ccv\
: =r (__result), =m (__drm_dummy_lock(lock)) \
: r (__old), r (new) \
: memory); \
__ret = (__result) != (__old);\
} while (0)
The problem was with the data types given to the cmpxchg4
instruction. All of the lock types in DRM are int's and on IA64 thats
4 bytes wide. The digit suffix cmpxchg4 signifies this instruction
operates on a 4 byte quantity. One might expect then since this
instruction operates on 4 byte values and in DRM the locks are 4 bytes
everything is fine, but it isn't.
The cmpxchg4 instruction operates this way:
cmpxchg4 r1=[r3],r2,ar.ccv
4 bytes are read at the address pointed to by r3, that 32 bit value is
then zero extended to 64 bits. The 64 bit value is then compared to
the 64 bit value stored in appliation register CCV. If the two 64 bit
values are equal then the least significant 4 bytes in r2 are written
back to the address pointed to by r3. The original value pointed to by
r3 is stored in r1. The entire operation is atomic.
The mistake in the DRM_CAS implemenation is that the comparison is 64
bits wide, thus the value stored in ar.ccv (%2 in the asm) must be 64
bits wide and for us that means zero extending the 32 bit old
parameter to 64 bits.
Because of the way GCC asm blocks work to tie C variables and data
types to asm values the promotion of old from unsigned int to
unsigned long was not happening. Thus when old was stored into
ar.ccv its most significant 32 bits contained garbage. (Actually
because of the way GCC generates constants it turns out the upper 32
bits was 0x, this was from the OR of DRM_LOCK_HELD which is
defined as 0x8000, but the compiler generates a 64 bit OR
operation using the immediate value 0x8000, which is legal
because the upper 32 bits are undefined on int (32 bit) operations).
The bottom line is that the test would fail when it shouldn't because
the high 32 bits in ar.ccv were not zero.
One might think that because old was assigned to __old in a local
block which was unsigned int the compiler would know enough when using
this value in the asm to have zero extended it. But that's not true,
in asm blocks its critical to define the asm value correctly so the
compiler can translate between the C code variable and what the asm
code is referring to.
The line:
: r (__old), r (new)
says %2 is mapped by r (__old), in other words put __old in a
general 64 bit register. We've told the compiler to put 64 bits of
__old into a register, but __old is a 32 bit value with its high
order 32 bits undefined. We need to tell the compiler to widen the
type when assigning it to a general register, thus the asm template
type definition needs to be modified with a cast to unsigned long.
: r ((unsigned long)__old), r (new)
Only with this will the compiler know to widen the 32 bit __old value
to 64 bits inside the asm code.
Thanks to Jakub Jelinek who helped me understand the nuances of GCC
asm templates and type conversions.
As a minor side note, definitions of bit flags should be tagged as
unsigned. Thus things like:
#define DRM_LOCK_HELD 0x8000
#define DRM_LOCK_CONT 0x4000
should really be:
#define DRM_LOCK_HELD 0x8000U
#define DRM_LOCK_CONT 0x4000U
John
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Deadlock with radeon DRI
John Dennis wrote: The locking problem is solved, my original analysis was incorrect. The problem was that DRM_CAS was not correctly implemented on IA64. Thus this was an IA64 issue only, this is consistent with others who showed up in a google search describing the problem, all were on IA64. I have filed an XFree86 bug report on this. I could not find a DRI specific bug reporting mechanism other than the dri-devel list. This list is good. Can you put together a patch to correct the behaviour? Keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
