| Age | Commit message (Collapse) | Author |
|---|
|
The ARM implementation of memset has a bug when the fill-value is negative or outside the
[0, 255] range. To reproduce:
char array[256];
memset(array, -5, 256);
This is supposed to fill the array with int8 values -5, -5, -5, ... . On ARM, this does
not work because the implementation assumes the high bytes of the fill-value argument are
already zero. However in this test case they are filled with 1-bits. The aarch64 and x86_64
implementations do not have this problem: they first convert the fill-value to an unsigned
byte following the specification of memset.
With GCC one can use `memset(ptr, (-5 & 0xFF), size)` as a workaround, but for clang
users that does not work: clang optimizes the `& 0xFF` away because it assumes that
memset will do it.
Signed-off-by: Tom Bannink <tombannink@gmail.com>
Acked-by: Peter Korsgaard <peter@korsgaard.com>
|
|
The 'BLT' instruction checks for *signed* values. So if a3, length
parameter of memset, is negative, then value added to the PC will be
large.
memset(buf, 0xaa, 0xffff0000) triggers the bug.
GDB session without the patch:
"""
$ gdb ./main-buggy-memset.elf -q
Reading symbols from ./main-buggy-memset.elf...done.
(gdb) x/i memset
0x8770 <memset>: mov r3, r0
(gdb) r
Starting program: /root/memset/main-buggy-memset.elf
Program received signal SIGSEGV, Segmentation fault.
0x00048808 in ?? ()
"""
The $pc is outside of the memset function because:
"""
(gdb) x/i $pc
=> 0x87e4 <memset+116>: add pc, pc, r2, lsl #2
(gdb) info reg $r2
r2 0x10007 65543
"""
GDB session with the bug fixed (patch applied):
"""
$ gdb ./main-fixed-memset.elf -q
Reading symbols from ./main-fixed-memset.elf...done.
(gdb) x/i memset
0x8770 <memset>: mov r3, r0
(gdb) r
Starting program: /root/memset/main-fixed-memset.elf
Program received signal SIGSEGV, Segmentation fault.
memset () at libc/string/arm/memset.S:92
92 libc/string/arm/memset.S: No such file or directory.
(gdb) x/i $pc
=> 0x87b0 <memset+64>: stmia r3!, {r1, r12}
(gdb) info reg $r3
r3 0x15000 86016
(gdb) info proc mappings
process 5822
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x8000 0xb000 0x3000 0x0
/root/memset/main-fixed-memset.elf
0x12000 0x15000 0x3000 0x2000
/root/memset/main-fixed-memset.elf
0xb6fff000 0xb7000000 0x1000 0x0 [sigpage]
0xbefdf000 0xbf000000 0x21000 0x0
0xffff0000 0xffff1000 0x1000 0x0 [vectors]
(gdb) info reg $sp
sp 0x14d78 0x14d78
"""
GDB crashes inside the memset function, on the store instruction. This
time the crash is (as expected) because of a memory access imediately
after the memory region that contains the stack -- the buffer that's
being memset'd is allocated on the stack.
Signed-off-by: Lucian Cojocar <lucian.cojocar@vu.nl>
|
|
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
As Will noticed, the header this check is currently done in
is asm-only, and is not meant to be included from C code.
This breaks compilation when compiled for a Thumb2-aware CPU.
Move the BX check to its own header, and revert 7a246fd.
Reported-by: Will Newton <will.newton@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Will Newton <will.newton@gmail.com>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
This matches a similar change made to glibc.
No functional changes here.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
The attached patch adds support for compiling arm uClibc as pure Thumb code.
This is needed because some recent ARM codes do not implement traditional ARM
mode. Specifically:
* Cortex-M1 - An extremely minimal FPGA based core that only implements
Thumb-1 (aka ARMv6-M).
* Cortex-M3 - A Thumb-2 only ARMv7-M core.
Most of uClibc already builds in Thumb mode, all that is left are a handful of
assembly bits.
Tested on arm-uclinuxeabi.
|
|
add support for using BX instruction for THUMB aware architectures
|
|
missing headers, other jump relocs removed
|
|
where the non-hidden version was used.
|
|
|
|
|
|
do seem to make noticable speed improvement...
-Erik
|
