This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/15931] New: memcpy() has different behavior when statically linked (x86_64)
- From: "pchang9 at cs dot wisc.edu" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 04 Sep 2013 17:05:23 +0000
- Subject: [Bug libc/15931] New: memcpy() has different behavior when statically linked (x86_64)
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=15931
Bug ID: 15931
Summary: memcpy() has different behavior when statically linked
(x86_64)
Product: glibc
Version: 2.18
Status: NEW
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: pchang9 at cs dot wisc.edu
CC: drepper.fsp at gmail dot com
Hi,
In latest git commit a442b23, I notice memcpy() has different behavior
when statically linked on x86_64. Specifically, the test program has three
character arrays "a", "b" and "c". It copies the whole "b" to "a" by memcpy()
and prints the last element of "b" before exiting. Before the memcpy(),
I intentionally set the x86 DF flag by "std" instruction. When dynamically
linked with x86_64 multiarch library, it works correctly.
pcchang@T420 ~/glibc_bug $ cat test.c
#include <stdio.h>
#include <string.h>
void main(void) {
char a[65536];
char b[] = { [0 ... 65535] = 'b'};
char c[] = { [0 ... 65535] = 'c'};
printf("b[65535] before memcpy(): %c\n", b[65535]);
asm volatile ("std");
memcpy(a, b, sizeof(a));
printf("b[65535] after memcpy(): %c\n", b[65535]);
}
pcchang@T420 ~/glibc_bug $ gcc -O0 -ggdb test.c -o test
pcchang@T420 ~/glibc_bug $ ./test
b[65535] before memcpy(): b
b[65535] after memcpy(): b
pcchang@T420 ~/glibc_bug $
However, when statically linked, the content of array "b" changes.
pcchang@T420 ~/glibc_bug $ gcc -O0 -ggdb test.c -o test -static
pcchang@T420 ~/glibc_bug $ ./test
b[65535] before memcpy(): b
b[65535] after memcpy(): c
pcchang@T420 ~/glibc_bug $
The problem seems to be the "movsq" in sysdeps/x86_64/memcpy.S after label
"L(fast)", which implicitly assumes the DF flag is clear.
--
You are receiving this mail because:
You are on the CC list for the bug.