Question about memmove implemented for uClibc arm

[Denys Vlasenko]

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