* Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote: > On Tue, Apr 11, 2017 at 07:09:07AM -0700, Andi Kleen wrote: > > > I'll look closer (building proccess it's rather complicated), but my > > > understanding is that VDSO is stand-alone binary and doesn't really links > > > with the rest of the kernel, rather included as blob, no? > > > > > > Andy, may be you have an idea? > > > > There isn't any way I know of to directly link them together. The ELF > > format wasn't designed for that. You would need to merge blobs and then use > > manual jump vectors, like the 16bit startup code does. It would be likely > > complicated and ugly. > > Ingo, can we proceed without coverting this assembly to C? > > I'm committed to convert it to C later if we'll find reasonable solution > to the issue. So one way to do it would be to build it standalone as a .o, then add it not to the regular kernel objects link target (as you found out it's not possible to link 32-bit and 64-bit objects), but to link it in a manual fashion, as part of vmlinux.bin.all-y in arch/x86/boot/compressed/Makefile. But there would be other complications with this approach, such as we'd have to add a size field and there might be symbol linking problems ... Another, pretty hacky way would be to generate a .S from the .c, then post-process the .S and essentially generate today's 32-bit .S from it. Probably not worth the trouble. Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
