From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55478 invoked by alias); 3 Jan 2018 21:53:14 -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 55464 invoked by uid 89); 3 Jan 2018 21:53:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=3594 X-HELO: mail-qt0-f194.google.com Received: from mail-qt0-f194.google.com (HELO mail-qt0-f194.google.com) (209.85.216.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 Jan 2018 21:53:11 +0000 Received: by mail-qt0-f194.google.com with SMTP id g9so3868011qth.9 for ; Wed, 03 Jan 2018 13:53:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zUPc9YzyUoklCLo/tb3Ru5qMt3YgXu36iK+DN1Cd8ic=; b=d4lL9bR6WuIFeFD/PN1499RT2B1BBANEDuGIH3AtCdPp6KmMXP1gmMBGC/aZDPhNoN m+68ozvaPHswWmwTImIiMuFc3Ns3lDwQFIY4nbn6h/lFGUNJjZxC1kvpcG+MdYaZl4GK SXaG3HJfoDEfq6YWlXlFZvwhF37VbrL9mC6hmJUu1JKSOMyU1FRipGGiiyNwBzcbxB3H BJe4bNKOxiVynmUmG7oAzGdCgE7b9NySpDTHhcM3NmBqdbeToVouDTftNFwZsLfJ9tHd rgn9iWd1f45Gw+L3fQb8oUOKy5MNepwMeUj5/zzQqtU6MeRYnxLr4m/02hBYdhYJ7Y8F ipwg== X-Gm-Message-State: AKGB3mIJoXTvuv+drvFaoEuTZpw87U/JEFf467StNeFItKBMkMIG3gBD //QJRXeaqvkMxKKzXsEdHwyy6AHN5PTrqQIlgmU= X-Google-Smtp-Source: ACJfBosy91BqCrI8bgJ3eDYDJawNN4YQ0UKo9tuBQuNeqgXGNDfuVmAzNna5ezJfhkxnS3ZF/AbEslG371l+oXwui/8= X-Received: by 10.200.63.107 with SMTP id w40mr3688868qtk.24.1515016390002; Wed, 03 Jan 2018 13:53:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.132.161 with HTTP; Wed, 3 Jan 2018 13:53:09 -0800 (PST) In-Reply-To: <9860ca45c4896a0e42190f4c34c68c4a@polymtl.ca> References: <20171216145651.13936-1-simon.marchi@polymtl.ca> <20171216145651.13936-2-simon.marchi@polymtl.ca> <9860ca45c4896a0e42190f4c34c68c4a@polymtl.ca> From: Yao Qi Date: Wed, 03 Jan 2018 21:53:00 -0000 Message-ID: Subject: Re: [PATCH 2/2] Fix gdb.mi/mi-stack.exp when gcc generates a stack protector To: Simon Marchi Cc: GDB Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00039.txt.bz2 On Tue, Jan 2, 2018 at 6:14 PM, Simon Marchi wrot= e: > On 2018-01-02 05:38, Yao Qi wrote: >> Can't we fix GDB to skip these stack protection code? > > > I think it would be desirable to consider the stack protection code as pa= rt > of the prologue, since it's compiler-generated and of little interest to = the > user. But I don't know how to do it without breaking existing behavior. > Yes, we can skip them as part of skipping prologue. > Our heuristic, when using SaL to skip prologue, is to consider the first > linetable entry to represent the prologue. If we find a consecutive entry > with the same line number, we assume it's the prologue -> body transition > (because otherwise there would be no point in having a separate entry). > When adding a stack protector, gcc puts it in a separate linetable entry,= as > if it was user code, so GDB thinks it's the beginning of the body. > > Let's take this small example: > > 1 int main() > 2 { > 3 int n =3D 0; > 4 n++; > 5 return n; > 6 } > > Which compiles to this with -fstack-protector-all: > > 0x0000000000400546 <+0>: push %rbp > 0x0000000000400547 <+1>: mov %rsp,%rbp > 0x000000000040054a <+4>: sub $0x10,%rsp > 0x000000000040054e <+8>: mov %fs:0x28,%rax > 0x0000000000400557 <+17>: mov %rax,-0x8(%rbp) > 0x000000000040055b <+21>: xor %eax,%eax > 0x000000000040055d <+23>: movl $0x0,-0xc(%rbp) > 0x0000000000400564 <+30>: addl $0x1,-0xc(%rbp) > 0x0000000000400568 <+34>: mov -0xc(%rbp),%eax > 0x000000000040056b <+37>: mov -0x8(%rbp),%rdx > 0x000000000040056f <+41>: xor %fs:0x28,%rdx > 0x0000000000400578 <+50>: je 0x40057f > 0x000000000040057a <+52>: callq 0x400420 <__stack_chk_fail@plt> > 0x000000000040057f <+57>: leaveq > 0x0000000000400580 <+58>: retq > > test.c 2 0x400546 > test.c 2 0x40054e > test.c 3 0x40055d > test.c 4 0x400564 > test.c 5 0x400568 > test.c 6 0x40056b > > GDB currently assumes that the second entry is the beginning of the body. > But ideally we would treat the first two entries as the prologue, and put > our breakpoint on line 3/0x40055d. > > And then let's look at this modified example, where the first line of code > is on the same line as the opening curly bracket, and compiled without st= ack > protection (-fno-stack-protector): > > 1 int main() > 2 { int n =3D 0; > 3 n++; > 4 return n; > 5 } > > > 0x00000000004004d6 <+0>: push %rbp > 0x00000000004004d7 <+1>: mov %rsp,%rbp > 0x00000000004004da <+4>: movl $0x0,-0x4(%rbp) > 0x00000000004004e1 <+11>: addl $0x1,-0x4(%rbp) > 0x00000000004004e5 <+15>: mov -0x4(%rbp),%eax > 0x00000000004004e8 <+18>: pop %rbp > 0x00000000004004e9 <+19>: retq > > test.c 2 0x4004d6 > test.c 2 0x4004da > test.c 3 0x4004e1 > test.c 4 0x4004e5 > test.c 5 0x4004e8 > > We have a similar line table as the previous example (same source line, > different address), but in this case the second entry at line 2 is really > the start of user code. We would want to put our breakpoint at line > 2/0x4004da. So, how do we differentiate these two cases? > When GDB sets breakpoint, it calls gdbarch_skip_prologue_noexcept to skip prologue, amd64 backend doesn't use SAL to identify the end of prologue unless compiler is clang (see amd64_skip_prologue). Instead, GDB scans prologue to find the end of prologue, so we can extend amd64 prologue analyzer to understand these instructions for stack protection. (gdb) b callee4 Thread 1 "gdb" hit Breakpoint 1, amd64_analyze_prologue (gdbarch=3Dgdbarch@entry=3D0x154ef60, pc=3Dpc@entry=3D4195734, current_pc=3Dcurrent_pc@entry=3D18446744073709551615, cache=3Dcache@entry=3D0x7fffffffd1e0) at ../../binutils-gdb/gdb/amd64-tdep.c:2319 2319 { (gdb) bt 10 #0 amd64_analyze_prologue (gdbarch=3Dgdbarch@entry=3D0x154ef60, pc=3Dpc@entry=3D4195734, current_pc=3Dcurrent_pc@entry=3D184467440737095516= 15, cache=3Dcache@entry=3D0x7fffffffd1e0) at ../../binutils-gdb/gdb/amd64-tdep.c:2319 #1 0x0000000000428b8c in amd64_skip_prologue (gdbarch=3D0x154ef60, start_pc=3D4195734) at ../../binutils-gdb/gdb/amd64-tdep.c:2488 #2 0x0000000000515363 in gdbarch_skip_prologue_noexcept (gdbarch=3Dgdbarch@entry=3D0x154ef60, pc=3Dpc@entry=3D4195734) at ../../binutils-gdb/gdb/arch-utils.c:970 #3 0x0000000000692b03 in skip_prologue_sal (sal=3Dsal@entry=3D0x7fffffffd4d0) at ../../binutils-gdb/gdb/symtab.c:3721 #4 0x0000000000692e02 in find_function_start_sal (sym=3Dsym@entry=3D0x158e8b0, funfirstline=3D1) at ../../binutils-gdb/gdb/symtab.c:3594 #5 0x00000000005fe0dd in symbol_to_sal (result=3Dresult@entry=3D0x7fffffffd6d0, funfirstline=3D, sym=3Dsym@entry=3D0x158e8b0) at ../../binutils-gdb/gdb/linespec.c:4611 We did something similar in arm-tdep.c, search "__stack_chk_guard". However, I am not sure we can find a "fingerprint" of these stack projection instructions on amd64. --=20 Yao (=E9=BD=90=E5=B0=A7)