From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26953 invoked by alias); 22 Oct 2014 14:22:36 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 26943 invoked by uid 89); 22 Oct 2014 14:22:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 22 Oct 2014 14:22:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 87A781161B5; Wed, 22 Oct 2014 10:22:31 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id E7A86Vg9mXLU; Wed, 22 Oct 2014 10:22:31 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 534441160D3; Wed, 22 Oct 2014 10:22:31 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 33FC940EBC; Wed, 22 Oct 2014 07:22:31 -0700 (PDT) Date: Wed, 22 Oct 2014 14:22:00 -0000 From: Joel Brobecker To: Yao Qi Cc: gdb-patches@sourceware.org Subject: over-permissive stack_chk_guard on ARM Message-ID: <20141022142231.GF4786@adacore.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-10/txt/msg00576.txt.bz2 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 3183 Hi Yao, I don't know if you remember, but we discussed an ARM patch back in Dec 2010, which was adding support for skipping stack-check-guard code as part of the prologue: https://www.sourceware.org/ml/gdb-patches/2010-12/msg00110.html I discovered that the heuristic used is mistakenly thinking that some code that fetches a global is some stack_chk_guard code, which, in turn, causes the debugger to skip it when inserting breakpoints. The full code is attached, but I suspect you will not have the Ada compiler to build it. But I can send you the binary if you need it. At this point, I am just trying to collect for more info. In our case, we're trying to insert a breakpoint on str.adb:4, where the code looks like this: 3 procedure STR is 4 XX : String (1 .. Blocks.Sz) := (others => 'X'); -- STOP 5 K : Integer; 6 begin 7 K := 13; Line 4 declares a new variable "XX" whihch is an array whose size is determined by the value of a global variable "Sz" from package "Blocks", and then assigns it an initial value (all 'X'-s). The generated code starts like this: (gdb) disass str'address Dump of assembler code for function _ada_str: --# Line str.adb:3 0x08000014 <+0>: push {r4, r7, lr} 0x08000016 <+2>: sub sp, #28 0x08000018 <+4>: add r7, sp, #0 0x0800001a <+6>: mov r3, sp 0x0800001c <+8>: mov r4, r3 --# Line str.adb:4 0x0800001e <+10>: ldr r3, [pc, #84] ; (0x8000074 <_ada_str+96>) 0x08000020 <+12>: ldr r3, [r3, #0] 0x08000022 <+14>: str r3, [r7, #20] 0x08000024 <+16>: ldr r3, [r7, #20] [...] When computing the address related to str.adb:4, GDB correctly resolves it to 0x0800001e first, but then considers the next 3 instructions as being part of the prologue because it thinks they are part of stack-protector code. As a result, instead of inserting the breakpoint at line 4, it skips those instruction and consequently the rest of the instructions until the next line start, which his line 7. Looking at the implementation of the prologue analyzing, it seems that a normal sequence would be what you put in the comments: ldr Rn, .Label .... .Lable: .word __stack_chk_guard But the implementation seems to be going further than that. If the location of the first ldr points to data that's not the address of __stack_chk_guard, then it looks at the next two instructions, to see if they might following another pattern: /* Step 2: ldr Rd, [Rn, #immed], encoding T1. */ /* Step 3: str Rd, [Rn, #immed], encoding T1. */ Looking at the code and the function description, it seems to me that the normal situation would be what the comment alluded to, and that if it was the entire story, we wouldn't have needed the code doing steps 2 & 3. But, looking at the email archives as well as the bug report initially referenced, I can't find really any explanation for what prompted you to add that code. I would need that in order to adjust the heuristics without breaking your situation. Do you remember, by any chance? -- Joel --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="blocks.ads" Content-length: 109 with System; package Blocks is SZ : Integer := 15; procedure Do_Nothing (A : System.Address); end; --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="blocks.adb" Content-length: 118 package body Blocks is procedure Do_Nothing (A : System.Address) is begin null; end Do_Nothing; end; --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="str.adb" Content-length: 200 with Blocks; procedure STR is XX : String (1 .. Blocks.Sz) := (others => 'X'); -- STOP K : Integer; begin K := 13; Blocks.Do_Nothing (XX'Address); Blocks.Do_Nothing (K'Address); end; --6TrnltStXW4iwmi0--