From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49536 invoked by alias); 22 Apr 2016 14:23:33 -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 49522 invoked by uid 89); 22 Apr 2016 14:23:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:10.67.14.98 X-HELO: mail-pa0-f50.google.com Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com) (209.85.220.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 22 Apr 2016 14:23:31 +0000 Received: by mail-pa0-f50.google.com with SMTP id zm5so40334521pac.0 for ; Fri, 22 Apr 2016 07:23:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=r6kVHJcb5/CnPaqz8rbbmWY1guFmnD6bkjUfmrAD464=; b=jvkUsn5/eohMitefW7KXK+wbHzZZrNTiPA2zlVOl0cIUqoekIO1RCCJ+JY6dcX7dHx gwsS3RPi6KYLTufFhW6cesPLdoUMNhEIXQ9IMJlypDKtvyfCM5ekU6aODGQiw9s3+uBN mI6EHh1Kn8Ss/yk+jrVr8PxkHfk5pERY72izDfuyRzmGsdwXGlmiX0UMS2nkR18dDe8L DDM0mPOYSsGieGnQOYa0TxVOY0N3UqtdAUmfu8jqQcQHHBybkCzftqV69n6dGYftOn45 foU9aequaqarFPhom8tduvHGFJbbsWeRnsaxmOMmqhaIbENq2HZ1RYgbMMnG1ZbR9XRg +5/A== X-Gm-Message-State: AOPr4FWuM924+G5g0nnk9HblUU/4c0jGsfZW1Gvgwj1/B0xhHFfJfIoWzLOyMfzH8XZzCw== X-Received: by 10.67.14.98 with SMTP id ff2mr28807535pad.105.1461335009533; Fri, 22 Apr 2016 07:23:29 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id r17sm8917812pfj.39.2016.04.22.07.23.26 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 22 Apr 2016 07:23:28 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH 1/2] Use -fno-asynchronous-unwind-tables if C program is compiled without debug info on x86 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> <571A197A.5030201@redhat.com> Date: Fri, 22 Apr 2016 14:23:00 -0000 In-Reply-To: <571A197A.5030201@redhat.com> (Pedro Alves's message of "Fri, 22 Apr 2016 13:30:50 +0100") Message-ID: <86y485hgdx.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00526.txt.bz2 Pedro Alves writes: > I think most, if not all, "nodebug" tests will be about no symbol info, > and aren't really about the unwinder at all. > It is quite common that gdb tests find some bugs of some thing which isn't these tests about. The test was written for feature A, but it may find bugs in feature B or C. > 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. > That must be useful. If debug infor is produced, it can be a good test to compiler. > Whether forcing use of the prologue unwinder through compilation flags > is the best way, not sure. A "maint set force-prologue-unwinder on" comm= and > 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. We had this idea too when we wrote aarch64 tracepoint support. We wanted to know which unwinder is chosen by GDB for a given frame. > > (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.) I want to focus on handling unavailable memory in frame unwinder, so I cannot do all of them above. What I can do are: 1. Name some unwinders, such as dwarf unwinders, prologue unwinders, sigtramp unwinders, stub unwinders, etc. Other unwinders are nameless. 2. Add a new maint command "maint set/show preferred-unwinder". This command tell GDB to prefer a unwinder during frame unwinding. If the unwinder can't be applied to the frame (sniffer fails), it is not chosen. 3. Prefer different unwinders (dwarf vs. prologue) in the different runs of gdb.trace tests, like foreach_with_prefix unwinder { "dwarf" "prologue" } { gdb_test "maint set preferred-unwinder $unwinder" gdb_test "tfind start" ..... gdb_test "tfind stop" } so that the PR 19947 can be reproduced. I'll stop here. What I don't plan to do in the short term are: - Write a case, let GDB single-step through its body, including prologue, epilogue and its callees, and check "bt" can show the frames correctly with different unwinders. - Single-step through dynamic symbol resolution / plt, prefer "dwarf" unwinder, and check "bt" can show the frames correctly. Is it OK to you? --=20 Yao (=E9=BD=90=E5=B0=A7)