On Thursday 22 May 2008 07:34, 夏Timothy wrote: > Hi, all > > I have built a arm uClibc toolchain from buildroot. The gcc version is 4.2.3 > and uClibc used is snapshot. > > Normally, I build busybox 1.7.2 with codesourcery toolchain and everything > works fine. > > Then I tried to build buxybox 1.7.2 with arm uClibc toolchain. And it turns > out the telnetd for busybox 1.7.2 > does not work functionally. When I telnet to the arm developement board, on > which linux and busybox 1.7.2 is > running, I got a shell prompt. But no matter which keyboard button I pressed, > the connect would be closed. > > Consequently, I tried to build busybox 1.10.2 and it turned out that telnetd > for busybox 1.10.2 could work > correctly. > > And then, I dig into the telnetd.c for both busybox 1.7.2 and 1.10.2, hoping > to find out why busybox 1.7.2 > could not work with arm uClibc toolchain. The followings are my findings. > > when busybox telnetd receives character from socketd, it would send the > character to pty. Before sending the > character, here are some statements in telnetd.c: char *ptr; /* Write > to pty from buffer 1. */ ptr = remove_iacs(ts, &num_totty); w = > safe_write(ts->ptyfd, ptr, num_totty); > Here is the statement used to return from remove_iacs in busybox 1.72. > return memmove(ptr - num_totty, ptr0, num_totty); > While the code used to return from remove_iacs in busybox 1.10.2 turns out to > be: if ((ptr - totty) == 0) /* 99.999% of cases */ > return ptr0; > return memmove(ptr - num_totty, ptr0, num_totty); > > It seems memmove returns value 0 so that when the following code attempts to > access *0, error occurs. Thus, it > could explain why busybox 1.7.2 fails but busybox 1.10.2 works since it > returns ptr0 which is safe. > > However, according to GNU Libc definition, the prototype of memmove is: > void * memmove (void *to, const void *from, size_t size) > And the value returned by memmove should be the value of to. > > Hence, I dig into the code of uClibc that implements memmove. And I found > that for the code of uClibc i386, memmove > does return the value of to. But for uClibc arm, memmove just simply jumps to > a function _memcpy which is implemented > by a bunch of assembly code. I suspected that uClibc arm code does not > implement memmove according to the GNU libc > definition and memmove does not return a value of to, instead, it returns 0 > directly. > > If so, busybox 1.10.2 might also be not totally safe. There still exists > possibility that remove_iacs uses memmove to > return. > > Could anybody help me to provide me with some comments on my suspicion? > Thanks a lot.
Excellent analysis. Can you disassemble "working" and "broken" memmove (and memcpy) code? If you build static busybox, dump busybox_unstripped binaries: <TARGET_PREFIX>-objdump -dr busybox_unstripped If you use shared uclibc, you need to dump libuClibc-$VERSION.so instead. Yon may need to add some switches to get arm/thumb disasm sorted out. Find memmove and memcpy assembly code in the output and post to the list. -- vda _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
