From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72513 invoked by alias); 20 Apr 2016 08:38:07 -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 71071 invoked by uid 89); 20 Apr 2016 08:38:03 -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= X-HELO: mail-pa0-f41.google.com Received: from mail-pa0-f41.google.com (HELO mail-pa0-f41.google.com) (209.85.220.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 20 Apr 2016 08:37:57 +0000 Received: by mail-pa0-f41.google.com with SMTP id zm5so15782679pac.0 for ; Wed, 20 Apr 2016 01:37:56 -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=JazLD3zEYUmTbD+u+lak8Ke1Dg7QGaWqP+XZpmK+mfY=; b=LzLKjJeU9wAjPY6M9XM6Q1yi0SqckdZCIUlRBvd4wHStk44j9ZUWCHD62+LrnPU58Z ySxLSpNIg9SXp89UXMO7381LFLrM8bka21UlMJInEGFLPG5uDXP4TACa/aEacfrj9gbQ C7Bc3jZGTdVtp4uMvIB54tQXC4swCy/pKguquJ2hlQoexs41RNlgnIvqb5g9ZBzCQ/qN FJaomMTWyw9I2t63U7BN215BYhiTTFbZ7GKE7VQ1A2OUPABoq8RJRJqvTECr0ckPtCIR VdOOD6GbcRP91EsvoHH1Q7rHApoPLd7G/ptHnEnu/AqaWwuKqBiIXBVm4AGlVdjbq547 dUvQ== X-Gm-Message-State: AOPr4FUle4jF1O74ds+odJPxlPZD5kJyzR3YJhQcJIbYDa+0cgi/z6q35AIhv6pybz3K/A== X-Received: by 10.66.52.112 with SMTP id s16mr10573250pao.35.1461141475264; Wed, 20 Apr 2016 01:37:55 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id j62sm29339893pfb.15.2016.04.20.01.37.53 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 20 Apr 2016 01:37:54 -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> Date: Wed, 20 Apr 2016 08:38:00 -0000 In-Reply-To: <57163425.1070505@redhat.com> (Pedro Alves's message of "Tue, 19 Apr 2016 14:35:33 +0100") Message-ID: <86wpnsiskw.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/msg00476.txt.bz2 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. GDB is different, because it can still rely on the prologue unwinder if no debug info. On the other hand, GDB prologue unwinder should be tested in case that no debug info is produced by compiler. We just use -fno-asynchronous-unwind-tables to produce binaries to exercise GDB, so I don't worry about ABI incompliance. > > 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. --=20 Yao (=E9=BD=90=E5=B0=A7)