On 09/19/2017 03:08 AM, Andreas Schwab wrote: > On Sep 18 2017, Jeff Law <l...@redhat.com> wrote: > >> On 09/18/2017 10:09 AM, Andreas Schwab wrote: >>> On Sep 18 2017, Jeff Law <l...@redhat.com> wrote: >>> >>>> Can you confirm if the probe was in the red zone vs the live areas on >>>> the stack? >>> >>> It overwrites a nearby variable. sp + 8 happens to be the address of >>> file_entries_new_size. >>> >>> 0x000140e8 <+1172>: mov r6, sp >>> 0x000140ec <+1176>: add r3, r3, #7 >>> 0x000140f0 <+1180>: bic r3, r3, #7 >>> 0x000140f4 <+1184>: cmp r3, #4096 ; 0x1000 >>> 0x000140f8 <+1188>: bcc 0x14110 <save_cache+1212> >>> 0x000140fc <+1192>: sub r3, r3, #4096 ; 0x1000 >>> 0x00014100 <+1196>: sub sp, sp, #4096 ; 0x1000 >>> 0x00014104 <+1200>: cmp r3, #4096 ; 0x1000 >>> 0x00014108 <+1204>: str r0, [sp, #8] >>> 0x0001410c <+1208>: bcs 0x140fc <save_cache+1192> >>> 0x00014110 <+1212>: ldr r7, [r11, #-56] ; 0xffffffc8 >>> 0x00014114 <+1216>: sub sp, sp, r3 >>> 0x00014118 <+1220>: mov r1, #0 >>> 0x0001411c <+1224>: add r3, sp, #8 >>> 0x00014120 <+1228>: mov r0, r3 >>> => 0x00014124 <+1232>: str r0, [sp, #8] >>> >>> Andreas. >>> >> Or better yet, include your .i and .s files in their entirety and the >> gcc -v output > > This was generated with a very simple and incomplete backport of > -fstack-clash-protection to gcc7. What I get with your full patches > with gcc8 looks correct. Ah. FWIW, it looks almost as if you've got a sign wrong when probing the residual alloca allocation. THe "8" is also strange as I'd expect it to be "4" since words are 4 bytes on ARM.
I know some early bits had hardcoded "8" in some places, but I didn't think those had ever been posted -- I may have given them to Matz for him to play with. Are you using those perhaps? I expect to have a backport to gcc-7 now that things are unblocking on the trunk. You'd be welcome to work from those. It might save you some headaches. jeff
