From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81182 invoked by alias); 22 Apr 2016 12:30:55 -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 81166 invoked by uid 89); 22 Apr 2016 12:30:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 22 Apr 2016 12:30:53 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3110FC04B30B; Fri, 22 Apr 2016 12:30:52 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3MCUpet023568; Fri, 22 Apr 2016 08:30:51 -0400 Subject: Re: [PATCH 1/2] Use -fno-asynchronous-unwind-tables if C program is compiled without debug info on x86 To: Yao Qi References: <1461052220-10149-1-git-send-email-yao.qi@linaro.org> <1461052220-10149-2-git-send-email-yao.qi@linaro.org> <57163425.1070505@redhat.com> <86wpnsiskw.fsf@gmail.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <571A197A.5030201@redhat.com> Date: Fri, 22 Apr 2016 12:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <86wpnsiskw.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00517.txt.bz2 On 04/20/2016 09:37 AM, Yao Qi wrote: > Pedro Alves writes: > >> No sure about this. This is an ABI change on x86_64 -- the x86_64 ABI >> requires eh_frame. > > This is because people want to unwind frames without using frame > pointer register (registers are very limited on x86), so different > tools, like glibc's backtrace and libunwind, can use eh_frame to unwind > correctly. Then, ABI requires eh_frame. I believe unwind frames are also necessary for pthread cancellation and thread_cleanup_push implemented in terms of gcc's __attribute__ __cleanup__, in C programs. > > GDB is different, because it can still rely on the prologue unwinder if > no debug info. Which is heuristic and can (and does) thus fail sometimes. > On the other hand, GDB prologue unwinder should be > tested in case that no debug info is produced by compiler. Though that's not testing what the compiler will normally output with just "-On" and no -g. That's what in part what I was trying to convey -- the ABI change means we're not testing what people normally use. > We just use > -fno-asynchronous-unwind-tables to produce binaries to exercise GDB, so > I don't worry about ABI incompliance. Right. > >> >> Should we instead add a new "nounwind" option, and a few >> prologue-unwinder-specific tests? > > We don't know how prologue unwinder is used in each test case with > option "nodebug", so I am afraid we need to add "nounwind" to every > test case where option "nodebug" is used. I think most, if not all, "nodebug" tests will be about no symbol info, and aren't really about the unwinder at all. I was suggesting new tests specific for the prologue unwinder, not changing the existing tests. E.g., just something simple that runs to a function and does "backtrace" making sure the expected frames are visible. If we want to cover more cases, maybe do a test that single-steps through some body of code, and issues backtrace at every single-step, prologues/epilogues included, making sure "main" is always visible in the backtrace. We could actually have that test try "backtrace" with dwarf unwinding, and then the same but with the prologue unwinder. Whether forcing use of the prologue unwinder through compilation flags is the best way, not sure. A "maint set force-prologue-unwinder on" command would make it easier to make sure we test what we intend to test on all architectures, independent of program language, and independent of architecture. Plus, a test unit testing the prologue unwinder could then conveniently make use of debug info. (If such a test steps through dynamic symbol resolution / plts, then it's likely that it can only really work with dwarf unwinding, though I think it'd be a nice test to have and would likely expose bugs in glibc's cfi markers in assembly code.) Thanks, Pedro Alves