Created attachment 373568 [details] build.log (compressed) Hi, building any glibc on my MIPS64 BE box, results in the following error CPP='mips64-unknown-linux-gnu-gcc -mabi=64 -E -x c-header' /var/tmp/portage/sys-libs/glibc-2.17/work/build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/cross-rpcgen -Y ../scripts -c rpcs Killed There is no kernel oom in the logs, and the system has plenty of RAM at this point. Running the previous command alone in the 'work' directory, dies in the same way This happens with both glibc-2.17 and glibc-2.18-r1 glibc-2.17 used to build fine for MIPS 64/BE/n64 and it's in our stages as well. I am not sure if something changed or if there a problem with the board (maybe a missing kernel option?) KiB Mem: 1966520 total, 216948 free KiB Swap: 2097148 total, 2094688 free Timestamp of tree: Sun, 16 Mar 2014 08:15:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-lang/python: 2.7.5-r1 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.13.4 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.7.3 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.13 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo ACCEPT_KEYWORDS="mips ~mips" ACCEPT_LICENSE="* -@EULA" CBUILD="mips64-unknown-linux-gnu" CFLAGS="-O2 -march=mips64 -mplt -pipe" CHOST="mips64-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=mips64 -mplt -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" USE="acl berkdb bzip2 cli cracklib crypt cxx gdbm iconv ipv6 mips modules multilib ncurses nls nptl pam pcre readline session ssl tcpd unicode zlib" ABI_MIPS="n32" ALSA_CARDS="au1x00" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="fbdev impact newport dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, MAKEOPTS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON
fyi ~$ file /var/tmp/portage/sys-libs/glibc-2.17/work/build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/cross-rpcgen /var/tmp/portage/sys-libs/glibc-2.17/work/build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/cross-rpcgen: ERROR: ELF 64-bit MSB executable, MIPS, MIPS64 version 1 (SYSV), statically linkederror seeking (Invalid argument) The file appears to be corrupted, but the build failure is reproducible on every build.
I am suspecting something funny with the toolchain, gcc or binutils. The frustrating, and nice, thing about glibc, is a build failure in the 'sunrpc' code generally points the finger at the compiler failing somewhere. Either a compiler component failed/crashed/ICEd/etc somewhere, or it just outputted bad data. This is why Google searches for sunrpc build failures can lead to virtually no where. Especially sunrpc/xbootparam_prot.stmp (which is where your build actually died): CPP='mips64-unknown-linux-gnu-gcc -mabi=64 -E -x c-header' /var/tmp/portage/sys-libs/glibc-2.17/work/build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/cross-rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o /var/tmp/portage/sys-libs/glibc-2.17/work/build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/xbootparam_prot.T make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.17/work/build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/xbootparam_prot.stmp] Killed I've been seeing this pretty much as long as I've been using Gentoo, across both sparc64 and mips platforms (when I had a sparc64 install). It always led me back to the compiler in some form or fashion. Are you able to switch to the $WORKDIR and re-run that compile command manually? Might have to tweak the paths on the command line a bit. I'll bet it'll run fine, but fail under the make env.
(In reply to Joshua Kinard from comment #2) > Are you able to switch to the $WORKDIR and re-run that compile command > manually? Might have to tweak the paths on the command line a bit. I'll > bet it'll run fine, but fail under the make env. He answered that already: > Running the previous command alone in the 'work' directory, dies in the same way
(In reply to Matt Turner from comment #3) > (In reply to Joshua Kinard from comment #2) > > Are you able to switch to the $WORKDIR and re-run that compile command > > manually? Might have to tweak the paths on the command line a bit. I'll > > bet it'll run fine, but fail under the make env. > > He answered that already: > > > Running the previous command alone in the 'work' directory, dies in the same way Lack of sleep, my bad. Markos: Can you try removing -mplt from CFLAGS/CXXFLAGS and -Wl,O1 from LDFLAGS (or just comment LDFLAGS out entirely), and re-run the build? -mplt seems to be unneeded, since it appears to require -msym32 and only affects code compiled with -mno-shared -mabicalls: -mplt -mno-plt Assume (do not assume) that the static and dynamic linkers support PLTs and copy relocations. This option only affects -mno-shared -mabicalls. For the n64 ABI, this option has no effect without -msym32. You can make -mplt the default by configuring GCC with --with-mips-plt. The default is -mno-plt otherwise.
(In reply to Joshua Kinard from comment #4) > (In reply to Matt Turner from comment #3) > > (In reply to Joshua Kinard from comment #2) > > > Are you able to switch to the $WORKDIR and re-run that compile command > > > manually? Might have to tweak the paths on the command line a bit. I'll > > > bet it'll run fine, but fail under the make env. > > > > He answered that already: > > > > > Running the previous command alone in the 'work' directory, dies in the same way > > Lack of sleep, my bad. > > > Markos: > Can you try removing -mplt from CFLAGS/CXXFLAGS and -Wl,O1 from LDFLAGS (or > just comment LDFLAGS out entirely), and re-run the build? -mplt seems to be > unneeded, since it appears to require -msym32 and only affects code compiled > with -mno-shared -mabicalls: > > -mplt > -mno-plt > Assume (do not assume) that the static and dynamic linkers support PLTs > and copy relocations. This option only affects -mno-shared -mabicalls. For > the n64 ABI, this option has no effect without -msym32. > > You can make -mplt the default by configuring GCC with --with-mips-plt. > The default is -mno-plt otherwise. I could, but this is a catalyst build, meaning I have built glibc-2.17 in the current stages in the past with the same C{XX}FLAGS and LDFLAGS without problem but used older gcc and binutils. Which makes me think the CFLAGS/LDFLAGS are fine, and this could be a gcc/binutils problem.
(In reply to Markos Chandras from comment #5) > (In reply to Joshua Kinard from comment #4) > > (In reply to Matt Turner from comment #3) > > > (In reply to Joshua Kinard from comment #2) > > > > Are you able to switch to the $WORKDIR and re-run that compile command > > > > manually? Might have to tweak the paths on the command line a bit. I'll > > > > bet it'll run fine, but fail under the make env. > > > > > > He answered that already: > > > > > > > Running the previous command alone in the 'work' directory, dies in the same way > > > > Lack of sleep, my bad. > > > > > > Markos: > > Can you try removing -mplt from CFLAGS/CXXFLAGS and -Wl,O1 from LDFLAGS (or > > just comment LDFLAGS out entirely), and re-run the build? -mplt seems to be > > unneeded, since it appears to require -msym32 and only affects code compiled > > with -mno-shared -mabicalls: > > > > -mplt > > -mno-plt > > Assume (do not assume) that the static and dynamic linkers support PLTs > > and copy relocations. This option only affects -mno-shared -mabicalls. For > > the n64 ABI, this option has no effect without -msym32. > > > > You can make -mplt the default by configuring GCC with --with-mips-plt. > > The default is -mno-plt otherwise. > > > I could, but this is a catalyst build, meaning I have built glibc-2.17 in > the current stages in the past with the same C{XX}FLAGS and LDFLAGS without > problem but used older gcc and binutils. Which makes me think the > CFLAGS/LDFLAGS are fine, and this could be a gcc/binutils problem. No I was wrong. This build still uses 4.7.3, which is the same compiler I used when I built that stage. So I am puzzled... Could something have changed in glibc ebuilds/functions since then?
> No I was wrong. This build still uses 4.7.3, which is the same compiler I > used when I built that stage. So I am puzzled... Could something have > changed in glibc ebuilds/functions since then? I am not seeing anything. We've got just one 2.17 ebuild, so no revbumps that added patches. Do you know if the gcc/binutils in the source stage are being used for the glibc attempt, or are they getting rebuilt inside the chroot first beforehand? I tried to build a -s3 crossdev of a N64 MIPS64 toolchain, but some other bug is blocking glibc from configuring correctly. Just out of curiosity, can you step the -march down to "mips4" in CFLAGS and try the build again? If that fails for the same reason (sunrpc/xbootparam_prot.stmp), tar it up and put it on your dev site (along with the catalyst spec files and basic setup instructions I'll need) and I'll see if I can play with it on my O2 at all. You might need to restart from a mips4 stage, though. That's the highest ISA the O2 can handle. If it gets farther under the lower ISA...well, things will be very interesting then. FYI, I only have about 3G of free space on my O2. If the catalyst buildroot is larger than that, let me know and I can move some things around to make room.
(In reply to Joshua Kinard from comment #7) > > No I was wrong. This build still uses 4.7.3, which is the same compiler I > > used when I built that stage. So I am puzzled... Could something have > > changed in glibc ebuilds/functions since then? > > I am not seeing anything. We've got just one 2.17 ebuild, so no revbumps > that added patches. Do you know if the gcc/binutils in the source stage are > being used for the glibc attempt, or are they getting rebuilt inside the > chroot first beforehand? Yes the gcc and binutils from the stages are used as far as I can tell. > > I tried to build a -s3 crossdev of a N64 MIPS64 toolchain, but some other > bug is blocking glibc from configuring correctly. > > Just out of curiosity, can you step the -march down to "mips4" in CFLAGS and > try the build again? If that fails for the same reason > (sunrpc/xbootparam_prot.stmp), tar it up and put it on your dev site (along > with the catalyst spec files and basic setup instructions I'll need) and > I'll see if I can play with it on my O2 at all. You might need to restart > from a mips4 stage, though. That's the highest ISA the O2 can handle. > > If it gets farther under the lower ISA...well, things will be very > interesting then. > > FYI, I only have about 3G of free space on my O2. If the catalyst buildroot > is larger than that, let me know and I can move some things around to make > room. Ok A few more information... The same machine built 32-bit stages with the same portage snapshots, and in these 32-bit stages, glibc-2.18 was built just fine (big-endian as well). So the problem appears to be related to 64-bit only.
(In reply to Joshua Kinard from comment #7) > > No I was wrong. This build still uses 4.7.3, which is the same compiler I > > used when I built that stage. So I am puzzled... Could something have > > changed in glibc ebuilds/functions since then? > > I am not seeing anything. We've got just one 2.17 ebuild, so no revbumps > that added patches. Do you know if the gcc/binutils in the source stage are > being used for the glibc attempt, or are they getting rebuilt inside the > chroot first beforehand? > > I tried to build a -s3 crossdev of a N64 MIPS64 toolchain, but some other > bug is blocking glibc from configuring correctly. > > Just out of curiosity, can you step the -march down to "mips4" in CFLAGS and > try the build again? If that fails for the same reason > (sunrpc/xbootparam_prot.stmp), tar it up and put it on your dev site (along > with the catalyst spec files and basic setup instructions I'll need) and > I'll see if I can play with it on my O2 at all. You might need to restart > from a mips4 stage, though. That's the highest ISA the O2 can handle. A build for mips3 failed in the same way. I will tar the stage soon.
(In reply to Joshua Kinard from comment #7) > > No I was wrong. This build still uses 4.7.3, which is the same compiler I > > used when I built that stage. So I am puzzled... Could something have > > changed in glibc ebuilds/functions since then? > > I am not seeing anything. We've got just one 2.17 ebuild, so no revbumps > that added patches. Do you know if the gcc/binutils in the source stage are > being used for the glibc attempt, or are they getting rebuilt inside the > chroot first beforehand? > > I tried to build a -s3 crossdev of a N64 MIPS64 toolchain, but some other > bug is blocking glibc from configuring correctly. > > Just out of curiosity, can you step the -march down to "mips4" in CFLAGS and > try the build again? If that fails for the same reason > (sunrpc/xbootparam_prot.stmp), tar it up and put it on your dev site (along > with the catalyst spec files and basic setup instructions I'll need) and > I'll see if I can play with it on my O2 at all. You might need to restart > from a mips4 stage, though. That's the highest ISA the O2 can handle. > > If it gets farther under the lower ISA...well, things will be very > interesting then. > > FYI, I only have about 3G of free space on my O2. If the catalyst buildroot > is larger than that, let me know and I can move some things around to make > room. What exactly do you want to see in the tarball? The process to reproduce it yourself is very simple 1) Download the latest 64-bit stage3 tarball of your preference 2) Get the latest portage tree 3) Try to build glibc There is no point for me to tar my rootfs as all I did was to follow the steps I mentioned above.
A few more information as I found sometime to look at this It appears that all the object files that are linked together to create the cross-rpcgen are corrupted or something? ~ sunrpc # mips64-unknown-linux-gnu-gcc -mabi=64 rpc_main.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -frounding-math -march=mips3 -mplt -pipe -Wstrict-prototypes -U_FORTIFY_SOURCE -D_RPC_THREAD_SAFE_ -I../include -I/var/tmp/portage/sys-libs/glibc-2.18-r1/work/build-n64-mips64-unknown-linux-gnu-nptl/sunrpc -I/var/tmp/portage/sys-libs/glibc-2.18-r1/work/build-n64-mips64-unknown-linux-gnu-nptl -I../ports/sysdeps/unix/sysv/linux/mips/mips64/n64/nptl -I../ports/sysdeps/unix/sysv/linux/mips/mips64/n64 -I../ports/sysdeps/unix/sysv/linux/mips/mips64/nptl -I../ports/sysdeps/unix/sysv/linux/mips/mips64 -I../ports/sysdeps/unix/sysv/linux/mips/nptl -I../ports/sysdeps/unix/sysv/linux/mips -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../ports/sysdeps/unix/mips/mips64/n64 -I../ports/sysdeps/unix/mips/mips64 -I../ports/sysdeps/unix/mips -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../ports/sysdeps/mips/mips64/n64 -I../ports/sysdeps/mips/ieee754 -I../sysdeps/ieee754/ldbl-128 -I../ports/sysdeps/mips/mips64/soft-fp -I../ports/sysdeps/mips/mips64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../ports/sysdeps/mips/include -I../ports/sysdeps/mips -I../sysdeps/wordsize-64 -I../ports/sysdeps/mips/fpu -I../ports/sysdeps/mips/nptl -I../sysdeps/ieee754 -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/mips64-unknown-linux-gnu/4.7.3/include -isystem /usr/lib/gcc/mips64-unknown-linux-gnu/4.7.3/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPIC -DNOT_IN_libc=1 -D_RPC_THREAD_SAFE_ -o /var/tmp/portage/sys-libs/glibc-2.18-r1/work/build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/rpc_main.o -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.18-r1/work/build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/rpc_main.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.18-r1/work/build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/rpc_main.o ~ sunrpc # file ../../build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/rpc_main.o ../../build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/rpc_main.o: ERROR: ELF 64-bit MSB relocatable, MIPS, MIPS-III version 1 (SYSV)error seeking (Invalid argument) I am not sure what's wrong. really...
(In reply to Markos Chandras from comment #10) > > What exactly do you want to see in the tarball? The process to reproduce it > yourself is very simple > > 1) Download the latest 64-bit stage3 tarball of your preference > 2) Get the latest portage tree > 3) Try to build glibc > > There is no point for me to tar my rootfs as all I did was to follow the > steps I mentioned above. Yeah, but being able to start from right where you left off saves time. Remember, I only have a speedy 350MHz RM7000 CPU and 512GB RAM in my O2 :) (I should put a racing stripe on it one day) Starting from a stage3 will work, it'll just take a bit longer. (In reply to Markos Chandras from comment #11) > A few more information as I found sometime to look at this > > It appears that all the object files that are linked together to create the > cross-rpcgen are corrupted or something? [snip] > > ~ sunrpc # file > ../../build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/rpc_main.o > ../../build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/rpc_main.o: ERROR: ELF > 64-bit MSB relocatable, MIPS, MIPS-III version 1 (SYSV)error seeking > (Invalid argument) > > I am not sure what's wrong. really... Tar up a few of those object files and send them to me. I am curious to see if I can at least take them apart at all. That would suggest a linker bug almost, because if gcc was at fault, ld should'ved bugged out before linking everyting. An objdump on them would be interesting....not that I would know what I am looking for. But maybe, if objdump can dump raw assembler up until the corrupted point, I can get an idea of where in the sunrpc C code it's choking.
(In reply to Joshua Kinard from comment #12) > (In reply to Markos Chandras from comment #10) > > > > What exactly do you want to see in the tarball? The process to reproduce it > > yourself is very simple > > > > 1) Download the latest 64-bit stage3 tarball of your preference > > 2) Get the latest portage tree > > 3) Try to build glibc > > > > There is no point for me to tar my rootfs as all I did was to follow the > > steps I mentioned above. > > Yeah, but being able to start from right where you left off saves time. > Remember, I only have a speedy 350MHz RM7000 CPU and 512GB RAM in my O2 :) > (I should put a racing stripe on it one day) > > Starting from a stage3 will work, it'll just take a bit longer. The problem appears very early during build (n64 is built first). So even on a slow box, you should be able to see this quite easily. Furthermore, I think it might make sense to not trust my object files if something is wrong with my environment, and see if the problem is reproducible on a completely different environment. > > > (In reply to Markos Chandras from comment #11) > > A few more information as I found sometime to look at this > > > > It appears that all the object files that are linked together to create the > > cross-rpcgen are corrupted or something? > [snip] > > > > ~ sunrpc # file > > ../../build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/rpc_main.o > > ../../build-n64-mips64-unknown-linux-gnu-nptl/sunrpc/rpc_main.o: ERROR: ELF > > 64-bit MSB relocatable, MIPS, MIPS-III version 1 (SYSV)error seeking > > (Invalid argument) > > > > I am not sure what's wrong. really... > > Tar up a few of those object files and send them to me. I am curious to see > if I can at least take them apart at all. That would suggest a linker bug > almost, because if gcc was at fault, ld should'ved bugged out before linking > everyting. An objdump on them would be interesting....not that I would know > what I am looking for. But maybe, if objdump can dump raw assembler up > until the corrupted point, I can get an idea of where in the sunrpc C code > it's choking. I have uploaded the workdir of my glibc build (mips3) on my devspace: http://dev.gentoo.org/~hwoarang/glibc-2.18-mips.tar.gz
(In reply to Markos Chandras from comment #13) > The problem appears very early during build (n64 is built first). So even on > a slow box, you should be able to see this quite easily. Furthermore, I > think it might make sense to not trust my object files if something is wrong > with my environment, and see if the problem is reproducible on a completely > different environment. It's possible. Looking at your glibc tarball: $ file sunrpc/rpc_main.o sunrpc/rpc_main.o: ELF 64-bit MSB relocatable, MIPS, MIPS-III version 1 (SYSV), not stripped Is that version of 'file' in the catalyst buildroot? Does it do similar errors on other glibc object files?
(In reply to Joshua Kinard from comment #14) > (In reply to Markos Chandras from comment #13) > > The problem appears very early during build (n64 is built first). So even on > > a slow box, you should be able to see this quite easily. Furthermore, I > > think it might make sense to not trust my object files if something is wrong > > with my environment, and see if the problem is reproducible on a completely > > different environment. > > It's possible. Looking at your glibc tarball: > $ file sunrpc/rpc_main.o > sunrpc/rpc_main.o: ELF 64-bit MSB relocatable, MIPS, MIPS-III version 1 > (SYSV), not stripped > > Is that version of 'file' in the catalyst buildroot? Does it do similar > errors on other glibc object files? Hit enter too soon, derp. That 'file' I ran is on my Intel machine, fyi. I'll fire the O2 up in a bit and see what it does.
(In reply to Joshua Kinard from comment #14) > (In reply to Markos Chandras from comment #13) > > The problem appears very early during build (n64 is built first). So even on > > a slow box, you should be able to see this quite easily. Furthermore, I > > think it might make sense to not trust my object files if something is wrong > > with my environment, and see if the problem is reproducible on a completely > > different environment. > > It's possible. Looking at your glibc tarball: > $ file sunrpc/rpc_main.o > sunrpc/rpc_main.o: ELF 64-bit MSB relocatable, MIPS, MIPS-III version 1 > (SYSV), not stripped > > Is that version of 'file' in the catalyst buildroot? Does it do similar > errors on other glibc object files? I already told you this is the latest stage3 so everything that is being used on this build, is from that stage3. Nothing has changed, nothing has been updated. I will repeat it again, all you need it to download the latest stage3 (64-bit), get a portage tree and try to merge glibc.
Updating to gcc-4.8.2 and trying to merge glibc did *not* fix the problem.
Actually, using the latest stage3 to build an execute any n64 elf file results to SIGKILL. Could someone please reproduce it on another hardware? The steps are the following ones - Get the latest stage3 from the mirros for 64-bit - echo "int main() { return 1; }" >> foo.c - mips64-unknown-linux-gnu-gcc -mabi=64 foo.c - ./a.out Killed
(In reply to Markos Chandras from comment #18) > Actually, using the latest stage3 to build an execute any n64 elf file > results to SIGKILL. Could someone please reproduce it on another hardware? > > The steps are the following ones > > - Get the latest stage3 from the mirros for 64-bit > - echo "int main() { return 1; }" >> foo.c > - mips64-unknown-linux-gnu-gcc -mabi=64 foo.c > - ./a.out > Killed This feels like a toolchain problem. Anyone from @toolchain to comment on this? the n64 ABI seems broken for mips. I have an old 2012XXXX stage3 around for mip3, and n64 is broken there as well.
(In reply to Markos Chandras from comment #19) > (In reply to Markos Chandras from comment #18) > > Actually, using the latest stage3 to build an execute any n64 elf file > > results to SIGKILL. Could someone please reproduce it on another hardware? > > > > The steps are the following ones > > > > - Get the latest stage3 from the mirros for 64-bit > > - echo "int main() { return 1; }" >> foo.c > > - mips64-unknown-linux-gnu-gcc -mabi=64 foo.c > > - ./a.out > > Killed > > This feels like a toolchain problem. Anyone from @toolchain to comment on > this? the n64 ABI seems broken for mips. I have an old 2012XXXX stage3 > around for mip3, and n64 is broken there as well. An even simpler testcase: ~ # cat a.S lw $4, 0($5) ~ # mips-unknown-linux-gnu-as -mabi=64 a.S -o a.o ~ # mips-unknown-linux-gnu-ld -m elf64btsmip a.o -o a.out mips-unknown-linux-gnu-ld: warning: cannot find entry symbol __start; defaulting to 00000001200000e0 ~ # ./a.out Killed
we usually let the mips team self service when it's a mips issue (which this certainly sounds like). are you sure it's SIGKILL ? look at dmesg, or maybe run it through strace, and see what signal is being sent up. it's kind of weird for the kernel to send a SIGKILL in response to bad userland code ... usually get SEGV/BUS/ILL.
(In reply to SpanKY from comment #21) > we usually let the mips team self service when it's a mips issue (which this > certainly sounds like). > > are you sure it's SIGKILL ? Yep look at dmesg, or maybe run it through strace, > and see what signal is being sent up. It's SIGKILL. dmesg says nothing. strace dies almost instantly. gdb the same it's kind of weird for the kernel to > send a SIGKILL in response to bad userland code ... usually get SEGV/BUS/ILL. The last code seems to suggest that the binutils could be the problem? (only gas/ld are involved there) The version on the stage is 2.23.1. I am going to try the latest on (even with USE=vanilla)
(In reply to Markos Chandras from comment #22) > (In reply to SpanKY from comment #21) > > we usually let the mips team self service when it's a mips issue (which this > > certainly sounds like). > > > > are you sure it's SIGKILL ? > > Yep > look at dmesg, or maybe run it through strace, > > and see what signal is being sent up. > It's SIGKILL. > > dmesg says nothing. strace dies almost instantly. gdb the same > > it's kind of weird for the kernel to > > send a SIGKILL in response to bad userland code ... usually get SEGV/BUS/ILL. > > The last code seems to suggest that the binutils could be the problem? (only > gas/ld are involved there) > > The version on the stage is 2.23.1. I am going to try the latest on (even > with USE=vanilla) With the latest binutils (2.24-r2) with USE=vanilla ~ # mips-unknown-linux-gnu-as -mabi=64 a.S -o a.o ~ # mips-unknown-linux-gnu-ld -m elf64btsmip a.o -o a.out mips-unknown-linux-gnu-ld: warning: cannot find entry symbol __start; defaulting to 00000001200000a0 ~ # strace ./a.out execve("./a.out", ["./a.out"], [/* 23 vars */] <unfinished ...> +++ killed by SIGKILL +++ Killed For reference, here is the n32 output ~ # mips64-unknown-linux-gnu-as -mabi=n32 a.S -o a.o ~ # mips64-unknown-linux-gnu-ld -m elf32btsmipn32 a.o -o a.out mips64-unknown-linux-gnu-ld: warning: cannot find entry symbol __start; defaulting to 0000000010000090 ~ # mips64-unknown-linux-gnu-as -mabi=n32 a.S -o a.o^C ~ # ./a.out Segmentation fault ~ # strace ./a.out execve("./a.out", ["./a.out"], [/* 23 vars */]) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} --- +++ killed by SIGSEGV +++ Segmentation fault Well the SIGSEGV is expected due to the stupid code in the a.S file. But you get my point. I am running out of ideas...
(In reply to Markos Chandras from comment #23) > I am running out of ideas... I'm working mostly with little endian stuff on the lemote where I have not hit this. What's the closest stage on the tree that I could try on the edge router lite?
(In reply to Markos Chandras from comment #23) then i guess it's time to debug the kernel
(In reply to Anthony Basile from comment #24) > (In reply to Markos Chandras from comment #23) > > I am running out of ideas... > > I'm working mostly with little endian stuff on the lemote where I have not > hit this. What's the closest stage on the tree that I could try on the edge > router lite? I was not able to reproduce the problem on an ERlite-3 which makes me think this is a problem with the board or the kernel (as Mike suggested). Closing as INVALID for now
Actually, I want to set this to TEST-REQUEST for now. I still need to try this on my O2. Can you post the source of the a.S file, just in case your toolchain is generating slightly different asm for some reason? If it's a kernel issue, it might be a particular syscall failing. I think I've seen before on the linux-mips ML where missing syscalls in the kernel's ABI-specific code (I forget what file this is) can lead to oddities like this.
(In reply to Joshua Kinard from comment #27) > Actually, I want to set this to TEST-REQUEST for now. I still need to try > this on my O2. Can you post the source of the a.S file, just in case your > toolchain is generating slightly different asm for some reason? If it's a > kernel issue, it might be a particular syscall failing. I think I've seen > before on the linux-mips ML where missing syscalls in the kernel's > ABI-specific code (I forget what file this is) can lead to oddities like > this. N/m on a.S source. I wasn't expecting a one-line ASM file.
