Re: [uclibc-ng-devel] CONFIG_UCLIBC_SUSV2_LEGACY triggers odd SIGSEGV in busybox's ash on MIPS
On 10/31/2016 03:13, Waldemar Brodkorb wrote: > Hi Joshua, > Joshua Kinard wrote, > >> On 10/23/2016 23:55, Waldemar Brodkorb wrote: >>> Hi Joshua, >>> Joshua Kinard wrote, >>> [snip] >>> >>> After sorting out my last bootup problems (missing N32/O32 binary >>> support in the kernel), I can confirm that the bug is fixed in >>> uCLibc-ng 1.0.19: >>> >>> root@openadk:/root # ash -c /tmp/c.sh >>> ash: /tmp/c.sh: Permission denied >>> root@openadk:/root # chmod 755 . >>> root@openadk:/root # chmod 755 /tmp/c.sh >>> root@openadk:/root # ash -c /tmp/c.sh >>> foo! >>> root@openadk:/root # ash -c >>> ash: -c requires an argument >>> root@openadk:/root # ls /lib >>> >>> Please update to 1.0.19, thanks >>> Waldemar >> >> Sorry for the delay, got tied up with things. >> >> I'd already switched the busybox build to a shared library from a static >> one, which worked around the issue for me, but I am building 1.0.19 now. >> I'll let you know if any additional issues crop up. >> >> And for the record, on your last e-mail, an RM52XX O2 needs -march=rm5200 to >> gcc. Stock -mips4 or -march=r5000 won't hurt, either. > > Okay. > >> Now to just figure out the libtirpc bit... > > Buildroot or OpenADK is always a good source for cross-compile > issues. Take a look at the patches. > > Another possibility would be to ty the internal ipv4 only RPC > implementation in uClibc-ng, but I have'nt used it for a long time. > > Not sure if rpcbind works with it. I think last time I sed it was > with good old portmap. > > best regards > Waldemar I can get NFS to work with just portmap running, but it throws an odd, yet non-fatal, error when mounting the remote share (don't have the actual error text available at the moment). I was hoping that having rpcbind running as well as portmap would eliminate that. However, current rpcbind needs libtirpc to build, and that fails on uclibc-ng because of a missing header file "rpcsvc/yp_prot.h". Buildroot posted a patch to fix this in libtirpc itself, just haven't had some free time to test it yet: http://lists.busybox.net/pipermail/buildroot/2015-July/133890.html Can't use the internal (minimal?) RPC mechanism, either. I had to enable the full RPC stack in order for portmap to actually build. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic ___ devel mailing list devel@uclibc-ng.org http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
Re: [uclibc-ng-devel] CONFIG_UCLIBC_SUSV2_LEGACY triggers odd SIGSEGV in busybox's ash on MIPS
Hi Joshua, Joshua Kinard wrote, > On 10/23/2016 23:55, Waldemar Brodkorb wrote: > > Hi Joshua, > > Joshua Kinard wrote, > > > >> I think I've run into a rather odd bug on a big-endian MIPS platform while > >> trying to hand-assemble a MIPS-II ISA netboot image built from a uclibc-ng > >> chroot. In my netboot, I need to include xfsprogs, but this has a > >> dependency > >> on the 'valloc' function call. So in uclibc-ng, I enabled > >> CONFIG_UCLIBC_SUSV2_LEGACY to enable that function, and rebuilt uclibc-ng. > >> This fixes the xfsprogs build, but it very subtly breaks busybox's ash > >> shell. > >> > >> After rebuilding uclibc-ng, then rebuilding busybox statically/multicall, > >> if > >> you run /bin/ash with a malformed argument or give it a script to execute > >> that > >> doesn't have the execute bit set, you get a SIGSEGV: > >> > >> Fudging up the argument syntax to /bin/ash: > >> octane / # /bin/ash "-c" > >> /bin/ash: -c requires an argument > >> Segmentation fault > >> > >> Via a non-executable script "x.sh", we start with this sample: > >> octane / # cat ./x.sh > >> #!/bin/ash > >> echo "foo!" > >> > >> If "x.sh" has the executable bit set, we're all good: > >> octane / # ls -l ./x.sh > >> -rwxr-xr-x 1 root root 24 Oct 12 01:57 ./x.sh > >> octane / # /bin/ash -c ./x.sh > >> foo! > >> > >> But if we turn off the executable bit... > >> octane / # chmod -x ./x.sh > >> octane / # ls -l ./x.sh > >> -rw-r--r-- 1 root root 24 Oct 12 01:57 ./x.sh > >> octane / # /bin/ash -c ./x.sh > >> /bin/ash: ./x.sh: Permission denied > >> Segmentation fault > > > > After sorting out my last bootup problems (missing N32/O32 binary > > support in the kernel), I can confirm that the bug is fixed in > > uCLibc-ng 1.0.19: > > > > root@openadk:/root # ash -c /tmp/c.sh > > ash: /tmp/c.sh: Permission denied > > root@openadk:/root # chmod 755 . > > root@openadk:/root # chmod 755 /tmp/c.sh > > root@openadk:/root # ash -c /tmp/c.sh > > foo! > > root@openadk:/root # ash -c > > ash: -c requires an argument > > root@openadk:/root # ls /lib > > > > Please update to 1.0.19, thanks > > Waldemar > > Sorry for the delay, got tied up with things. > > I'd already switched the busybox build to a shared library from a static > one, which worked around the issue for me, but I am building 1.0.19 now. > I'll let you know if any additional issues crop up. > > And for the record, on your last e-mail, an RM52XX O2 needs -march=rm5200 to > gcc. Stock -mips4 or -march=r5000 won't hurt, either. Okay. > Now to just figure out the libtirpc bit... Buildroot or OpenADK is always a good source for cross-compile issues. Take a look at the patches. Another possibility would be to ty the internal ipv4 only RPC implementation in uClibc-ng, but I have'nt used it for a long time. Not sure if rpcbind works with it. I think last time I sed it was with good old portmap. best regards Waldemar ___ devel mailing list devel@uclibc-ng.org http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
