From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106085 invoked by alias); 16 May 2017 07:53:59 -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 106034 invoked by uid 89); 16 May 2017 07:53:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:Tue X-HELO: mail-pf0-f179.google.com Received: from mail-pf0-f179.google.com (HELO mail-pf0-f179.google.com) (209.85.192.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 May 2017 07:53:56 +0000 Received: by mail-pf0-f179.google.com with SMTP id m17so76196795pfg.3 for ; Tue, 16 May 2017 00:53:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=FcnVk9ACKXN9FKgSCGir9YWAJ3VmB/mzvbp8PmgBMvg=; b=lBEk/sHJ7HVi/gho1SopnIcpD+bvrty6MOR5hQO2s1v8XmucF/6tfn0kOuFh3+7867 vObJ8Z5EQnSWepek2+5sXv+DC28F2nt5O8nacLm58nz8pwXUAntxk4ga2Itory0C4nEa 3KXbQRpXR4f/xV2gVcMlqCs4GPEmYdtVFw8EYAB3m75XRcHLVA7dlSqzd2k8Ze/QvZf+ vDj2OAxWl3ITxMCJF+lujEYhFskwxQMeDub1AYLGxpyr0vbUqtsA3XKgZayirO+PnmM8 cKL0Ps6CkUZWEUx9qjZ4RiTl2zQhW6UfnwVeAazeoRF5l2RT47VlJnWUrs+vvcOl042N JfYQ== X-Gm-Message-State: AODbwcCVQkcrRuzwhpuKMZ2dleOfuU2W6EYW61NJQY5Z0GM7SSLUp/Yz RodD95XLdGdXUw== X-Received: by 10.84.137.3 with SMTP id 3mr13941014plm.68.1494921237901; Tue, 16 May 2017 00:53:57 -0700 (PDT) Received: from E107787-LIN (gcc114.osuosl.org. [140.211.9.72]) by smtp.gmail.com with ESMTPSA id u78sm23512130pfa.47.2017.05.16.00.53.56 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 16 May 2017 00:53:57 -0700 (PDT) From: Yao Qi To: Andreas Arnez Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v2 03/19] PR gdb/21226: Take DWARF stack value pieces from LSB end References: <1494352015-10465-1-git-send-email-arnez@linux.vnet.ibm.com> <1494352015-10465-4-git-send-email-arnez@linux.vnet.ibm.com> <86wp9icvnn.fsf@gmail.com> Date: Tue, 16 May 2017 07:53:00 -0000 In-Reply-To: (Andreas Arnez's message of "Mon, 15 May 2017 18:35:30 +0200") Message-ID: <86d1b9b5kf.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: 2017-05/txt/msg00324.txt.bz2 Andreas Arnez writes: >>> - const gdb_byte *val_bytes =3D value_contents_all (p->v.value); >>> + /* Use zeroes if piece reaches beyond stack value. */ >>> + if (p->size > stack_value_size_bits) >>> + break; >> >> Does this indicate something wrong in DWARF producer? Does GDB need to >> emit a complaint? > > I don't know any DWARF producer that would emit such a DWARF piece. > Whether it should be considered valid or not is unclear. Probably not. > But if we emit a complaint for such a piece, then all pieces will become > unusable just because GDB can't deal with that one piece. Before the > change, no complaint was emitted either; not sure if the author had > another reason for that. Oh, I thought it is you who add this check and "break" in this patch. I can't find such logic in the original code. --=20 Yao (=E9=BD=90=E5=B0=A7)