-current userland segfault

[Manuel Bouyer]

Hello,
I upgraded my loogson to HEAD, and now all userland binaries segfault
at exit:
(gdb) run
Starting program: /rescue/ls
.cshrc etc libdata pwd.core uname.core
.profile ftp.core libexec rescue usr
altroot gdb.core ls.core root var
bin gzip.core mnt sbin
boot home netbsd stand
cdrom kern proc tar.core
dev lib progress.core tmp

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()

looks like it jumps to a NULL pointer.

I don't see this with the same kernel and a -6 userland.
This is a 64bit kernel with N32 userland.

Anyone else seeing this ? Any idea ?

[Michael]

Hello,

On Thu, 23 Jan 2014 13:51:31 +0100

Post by Manuel Bouyer
Hello,
I upgraded my loogson to HEAD, and now all userland binaries segfault
(gdb) run
Starting program: /rescue/ls
.cshrc etc libdata pwd.core uname.core
.profile ftp.core libexec rescue usr
altroot gdb.core ls.core root var
bin gzip.core mnt sbin
boot home netbsd stand
cdrom kern proc tar.core
dev lib progress.core tmp
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
looks like it jumps to a NULL pointer.
I don't see this with the same kernel and a -6 userland.
This is a 64bit kernel with N32 userland.
Anyone else seeing this ? Any idea ?

I've seen this on my gdium and others have reported the same on both Loongson and other MIPS hardware.

have fun
Michael

[Manuel Bouyer]

Post by Manuel Bouyer
Hello,
I upgraded my loogson to HEAD, and now all userland binaries segfault
(gdb) run
Starting program: /rescue/ls
.cshrc etc libdata pwd.core uname.core
.profile ftp.core libexec rescue usr
altroot gdb.core ls.core root var
bin gzip.core mnt sbin
boot home netbsd stand
cdrom kern proc tar.core
dev lib progress.core tmp
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
looks like it jumps to a NULL pointer.

This is indeed a jump to NULL. I tracked it down and just commited a fix.
Basically: __DTOR_LIST__ was aligned to 8-byte on N32, causing an extra
NULL entry between __DTOR_LIST__ and __DTOR_LIST_END__.
This was corrected for CTOR but not DTOR.

[matthew green]

Post by Manuel Bouyer
This is indeed a jump to NULL. I tracked it down and just commited a fix.
Basically: __DTOR_LIST__ was aligned to 8-byte on N32, causing an extra
NULL entry between __DTOR_LIST__ and __DTOR_LIST_END__.
This was corrected for CTOR but not DTOR.

thanks! i've been unable to test gcc 4.8 on mips non-o32 because
of this (i assume.)

hopefully this will work there too..