Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)
On Sun, Jan 24, 2021 at 01:15:51AM +0100, Iain Buclaw wrote: > The logmake application runs just fine here. Fix has been committed to > gcc mainline, and backported to the version 9 and 10 release branches. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98806 Thanks a lot for your work, Iain! Do you think it might make it in Debian for Bullseye? Cheers, Matija -- Opinions above are GNU-copylefted.
Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)
Excerpts from Iain Buclaw's message of January 23, 2021 11:07 am: > Excerpts from Iain Buclaw's message of January 23, 2021 2:36 am: >> >> So the crux of the matter is that on MIPS, dynamic sections are read-only >> (glibc sets DL_RO_DYN_SECTION 1), which requires special handling when >> pulling >> data from dl_phdr_info. >> >> Re-running with the attached patch applied. >> >> Iain. >> >> --- a/libphobos/libdruntime/gcc/sections/elf_shared.d >> +++ b/libphobos/libdruntime/gcc/sections/elf_shared.d >> @@ -22,6 +22,8 @@ >> >> module gcc.sections.elf_shared; >> >> +version (MIPS32) version = MIPS_Any; >> +version (MIPS64) version = MIPS_Any; >> version (RISCV32) version = RISCV_Any; >> version (RISCV64) version = RISCV_Any; >> version (S390)version = IBMZ_Any; >> @@ -763,6 +765,8 @@ version (Shared) >> // in glibc: #define DL_RO_DYN_SECTION 1 >> version (RISCV_Any) >> strtab = cast(const(char)*)(info.dlpi_addr + >> dyn.d_un.d_ptr); // relocate >> +else version (MIPS_Any) >> +strtab = cast(const(char)*)(info.dlpi_addr + >> dyn.d_un.d_ptr); // relocate >> else >> strtab = cast(const(char)*)dyn.d_un.d_ptr; >> } >> >> > > It's halfway through now, and confirm that I see no more failures in the > testsuite, so I'm fairly confident that everything should be OK now, > though I'll try building your package later. > > In case I don't get round to doing it myself this weekend, could a PR be > raised in gcc bugzilla about it? This so I can reference it in > backports to gdc-10 and gdc-9. > The logmake application runs just fine here. Fix has been committed to gcc mainline, and backported to the version 9 and 10 release branches. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98806 Regards Iain.
Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)
Excerpts from Iain Buclaw's message of January 23, 2021 2:36 am: > > So the crux of the matter is that on MIPS, dynamic sections are read-only > (glibc sets DL_RO_DYN_SECTION 1), which requires special handling when pulling > data from dl_phdr_info. > > Re-running with the attached patch applied. > > Iain. > > --- a/libphobos/libdruntime/gcc/sections/elf_shared.d > +++ b/libphobos/libdruntime/gcc/sections/elf_shared.d > @@ -22,6 +22,8 @@ > > module gcc.sections.elf_shared; > > +version (MIPS32) version = MIPS_Any; > +version (MIPS64) version = MIPS_Any; > version (RISCV32) version = RISCV_Any; > version (RISCV64) version = RISCV_Any; > version (S390)version = IBMZ_Any; > @@ -763,6 +765,8 @@ version (Shared) > // in glibc: #define DL_RO_DYN_SECTION 1 > version (RISCV_Any) > strtab = cast(const(char)*)(info.dlpi_addr + > dyn.d_un.d_ptr); // relocate > +else version (MIPS_Any) > +strtab = cast(const(char)*)(info.dlpi_addr + > dyn.d_un.d_ptr); // relocate > else > strtab = cast(const(char)*)dyn.d_un.d_ptr; > } > > It's halfway through now, and confirm that I see no more failures in the testsuite, so I'm fairly confident that everything should be OK now, though I'll try building your package later. In case I don't get round to doing it myself this weekend, could a PR be raised in gcc bugzilla about it? This so I can reference it in backports to gdc-10 and gdc-9. Regards, Iain.
Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)
Excerpts from Iain Buclaw's message of January 22, 2021 8:14 pm:
> Excerpts from Matija Nalis's message of January 22, 2021 5:51 pm:
>> On Fri, Jan 22, 2021 at 12:59:34PM +0100, Iain Buclaw wrote:
>>> Also, are you linking to the static or shared libphobos library?
>>
>> shared (default):
>>
>> (mipsel-chroot):/tmp/w$ dpkg -l gdc | grep gdc
>> ii gdc4:10.2.1-1 mipsel D compiler (language version
>> 2), based on the GCC backend
>>
>> (mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main() {
>> writeln("Hello, World!"); }\n' > hello.d ; gdc hello.d && ./a.out
>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>> Segmentation fault
>>
>> (mipsel-chroot):/tmp/w$ file a.out
>> a.out: ELF 32-bit LSB pie executable, MIPS, MIPS32 rel2 version 1 (SYSV),
>> dynamically linked, interpreter /lib/ld.so.1,
>> BuildID[sha1]=36c5576b94519b416c1996018760159ae925bc34, for GNU/Linux 3.2.0,
>> not stripped
>>
>> (mipsel-chroot):/tmp/w$ ldd a.out
>> libgphobos.so.1 => /lib/mipsel-linux-gnu/libgphobos.so.1 (0x7f1a3000)
>> libgcc_s.so.1 => /lib/mipsel-linux-gnu/libgcc_s.so.1 (0x7f16b000)
>> libc.so.6 => /lib/mipsel-linux-gnu/libc.so.6 (0x7efd1000)
>> libm.so.6 => /lib/mipsel-linux-gnu/libm.so.6 (0x7ef52000)
>> libpthread.so.0 => /lib/mipsel-linux-gnu/libpthread.so.0 (0x7ef21000)
>> libdl.so.2 => /lib/mipsel-linux-gnu/libdl.so.2 (0x7ef0d000)
>> libz.so.1 => /lib/mipsel-linux-gnu/libz.so.1 (0x7eee2000)
>> /lib/ld.so.1 (0x7ffc9000)
>>
>>
>> But good point, when I try to link this "hello world" example statically, it
>> throws warnings, but works!
>>
>> (mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main() {
>> writeln("Hello, World!"); }\n' > hello.d ; gdc -static hello.d && ./a.out
>> /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(elf_shared.o): in
>> function `_D3gcc8sections10elf_shared18pinLoadedLibrariesFNbNiZPv':
>> /build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/libdruntime/../../../../src/libphobos/libdruntime/gcc/sections/elf_shared.d:250:
>> warning: Using 'dlopen' in statically linked applications requires at
>> runtime the shared libraries from the glibc version used for linking
>> /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(stdio.o): in
>> function `_D3std5stdio11openNetworkFAyatZS3std5stdio4File':
>> /build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/src/../../../../src/libphobos/src/std/stdio.d:5137:
>> warning: Using 'gethostbyname' in statically linked applications requires
>> at runtime the shared libraries from the glibc version used for linking
>> Hello, World!
>>
>
> I've just checked the testsuite result, and the only failed tests are
> those that use -shared-libphobos.
>
> FAIL: gdc.test/runnable/implicit.d -shared-libphobos execution test
> FAIL: gdc.test/runnable/test31.d -shared-libphobos execution test
> FAIL: gdc.test/runnable/testarray.d -shared-libphobos execution test
> FAIL: gdc.test/runnable/Same.d -shared-libphobos execution test
> FAIL: gdc.test/runnable/s2ir.d -shared-libphobos execution test
> FAIL: gdc.test/runnable/test9309.d -shared-libphobos execution test
> FAIL: gdc.test/runnable/test15.d -shared-libphobos execution test
> etc...
>
>
So the crux of the matter is that on MIPS, dynamic sections are read-only
(glibc sets DL_RO_DYN_SECTION 1), which requires special handling when pulling
data from dl_phdr_info.
Re-running with the attached patch applied.
Iain.
--- a/libphobos/libdruntime/gcc/sections/elf_shared.d
+++ b/libphobos/libdruntime/gcc/sections/elf_shared.d
@@ -22,6 +22,8 @@
module gcc.sections.elf_shared;
+version (MIPS32) version = MIPS_Any;
+version (MIPS64) version = MIPS_Any;
version (RISCV32) version = RISCV_Any;
version (RISCV64) version = RISCV_Any;
version (S390)version = IBMZ_Any;
@@ -763,6 +765,8 @@ version (Shared)
// in glibc: #define DL_RO_DYN_SECTION 1
version (RISCV_Any)
strtab = cast(const(char)*)(info.dlpi_addr +
dyn.d_un.d_ptr); // relocate
+else version (MIPS_Any)
+strtab = cast(const(char)*)(info.dlpi_addr +
dyn.d_un.d_ptr); // relocate
else
strtab = cast(const(char)*)dyn.d_un.d_ptr;
}
Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)
Excerpts from Matija Nalis's message of January 22, 2021 5:51 pm:
> On Fri, Jan 22, 2021 at 12:59:34PM +0100, Iain Buclaw wrote:
>> Also, are you linking to the static or shared libphobos library?
>
> shared (default):
>
> (mipsel-chroot):/tmp/w$ dpkg -l gdc | grep gdc
> ii gdc4:10.2.1-1 mipsel D compiler (language version 2),
> based on the GCC backend
>
> (mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main() {
> writeln("Hello, World!"); }\n' > hello.d ; gdc hello.d && ./a.out
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
>
> (mipsel-chroot):/tmp/w$ file a.out
> a.out: ELF 32-bit LSB pie executable, MIPS, MIPS32 rel2 version 1 (SYSV),
> dynamically linked, interpreter /lib/ld.so.1,
> BuildID[sha1]=36c5576b94519b416c1996018760159ae925bc34, for GNU/Linux 3.2.0,
> not stripped
>
> (mipsel-chroot):/tmp/w$ ldd a.out
> libgphobos.so.1 => /lib/mipsel-linux-gnu/libgphobos.so.1 (0x7f1a3000)
> libgcc_s.so.1 => /lib/mipsel-linux-gnu/libgcc_s.so.1 (0x7f16b000)
> libc.so.6 => /lib/mipsel-linux-gnu/libc.so.6 (0x7efd1000)
> libm.so.6 => /lib/mipsel-linux-gnu/libm.so.6 (0x7ef52000)
> libpthread.so.0 => /lib/mipsel-linux-gnu/libpthread.so.0 (0x7ef21000)
> libdl.so.2 => /lib/mipsel-linux-gnu/libdl.so.2 (0x7ef0d000)
> libz.so.1 => /lib/mipsel-linux-gnu/libz.so.1 (0x7eee2000)
> /lib/ld.so.1 (0x7ffc9000)
>
>
> But good point, when I try to link this "hello world" example statically, it
> throws warnings, but works!
>
> (mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main() {
> writeln("Hello, World!"); }\n' > hello.d ; gdc -static hello.d && ./a.out
> /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(elf_shared.o): in
> function `_D3gcc8sections10elf_shared18pinLoadedLibrariesFNbNiZPv':
> /build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/libdruntime/../../../../src/libphobos/libdruntime/gcc/sections/elf_shared.d:250:
> warning: Using 'dlopen' in statically linked applications requires at
> runtime the shared libraries from the glibc version used for linking
> /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(stdio.o): in
> function `_D3std5stdio11openNetworkFAyatZS3std5stdio4File':
> /build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/src/../../../../src/libphobos/src/std/stdio.d:5137:
> warning: Using 'gethostbyname' in statically linked applications requires at
> runtime the shared libraries from the glibc version used for linking
> Hello, World!
>
I've just checked the testsuite result, and the only failed tests are
those that use -shared-libphobos.
FAIL: gdc.test/runnable/implicit.d -shared-libphobos execution test
FAIL: gdc.test/runnable/test31.d -shared-libphobos execution test
FAIL: gdc.test/runnable/testarray.d -shared-libphobos execution test
FAIL: gdc.test/runnable/Same.d -shared-libphobos execution test
FAIL: gdc.test/runnable/s2ir.d -shared-libphobos execution test
FAIL: gdc.test/runnable/test9309.d -shared-libphobos execution test
FAIL: gdc.test/runnable/test15.d -shared-libphobos execution test
etc...
>> Running the testsuite now, to see if there's any reported failures, but
>> none so far...
>
>
> However, when I try to build and run the more complex program
> Data_Generators/makedata/logmake.d
> from this version:
> http://snapshot.debian.org/archive/debian/20210115T023714Z/pool/main/i/ironseed/ironseed_0.3.6-4.dsc
>
> it still fails with segfault on my qemu mipsel chroot, even when '-static' is
> added
> (as it did on Debian buildd machine "eberlin.debian.org"):
>
> (mipsel-chroot):/tmp/w/is/ironseed-0.3.6$ gdc -static -o
> Data_Generators/makedata/logmake Data_Generators/makedata/logmake.d
> Data_Generators/makedata/data.d && Data_Generators/makedata/logmake
> Data_Generators/makedata/logs.txt data/titles.dta data/log.dta
> /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(elf_shared.o): in
> function `_D3gcc8sections10elf_shared18pinLoadedLibrariesFNbNiZPv':
> /build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/libdruntime/../../../../src/libphobos/libdruntime/gcc/sections/elf_shared.d:250:
> warning: Using 'dlopen' in statically linked applications requires at
> runtime the shared libraries from the glibc version used for linking
> /usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(stdio.o): in
> function `_D3std5stdio11openNetworkFAyatZS3std5stdio4File':
> /build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/src/../../../../src/libphobos/src/std/stdio.d:5137:
> warning: Using 'gethostbyname' in statically linked applications requires at
> runtime the shared libraries from the glibc version used for linking
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
>
> (mipsel-chroot):/tmp/w/is/ironseed-0.3.6$ file
>
Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)
On Fri, Jan 22, 2021 at 12:59:34PM +0100, Iain Buclaw wrote:
> > (mipsel-chroot)$ printf 'import std.stdio;\nvoid main() { writeln("Hello,
> > World!"); }\n' > hello.d ; gdc hello.d && ./a.out
> > qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> > Segmentation fault
> >
> > This is with host running Buster with qemu-user 1:5.2+dfsg-3~bpo10+1
> > but the other not-too-complicated D programs fail on Debian buildd
> > infrastructure too:
> > https://buildd.debian.org/status/fetch.php?pkg=ironseed=mipsel=0.3.6-4=1610676343=0
>
> Building current gdc-master on a MIPS server (running Debian Jessie, I
> don't seem to have access to the Buster node), I can't reproduce the
> segfault. What are the chances of it being QEMU that's the cause?
I would be first to blame qemu in my virtual chroot on amd64, but I
was under impression the Debian buildd machine that failed was real
hardware? I could be wrong though, this is information for buildd machine
referenced in bug report where gdc failed:
https://db.debian.org/machines.cgi?host=eberlin
The program there segfaulted there was more complex than simple "hello world",
though.
(but it does work without any problems on all other architectures with gdc)
> Also, are you linking to the static or shared libphobos library?
shared (default):
(mipsel-chroot):/tmp/w$ dpkg -l gdc | grep gdc
ii gdc4:10.2.1-1 mipsel D compiler (language version 2),
based on the GCC backend
(mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main() {
writeln("Hello, World!"); }\n' > hello.d ; gdc hello.d && ./a.out
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
(mipsel-chroot):/tmp/w$ file a.out
a.out: ELF 32-bit LSB pie executable, MIPS, MIPS32 rel2 version 1 (SYSV),
dynamically linked, interpreter /lib/ld.so.1,
BuildID[sha1]=36c5576b94519b416c1996018760159ae925bc34, for GNU/Linux 3.2.0,
not stripped
(mipsel-chroot):/tmp/w$ ldd a.out
libgphobos.so.1 => /lib/mipsel-linux-gnu/libgphobos.so.1 (0x7f1a3000)
libgcc_s.so.1 => /lib/mipsel-linux-gnu/libgcc_s.so.1 (0x7f16b000)
libc.so.6 => /lib/mipsel-linux-gnu/libc.so.6 (0x7efd1000)
libm.so.6 => /lib/mipsel-linux-gnu/libm.so.6 (0x7ef52000)
libpthread.so.0 => /lib/mipsel-linux-gnu/libpthread.so.0 (0x7ef21000)
libdl.so.2 => /lib/mipsel-linux-gnu/libdl.so.2 (0x7ef0d000)
libz.so.1 => /lib/mipsel-linux-gnu/libz.so.1 (0x7eee2000)
/lib/ld.so.1 (0x7ffc9000)
But good point, when I try to link this "hello world" example statically, it
throws warnings, but works!
(mipsel-chroot):/tmp/w$ printf 'import std.stdio;\nvoid main() {
writeln("Hello, World!"); }\n' > hello.d ; gdc -static hello.d && ./a.out
/usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(elf_shared.o): in
function `_D3gcc8sections10elf_shared18pinLoadedLibrariesFNbNiZPv':
/build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/libdruntime/../../../../src/libphobos/libdruntime/gcc/sections/elf_shared.d:250:
warning: Using 'dlopen' in statically linked applications requires at runtime
the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(stdio.o): in
function `_D3std5stdio11openNetworkFAyatZS3std5stdio4File':
/build/gcc-10-XdUysA/gcc-10-10.2.1/build/mipsel-linux-gnu/libphobos/src/../../../../src/libphobos/src/std/stdio.d:5137:
warning: Using 'gethostbyname' in statically linked applications requires at
runtime the shared libraries from the glibc version used for linking
Hello, World!
(mipsel-chroot):/tmp/w$ file a.out
a.out: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (GNU/Linux),
statically linked, BuildID[sha1]=2da3a20d4fe083f1c33f79e4d259f91f8ed7696d, for
GNU/Linux 3.2.0, with debug_info, not stripped
(mipsel-chroot):/tmp/w$ dpkg -l "libgphobos*" | grep '^ii'
ii libgphobos-10-dev:mipsel 10.2.1-6 mipsel Phobos D standard library
ii libgphobos-dev:mipsel10.2.1-1 mipsel Phobos D standard library
ii libgphobos1:mipsel 10.2.1-6 mipsel Phobos D standard
library (runtime library)
> Running the testsuite now, to see if there's any reported failures, but
> none so far...
However, when I try to build and run the more complex program
Data_Generators/makedata/logmake.d
from this version:
http://snapshot.debian.org/archive/debian/20210115T023714Z/pool/main/i/ironseed/ironseed_0.3.6-4.dsc
it still fails with segfault on my qemu mipsel chroot, even when '-static' is
added
(as it did on Debian buildd machine "eberlin.debian.org"):
(mipsel-chroot):/tmp/w/is/ironseed-0.3.6$ gdc -static -o
Data_Generators/makedata/logmake Data_Generators/makedata/logmake.d
Data_Generators/makedata/data.d && Data_Generators/makedata/logmake
Data_Generators/makedata/logs.txt data/titles.dta data/log.dta
/usr/bin/ld: /usr/lib/gcc/mipsel-linux-gnu/10/libgphobos.a(elf_shared.o): in
function
Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)
Excerpts from Matija Nalis's message of January 16, 2021 3:54 am:
> Package: gdc
> Version: 4:10.2.1-1
> Severity: normal
> X-Debbugs-Cc: mnalis-debian...@voyager.hr
>
> Dear Maintainer,
>
> compiling D programs with gdc produces excutable, but trying to run that
> executable segfaults.
> I've tried various gdc flags, but never managed to produce even the simplest
> working program.
>
> on Debian Sid in chroot:
>
> (mipsel-chroot)$ printf 'import std.stdio;\nvoid main() { writeln("Hello,
> World!"); }\n' > hello.d ; gdc hello.d && ./a.out
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
>
> This is with host running Buster with qemu-user 1:5.2+dfsg-3~bpo10+1
> but the other not-too-complicated D programs fail on Debian buildd
> infrastructure too:
> https://buildd.debian.org/status/fetch.php?pkg=ironseed=mipsel=0.3.6-4=1610676343=0
>
Hi,
Building current gdc-master on a MIPS server (running Debian Jessie, I
don't seem to have access to the Buster node), I can't reproduce the
segfault. What are the chances of it being QEMU that's the cause?
Also, are you linking to the static or shared libphobos library?
Running the testsuite now, to see if there's any reported failures, but
none so far...
Iain.
Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)
Package: gdc
Version: 4:10.2.1-1
Severity: normal
X-Debbugs-Cc: mnalis-debian...@voyager.hr
Dear Maintainer,
compiling D programs with gdc produces excutable, but trying to run that
executable segfaults.
I've tried various gdc flags, but never managed to produce even the simplest
working program.
on Debian Sid in chroot:
(mipsel-chroot)$ printf 'import std.stdio;\nvoid main() { writeln("Hello,
World!"); }\n' > hello.d ; gdc hello.d && ./a.out
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
This is with host running Buster with qemu-user 1:5.2+dfsg-3~bpo10+1
but the other not-too-complicated D programs fail on Debian buildd
infrastructure too:
https://buildd.debian.org/status/fetch.php?pkg=ironseed=mipsel=0.3.6-4=1610676343=0
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: mipsel (mips)
Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Versions of packages gdc depends on:
ii gdc-10 10.2.1-6
ii libgphobos-dev 10.2.1-1
gdc recommends no packages.
gdc suggests no packages.
-- no debconf information
