Re: NetBSD/usermode link issues

[Jason Thorpe <thorpej%me.com@localhost>]

> On Aug 4, 2018, at 7:45 AM, Reinoud Zandijk <reinoud%NetBSD.org@localhost> wrote:
> 
> Hi folks,
> 
> as you might know, i'm currently working on NetBSD/usermode.amd64 but I can
> use some help with the following linking issue:

NetBSD/usermode seems a little wacky in that it's intended to run on some host system, right?  In that regard, it almost sees like it needs to be build like a host tool.

> 
> `./build.sh ... kernel=GENERIC_USERMODE' now compiles the kernel fine and
> (with a little hack) links it fine. Going to the directory and executing the
> resulting kernel with `./netbsd' it segfaults directly. The following will
> make a working kernel: `rm netbsd; make'; this will link the kernel again,
> without using the tools, and will this time result in a working kernel.
> './netbsd' then boots up and asks for its root device. You can kill it with
> `pkill -9 netbsd'.
> 
> The hack mentioned to get ./buil.sh working is explicitly linking crti.o since
> without it it will give unresolved references :
> 
> /usr/sources/cvs.netbsd.org/src-usermode/obj/
> tooldir.NetBSD-8.99.1-amd64/bin/x86_64--netbsd-gcc -static
> -fno-omit-frame-pointer -m64 -Wl,-Map,.map -o netbsd -Ttext 0x7f000000
> ${SYSTEM_OBJ} ${EXTRA_OBJ} vers.o -L/usr/lib -lrt crti.o
> crt0.o: In function `___start':
> (.text+0xde): undefined reference to `_fini'
> crt0.o: In function `___start':
> (.text+0xe8): undefined reference to `_init'
> collect2: error: ld returned 1 exit status
> 
> Hence the linkage of crti.o solving it. I am not sure this is the reason it
> doesn't work though!
> 
> The private headers of the two executables are different:
>     TLS off    0x000000000052b000 vaddr 0x000000006052b000 paddr
> 0x000000006052b000 align 2**3
>         filesz 0x0000000000000000 memsz 0x0000000000000008 flags r--
> EH_FRAME off    0x00000000004cd158 vaddr 0x00000000602cd158 paddr
> 0x00000000602cd158 align 2**2
>         filesz 0x000000000000f7f4 memsz 0x000000000000f7f4 flags r--
> 
> 
> Since the ktruss of the netbsd.build.sh kernel reports it failing directly:
> diablo# ktruss ./netbsd.build.sh
> 25718      1 ktruss   fcntl(0x4, 0x3, 0)          = 4194305
> 25718      1 ktruss   emul(netbsd)
> 25718      1 ktruss   fcntl(0x4, 0x4, 0x400001)   = 0
> 25718      1 netbsd.build.sh
> execve("/usr/sources/cvs.netbsd.org/src-usermode/obj/sys/arch/amd64/compile/GENERIC_USERMODE/./netbsd.build.sh",
> 0x7f7fff2742b0, 0x7f7fff2742c0) JUSTRETURN
> 25718      1 netbsd.build.sh emul(netbsd)
> 25718      1 netbsd.build.sh __sysctl(0x602ca6e8, 0x2, 0x6058c920,
> 0x7f7fff429218, 0, 0) = 0
> 25718      1 netbsd.build.sh mmap(0, 0x20, 0x3, 0x1000, 0xffffffff, 0, 0) =
> 0x7d926f13c000
> 25718      1 netbsd.build.sh _lwp_setprivate(0x7d926f13c008) = 0
> 25718      1 netbsd.build.sh SIGSEGV SIG_DFL
> #diablo
> 
> Could the TLS section be at fault? Any help or suggestions will help :)
> 
> Thanks in advance,
> Reinoud
> 

-- thorpej