Created attachment 3037 [details] busybox config I'm using busybox in my uclibc-linux image for embedded ARM system. I have busybox 1.15.3 and uclibc 0.9.31. Linux works fine, but I have some bug I can't deal with - almost all shell commands parse argv[0] as first option. For example, I have following for "ls" command: root@(none):/# ls ls: ls: No such file or directory I think there is some trouble with getopt() and optind
changed complier options from CONFIG_CROSS_COMPILER_PREFIX="arm-oe-linux-uclibceabi-" CONFIG_EXTRA_CFLAGS="-isystem/home/melg/workspace/platform-a/tmp/sysroots/armv5te-oe-linux-uclibceabi/usr/include -fexpensive-optimizations -fomit-frame-pointer -frename-register to CONFIG_CROSS_COMPILER_PREFIX="i486-linux-uclibc-" CONFIG_EXTRA_CFLAGS="-fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -fomit-frame-pointer" recompiled busybox-1.15.3 and failed to reproduce the bug. Can you reproduce it on a ix86 Linux distribution machine? If not, can you reproduce it in Rob's Aboriginal Linux qemu image? See: http://www.landley.net/aboriginal/ http://www.landley.net/aboriginal/downloads/binaries/README If you do, it will be very easy to reproduce for anyone else. > root@(none):/# ls > ls: ls: No such file or directory Under which shell do you do it? ash from the same busybox binary?
> Under which shell do you do it? ash from the same busybox binary? I use ash from busybox. > Can you reproduce it on a ix86 Linux distribution machine? I've tryed reproduce this bug on x86 with GNU libc, but there was no this bug. I've found some intresting thing in libbb/getopt32.c. In function uint32_t FAST_FUNC getopt32(char **argv, const char *applet_opts, ...). http://git.busybox.net/busybox/tree/libbb/getopt32.c?h=1_15_stable#n532 <- here optind resets to 0. After that, http://git.busybox.net/busybox/tree/libbb/getopt32.c?h=1_15_stable#n550 <- here getopt() from uClibc called, but on ARM system optind is still 0, however on x86 optind is 1 in this place. So busybox commands (for example cat - http://git.busybox.net/busybox/tree/coreutils/cat.c?h=1_15_stable#n46) add optind which is 0 to argv and then parse options from argv[0] which is command name. So, i guess, it's not busybox bug, but uClibc bug.
It wasn't uClibc bug. Bug has gone away with adding CONFIG_PIE=y in busybox config.
(In reply to comment #2) > > Under which shell do you do it? ash from the same busybox binary? > I use ash from busybox. > > > Can you reproduce it on a ix86 Linux distribution machine? > I've tryed reproduce this bug on x86 with GNU libc, but there was no this > bug. > > I've found some intresting thing in libbb/getopt32.c. In function uint32_t > FAST_FUNC getopt32(char **argv, const char *applet_opts, ...). > > http://git.busybox.net/busybox/tree/libbb/getopt32.c?h=1_15_stable#n532 <- here > optind resets to 0. After that, > http://git.busybox.net/busybox/tree/libbb/getopt32.c?h=1_15_stable#n550 <- here > getopt() from uClibc called, but on ARM system optind is still 0, however on > x86 optind is 1 in this place. > > So busybox commands (for example cat - > http://git.busybox.net/busybox/tree/coreutils/cat.c?h=1_15_stable#n46) add > optind which is 0 to argv and then parse options from argv[0] which is command > name. This may well be one. Resetting getopt is a somewhat non-well standardized thing.