On Sunday 27 June 2004 00:27, you wrote: > For some reason, gcc-2.95.4 dies horridly on those asmlinkage > declarations. > > I was unable to work out _why_ those functions have asmlinkage, as there > seem to be no instances of them - nobody calls > pwc_register_decompressor(). What's up with that?
What's up with this is that the latest 2.6 kerneld have an experimental feature "Use register arguments"; it compiles the kernel code with -mregparm=3, which changes the way parameters are passed to a function. Unfortunately, this goes horribly wrong when you call a function in a library or object file that is compiled with the (default) regparm=0. And this is exactly what happened in PWCX (I noticed that just in time before releasing the beta-2). PWCX is the decompressor part of the PWC driver, which is maintained as a separate module, and has a binary-only part in the form of a library (libpwcx.a). Calling that binary-only part is where things went wrong, even though there is a small piece of 'glue' C code, since that glue code is compiled as kernel module (regparm=3), and the library is not (regparm=0). So I needed to have a way to specify _exactly_ how the parameters are passed to the function, and 'asmlinkage' does just that. In this case, however, the fault lies entirely with GCC. There are numerous functions in the kernel that have an 'asmlinkage' specifier, so where's the problem then? Well, GCC 2.95 doesn't like attribute()s on function _pointer_ arguments, and that's exactly what is being used in "struct pwc_decompressor" (If you look at the code you'll understand why I choose this approach) GCC 3.2 doesn't have a problem with this attribute() on function pointers. The "Use register arguments" is on by default in the 2.6 kernels (why an *experimental* feature is by default *on* eludes me at this moment :-P). Unfortunately, from the outside you can't tell whether the kernel is being compiled with regparm=0 or regparm=3. The alternative would be to compile two different version of libpwcx.a, but considering I'm already cross-compiling for 7 different architectures and the only sure way to find out if you used the wrong version of the library is by a kernel Oops, I think 'asmlinkage' is an acceptable solution. But that still leaves us with the GCC 2.95 compile error... In my opinion, the best solution is to make the asmlinkage conditional on the compiler version. Since the default for GCC 2.95 is regparm=0, and that is exactly what 'asmlinkage' enforces, that shouldn't give any problems (ie. compiling on GCC 2.95 without asmlinkage is the same as regparm=0). IŽll send out a patch soon, however the solution from Andrew will cause problems for people on GCC 3, kernel 2.6 and the default kernel settings. Actually, I'm still surprised at the number of GCC 2.95 compilers in use today... I would have thought they would have been extinct by now (but then again, people are still using DOS programs and Windows98, so who am I fooling...) - Nemosoft ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel