Date: Tue, 12 Aug 2003 11:20:36 -0400 From: ari <edelkind-freebsd-stable@episec.com> To: freebsd-stable@freebsd.org Subject: linprocfs: extern declaration of a static variable Message-ID: <20030812152036.GD1746@episec.com>
next in thread | raw e-mail | index | archive | help
I didn't get much (read: any) feedback from the freebsd-emulation list on this, so i'm passing it on myself. My original post can be found at: http://lists.freebsd.org/pipermail/freebsd-emulation/2003-August/000136.html A few days ago, i found myself in need of mounting a vmware image on my old 4.7-STABLE system. To do this, i needed linprocfs functioning properly, but this module failed with an "exec format error". Further investigation revealed that nextpid was undefined. So i checked the source, and discovered that in kern/kern_fork.c, nextpid was defined statically. It was defined nowhere else, but in i386/linux/linprocfs/linprocfs_misc.c, it was declared "extern". Since the system needed a new pair of shoes anyway, i promptly upgraded it to 4.8-STABLE. To my surprise, i found that nothing had changed. The nextpid variable was still defined as a "static int" in kern_fork.c, and it was still requested externally in linprocfs.c. And, obviously, the module still couldn't be loaded. I removed the "static" tag in kern_fork.c, recompiled, and everything was fine. What's odd isn't that this wasn't functioning properly. What's odd is that it _does_ function properly for some. Indeed, i also have a 4.8-RELEASE system, using the very same tidbits of code, and linprocfs.ko loads perfectly. In the working module, nm reports that nextpid is still undefined, and in the otherwise linked kernel, nm reports that nextpid is still a local variable: % nm -A /modules/linprocfs.ko /kernel |grep nextpid /modules/linprocfs.ko: U nextpid /kernel:c02c9298 d nextpid I'm not sure why this would have been unchanged from 4.7-STABLE to 4.8-STABLE, as it shouldn't work for _anyone_, barring some compiler bug that exports static variables. In the RELENG_5 kernel tree, the 'nextpid' variable has been changed to 'lastpid', and the static declaration has been removed. So there we have it. I believe it's a bug. Twofold, that is. A bug that it works at all, and a bug that when it works correctly, it doesn't. ari
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030812152036.GD1746>