Fix valgrind nm complaint: memcpy to == from

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

In the ld testsuite for native i686-pc-linux-gnu (and others),
you can see, if you pass the nm-calls through valgrind, in
ld.log:

valgrind -q /home/hp/binutils/obj/n/binutils/nm-new  -D tmpdir/exclude.so >tmpdir/nm.out
Executing on host: sh -c {valgrind -q /home/hp/binutils/obj/n/binutils/nm-new  -D tmpdir/exclude.so 2>ld.stderr}  /dev/null tmpdir/nm.out (timeout = 300)
000011e0 A __bss_start
000011e0 A _edata
000011e0 A _end
000011dc D exclude_sym
000011d8 D include_sym
==26792== Source and destination overlap in memcpy(0x402D480, 0x402D480, 4)
==26792==    at 0x40076D9: memcpy (mc_replace_strmem.c:402)
==26792==    by 0x804AC84: display_rel_file (nm.c:452)
==26792==    by 0x804B2E8: display_file (nm.c:1192)
==26792==    by 0x804B885: main (nm.c:1641)

ERROR: tmpdir/exclude.so: nm failed
UNRESOLVED: ld export symbols from archive

While this and the other calls in ld.log were simple to == from
cases and could avoid the call to memcpy at all, it seems the
code is intended to also have partial overlapping to and from,
so it's memmove, not memcpy that should be used.  No regressions
for the binutils testsuite, fixes the valgrind nm complaints.

Ok to commit?

binutils:
	* nm.c (filter_symbols): Use memmove, not memcpy, for possibly
	overlapping source and destination.

Index: nm.c
===================================================================
RCS file: /cvs/src/src/binutils/nm.c,v
retrieving revision 1.55
diff -p -u -r1.55 nm.c
--- nm.c	13 Sep 2007 14:32:11 -0000	1.55
+++ nm.c	13 Nov 2008 02:52:05 -0000
@@ -449,7 +449,7 @@ filter_symbols (bfd *abfd, bfd_boolean d
 
       if (keep)
 	{
-	  memcpy (to, from, size);
+	  memmove (to, from, size);
 	  to += size;
 	}
     }

brgds, H-P