On 06/09/2016 09:07 PM, Charles Baylis wrote:
> This looks like a valgrind bug to me.
>
> I can reproduce the problem with this simple program, which shows the
> issue at any optimisation level.
>
> int main ()
> {
> asm volatile ("" : : : "r4", "r5");
> return 0;
> }
>
> [on my raspberry pi, with the system gcc]
> $ gcc test.c -mtune=cortex-a15 -marm
> $ valgrind ./a.out
> ==15850== Memcheck, a memory error detector
> ==15850== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==15850== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==15850== Command: ./a.out
> ==15850==
> ==15850== Invalid write of size 4
> ==15850==at 0x103E8: main (in /home/cgb23/a.out)
> ==15850== Address 0xbdcf34a4 is just below the stack ptr. To
> suppress, use: --workaround-gcc296-bugs=yes
> ...
>
> 000103e8 :
>103e8: e16d40fcstrdr4, [sp, #-12]!
>103ec: e58db008str fp, [sp, #8]
>103f0: e28db008add fp, sp, #8
>103f4: e3a03000mov r3, #0
>103f8: e1a3mov r0, r3
>103fc: e24bd008sub sp, fp, #8
>10400: e1cd40d0ldrdr4, [sp]
>10404: e59db008ldr fp, [sp, #8]
>10408: e28dd00cadd sp, sp, #12
>1040c: e12fff1ebx lr
>
> Without looking at the valgrind sources, I'd guess that valgrind isn't
> handling the strd instruction correctly.
Yes, this was my conclusion as well.
> "size 4" obviously isn't
> correct for the strd, and it also may not be accounting for the
> writeback of the stack pointer correctly. Looking at google, I found
> this bug report to the valgrind mailing list:
> https://sourceforge.net/p/valgrind/mailman/message/34632852/. It seems
> to relate to the same issue, but did not attract any attention. A
> brief look at the attached patch suggests that the problem is related
> to the way valgrind handles writes to the stack with negative offsets
> and writeback.
>
Thanks for the patch pointer. I looked at the patch. The special casing
of -8 in the original code looks like a hack to me. The patch looks
right to me. It just removes the special casing of -8 and does the same
for all negative values. The comment is wrong. The logic is handling
the [SP, #-k]! form (Note the -> ! <-). Negative values w/o the SP
update would still generate an error.
Will the compiler ever generate:
strd Rd, [SP, Rm]!
or strd Rd, [SP, Rm, LSL #k]!
where Rm is negative (or at all?)
Valgrind would currently not handle these cases at all.
> The suggested --workaround-gcc296-bugs=yes option does seem to
> suppress the error. Alternatively, since the compiler will only use
> STRD/LDRD in the prologue and epilogue when compiling for cores with
> an out-of-order microarchitecture, you can workaround the problem by
> compiling with -mcpu=cortex-a7, in which case it will use PUSH and POP
> instead
>
>
>
> On 9 June 2016 at 22:22, William Mills wrote:
>> Hello,
>>
>> We have been using Linaro GCC 5.x[1] and valgrind.
>>
>> When the optimizer is turned on valgrind complains about writes beyond
>> the current stack pointer. With the optimizer off, the problem report
>> goes away.
>>
>> I have my own conclusion about what is going on but I won't bias you
>> with it. Here are the facts:
>>
>> All files and logs attached as 10K tar.gz if it survives this maillist.
>>
>> test.c:
>> #include
>>
>> int main(int argc,char** argv)
>> {
>> int i;
>>
>> for (i = 1; i < argc; i++) {
>> printf("argument is %s\n", argv[i]);
>>}
>>
>>return 0;
>> }
>>
>> $ arm-linux-gnueabihf-gcc -march=armv7ve -marm -mfpu=neon \
>> -mfloat-abi=hard -mcpu=cortex-a15 -O2 -g \
>> -o test-fail test.c
>>
>>
>> $ valgrind --leak-resolution=high --track-origins=yes \
>> --trace-children=yes --leak-check=full --error-limit=no \
>> ./test-fail arg1 arg2 arg3
>>
>> ==20011== Memcheck, a memory error detector
>> ==20011== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
>> ==20011== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
>> ==20011== Command: ./test-fail arg1 arg2 arg3
>> ==20011==
>> ==20011== Invalid write of size 4
>> ==20011==at 0x10300: main (test.c:4)
>> ==20011== Address 0xbdbfcb58 is on thread 1's stack
>> ==20011== 24 bytes below stack pointer
>> ==20011==
>>
>> 000102f8 :
>>102f8: e351cmp r0, #1
>>102fc: da14ble 10354
>>10300: e16d41f8strdr4, [sp, #-24]! ; 0xffe8
>> Complaint is here
>>
>>10304: e1a05001mov r5, r1
>>10308: e3a04001mov r4, #1
>>1030c: e1cd60f8strdr6, [sp, #8]
>>10310: e300748cmovwr7, #1164 ; 0x48c
>>10314: e1a06000mov r6, r0
>>10318: e3407001movtr7, #1
>>
