[Bug libc/28572] Misaligned accesses in test-memcpy and test-mempcpy on hppa

["dave.anglin at bell dot net" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28572

--- Comment #2 from dave.anglin at bell dot net ---
On 2021-11-09 12:42 p.m., adhemerval.zanella at linaro dot org wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=28572
>
> Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |adhemerval.zanella at linaro dot o
>                     |                            |rg
>
> --- Comment #1 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
> I think the recent change of test-memcpy.c
> (d585ba47fcda99fdf228e3e45a01b11a15efbc5a) might have triggered an hidden bug
> on generic implementation.  Could we get the input parameters that triggered
> the first fault?
I suspect the unaligned accesses are in the test code:
ld.so.1(9795): unaligned access to 0x00000000f9a39001 at ip=0x0000000000011e33

(gdb) r
Starting program: /home/dave/gnu/glibc/objdir/elf/ld.so.1 --library-path 
/home/dave/gnu/glibc/objdir:/home/dave/gnu/glibc/objdir/math:/home/dave/gnu/glibc/objdir/elf:/home/dave/gnu/glibc/objdir/dlfcn:/home/dave/gnu/glibc/objdir/nss:/home/dave/gnu/glibc/objdir/nis:/home/dave/gnu/glibc/objdir/rt:/home/dave/gnu/glibc/objdir/resolv:/home/dave/gnu/glibc/objdir/mathvec:/home/dave/gnu/glibc/objdir/support:/home/dave/gnu/glibc/objdir/crypt:/home/dave/gnu/glibc/objdir/nptl 
/home/dave/gnu/glibc/objdir/string/test-memcpy
[Attaching after process 9792 fork to child process 9795]
[New inferior 2 (process 9795)]
[Detaching after fork from parent process 9792]
[Inferior 1 (process 9792) detached]
                         memcpy  builtin_memcpy  simple_memcpy

Thread 2.1 "ld.so.1" received signal SIGBUS, Bus error.
[Switching to process 9795]
0x00011e30 in ?? ()
(gdb) disass $pc-16,$pc+16
Dump of assembler code from 0x11e20 to 0x11e40:
    0x00011e20:  ldo 2d0(r15),r15
    0x00011e24:  ldi 0,ret0
    0x00011e28:  cmpb,= ret0,r11,0x11e40
    0x00011e2c:  shladd,l ret0,2,r10,r22
=> 0x00011e30:  stw ret0,0(r22)
    0x00011e34:  ldo 1(ret0),ret0
    0x00011e38:  cmpb,<> ret0,r11,0x11e30
    0x00011e3c:  shladd,l ret0,2,r10,r22
End of assembler dump.
(gdb) p/x $r22
$1 = 0xf9a39001
(gdb) p/x $ret0
$2 = 0x0
(gdb) p/x $r10
$3 = 0xf9a39001

This is in do_test1:
(gdb) break *0x00011e30
Breakpoint 1 at 0x11e30: file test-memcpy.c, line 253.
(gdb) list test-memcpy.c:253
248       size_t i;
249       size_t repeats;
250       for(repeats = 0; repeats < 2; repeats++)
251         {
252           for (i = 0; i < array_size; i++)
253             src[i] = (uint32_t) i;
254           FOR_EACH_IMPL (impl, 0)
255             {
256               memset (dest, -1, size);
257               CALL (impl, (char *) dest, (char *) src, size);

It looks like src is misaligned.

So far, I haven't been able to run test directly.  When I try to run it
directly, I get a divide by 0 trap in
__nptl_tls_static_size_for_stack():

/* Compute the size of the static TLS area based on data from the
    dynamic loader.  */
static inline size_t
__nptl_tls_static_size_for_stack (void)
{
   return roundup (GLRO (dl_tls_static_size), GLRO (dl_tls_static_align));
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.