This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/15931] New: memcpy() has different behavior when statically linked (x86_64)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]