Ian Lance Taylor 479872227c runtime: avoid libc memmove and memclr ...

The libc memmove and memclr don't reliably operate on full memory words.
We already avoided them on PPC64, but the same problem can occur even
on x86, where some processors use "rep movsb" and "rep stosb".
Always use C code that stores full memory words.

While we're here, clean up the C code. We don't need special handling
if the memmove/memclr pointers are not pointer-aligned.

Unfortunately, this will likely be slower. Perhaps some day we can
have our own assembly code that operates a word at a time,
or we can use different operations when we know there are no pointers.

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/685178

2025-07-08 15:49:16 -07:00

..

aeshash.c

…

arch.h

…

array.h

…

defs.h

…

env_posix.c

…

go-assert.c

…

go-assert.h

…

go-caller.c

…

go-callers.c

…

go-cgo.c

…

go-construct-map.c

…

go-context.S

…

go-ffi.c

…

go-fieldtrack.c

…

go-libmain.c

…

go-main.c

…

go-matherr.c

…

go-memclr.c

runtime: avoid libc memmove and memclr

2025-07-08 15:49:16 -07:00

go-memequal.c

…

go-memmove.c

runtime: avoid libc memmove and memclr

2025-07-08 15:49:16 -07:00

go-mmap.c

…

go-nanotime.c

…

go-nosys.c

syscall: don't define syscall stub on Hurd

2024-10-30 11:33:07 -07:00

go-now.c

…

go-reflect-call.c

…

go-setenv.c

…

go-signal.c

…

go-strerror.c

…

go-string.h

…

go-unsafe-pointer.c

…

go-unsetenv.c

…

go-unwind.c

…

go-varargs.c

…

panic.c

…

print.c

…

proc.c

…

rtems-task-variable-add.c

…

runtime_c.c

…

runtime.h

…

stack.c

…

yield.c

…