Am 19.11.2015 um 23:50 schrieb Richard Weinberger: > Hi! > > UML recently had an interesting bug[1] where the host side of UML > tried to call sigsuspend() but as the kernel itself offers a function > with the same name it called sigsuspend() on > the UML kernel side and funny things happened. > > The root cause of the problem is that the UML links userspace > code like glibc, libpcap, etc. to the kernel image and symbols can > clash. Especially if one side is a shared library it will not noticed > at compile time. > > As this is not the first bug of this kind I'm facing on UML I've > started to think how to deal with that. > > Is it somehow possible to limit the linker scope? > Such that we can force LD no not blindly link every symbols of > vmlinux into another object? Maybe using a white list? > I have do admit I've never used LD scripts nor GNU export maps, > maybe they can help. Currently I'm reading their docs and hope > to find a way to implement my idea. > > The problem is also not specific to UML, the emerging Linux Kernel > Library will suffer from the same issue. I take this back. LKL continues to impress me. It creates a new kernel object using objcopy -G and marks only some symbols as global. This approach could work for UML too. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
