Bug 208464
| Summary: | [svr4] svr4.ko fails to load due to not finding symbol svr4_delete_socket even though it is present in same module | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Kristoffer Eriksson <ske-89> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | cem, dchagin, i386 |
| Priority: | --- | Keywords: | patch |
| Version: | 10.2-RELEASE | ||
| Hardware: | i386 | ||
| OS: | Any | ||
| Attachments: | |||
Created attachment 169112 [details]
Patch for dependencies between svr4.ko & streams.ko due to symbols svr4_delete_socket & svr4_stream_get
This attachment fixes the bug with both svr4.ko & streams.ko complaining about undefined symbol svr4_delete_socket. The symbol is present in svr4.ko, but was not found. Additionally fixes the same problem in reverse for the symbol svr4_stream_get, which was revealed after the first fix. These created a two-way dependency between the two modules, preventing both of them from being loaded.
Moved EXPORT_SYMS=svr4_delete_socket from modules/streams/Makefile to modules/svr4/Makefile. The function had already moved from streams.ko to svr4.ko in revision 160558 in 2006, but EXPORT_SYMS was not updated.
Added MODULE_DEPEND(streams, svr4elf) to dev/streams/streams.c to reflect this, and a matching MODULE_VERSION to compat/svr4/svr4_sysvec.c. Otherwise streams.ko still didn't find svr4_delete_socket in svr4.ko.
Moved the function svr4_stream_get() from dev/streams/streams.c to compat/svr4/svr4_socket.c like svr4_delete_socket() was already moved in 2006. There were no callers in streams.ko, only in svr4.ko. Included svr4_stropts.h to declare it.
Then removed svr4_stream_get too from EXPORT_SYMS in modules/streams/Makefile for streams.ko. Removed MODULE_DEPEND(svr4elf, streams) from compat/svr4/svr4_sysvec.c, since no calls from svr4.ko to streams.ko remained now. - This dissolves the two-way dependency, leaving only streams.ko depending on svr4.ko to call svr4_delete_socket().
(Alternatively svr4_delete_socket() might perhaps have been moved back to streams.ko, or perhaps even all of svr4_sockets.c could have moved there, or both modules could just as well have been joined into a single module, like it was originally in NetBSD.)
Removed EXPORT_SYMS=svr4_str_initialized, which doesn't exist currently.
The source I patched came from 10.3-RELEASE.
After this I can successfully kldload these modules again.
Created attachment 169113 [details]
Patch for incomplete ifdefs for SYSVMSG/SEM/SHM in svr4.ko preventing separate compilation of the module
Compiling the svr4.ko module in isolation for the svr4_delete_socket bug, I ended up getting complaints from kldload about undefined symbols svr4_sys_msgsys, svr4_sys_semsys, svr4_sys_shmsys.
When running make in sys/modules/svr4/ separately with no parameters, the defines SYSVMSG, SYSVSEM, SYSVSHM are not defined. Code in sys/compat/svr4/svr4_ipc.c #ifdef these, and exclude code for the calls mentioned above when not defined. But the file syscalls.master still referred to them unconditionally, causing the loader to try to find them, but failing.
I added matching #ifdefs to syscalls.master. That fixed it.
I guess this has no effect in the release version, where this calls are not excluded.
The patch in comment 1 looks fine to me. However, I don't have an i386 machine to try building it with. I used a virtual machine in Virtual Box for that. A commit references this bug: Author: dchagin Date: Sat Apr 23 20:29:56 UTC 2016 New revision: 298519 URL: https://svnweb.freebsd.org/changeset/base/298519 Log: Fix streams and svr4 module dependency. Both modules are complaining about undefined symbol svr4_delete_socket which was moved from streams to the svr4 module in r160558 that created a two-way dependency between them. PR: 208464 Submitted by: Kristoffer Eriksson Reported by: Kristoffer Eriksson MFC after: 2 week Changes: head/sys/compat/svr4/svr4_socket.c head/sys/compat/svr4/svr4_sysvec.c head/sys/dev/streams/streams.c head/sys/modules/streams/Makefile head/sys/modules/svr4/Makefile A commit references this bug: Author: dchagin Date: Sat Apr 23 20:31:18 UTC 2016 New revision: 298520 URL: https://svnweb.freebsd.org/changeset/base/298520 Log: Allow to build svr4 module with SYSV support separatelly from the kernel build. PR: 208464 Reported by: Kristoffer Eriksson MFC after: 2 week Changes: head/sys/compat/svr4/svr4_ipc.c A commit references this bug: Author: dchagin Date: Sat May 7 08:26:06 UTC 2016 New revision: 299214 URL: https://svnweb.freebsd.org/changeset/base/299214 Log: MFC r298519: Fix streams and svr4 module dependency. Both modules are complaining about undefined symbol svr4_delete_socket which was moved from streams to the svr4 module in r160558 that created a two-way dependency between them. MFC r298520: Allow to build svr4 module with SYSV support separatelly from the kernel build. PR: 208464 Reported by: Kristoffer Eriksson Changes: _U stable/9/sys/ stable/9/sys/compat/svr4/svr4_ipc.c stable/9/sys/compat/svr4/svr4_socket.c stable/9/sys/compat/svr4/svr4_sysvec.c _U stable/9/sys/dev/ stable/9/sys/dev/streams/streams.c _U stable/9/sys/modules/ stable/9/sys/modules/streams/Makefile _U stable/9/sys/modules/svr4/ stable/9/sys/modules/svr4/Makefile A commit references this bug: Author: dchagin Date: Sat May 7 08:30:22 UTC 2016 New revision: 299215 URL: https://svnweb.freebsd.org/changeset/base/299215 Log: MFC r298519: Fix streams and svr4 module dependency. Both modules are complaining about undefined symbol svr4_delete_socket which was moved from streams to the svr4 module in r160558 that created a two-way dependency between them. MFC r298520: Allow to build svr4 module with SYSV support separatelly from the kernel build. PR: 208464 Reported by: Kristoffer Eriksson Changes: _U stable/10/ stable/10/sys/compat/svr4/svr4_ipc.c stable/10/sys/compat/svr4/svr4_socket.c stable/10/sys/compat/svr4/svr4_sysvec.c stable/10/sys/dev/streams/streams.c stable/10/sys/modules/streams/Makefile stable/10/sys/modules/svr4/Makefile thanks |
When I try to "kldload svr4.ko" I get this error: link_elf: symbol svr4_delete_socket undefined KLD svr4.ko: depends on streams - not available or version mismatch kldload: can't load svr4: No such file or directory This would appear to say that streams.ko might need to be loaded before svr4.ko to provide the symbol svr4_delete_socket. That is not correct, though. Loading streams.ko also complains that svr4_delete_socket is undefined. Checking the revision histories and source code for svr4.ko and streams.ko, I noticed that svr4_delete_socket() was moved from streams.c to svr4_socket.c in July 2006. https://svnweb.freebsd.org/base?view=revision&revision=160558 So now svr4_delete_socket is an internal symbol of the svr4.ko module. So link_elf shouldn't need to import it at all when loading svr4.ko. There seems to be some mixup regarding which module this symbol belongs to. Next thing I noticed is that there is still an "EXPORT_SYMS=svr4_delete_socket" in the Makefile for the streams module, where the symbol does no longer exist. And there is no such EXPORT_SYMS in the Makefile for the svr4 module, where the symbol currently lives. I would assume this should have been moved together with the source code for svr4_delete_socket(), but was overlooked. https://svnweb.freebsd.org/base/head/sys/modules/streams/Makefile?view=markup https://svnweb.freebsd.org/base/head/sys/modules/svr4/Makefile?view=markup I'm not experienced enough with FreeBSD kernel source to know for sure if this is really the whole story, but to me it seems like a good explanation for the bug. I don't see any other mention of svr4_delete_socket when searching the source code, that would explain this symtom. Can we get this fixed, so svr4.ko and streams.ko can be loaded again? It seems a pity having such a simple bug preventing their use. I'm not equipped to try to fix this myself, otherwise I would. - I tried this out on FreeBSD-10.2-RELEASE-i386-bootonly.iso and FreeBSD-10.1-RELEASE-i386-bootonly.iso. The same problem occurs also with 8.0-RELEASE-i386-livefs.iso, except there you need to check dmesg to see the message from link_elf. Given the explanation and date above, I would assume the same occurs in release 7 too, but I didn't test it. I have also discussed this in the forum thread https://forums.freebsd.org/threads/55617/ I didn't find any previous problem reports about this. There have been various forum discussions mentioning not being able to use these modules on various releases, but not very detailed.