Message ID | 1428415783-15199-1-git-send-email-martin.galvan@tallertechnologies.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 66293 invoked by alias); 7 Apr 2015 14:09:56 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 66281 invoked by uid 89); 7 Apr 2015 14:09:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mail-qg0-f52.google.com Received: from mail-qg0-f52.google.com (HELO mail-qg0-f52.google.com) (209.85.192.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 07 Apr 2015 14:09:51 +0000 Received: by qgdy78 with SMTP id y78so20760694qgd.0 for <gdb-patches@sourceware.org>; Tue, 07 Apr 2015 07:09:49 -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:subject:date:message-id; bh=RQHt64XFGijm+4OgPOykYUpC8CoyuZb6/m72lJWR8Ok=; b=KRPNdoz64dtJNZTzyXcvX4qR1C4MNTuTPINScbdlMy7dOqJv9Ro/MyOvIfLiM4vAuG zEq/hErCiqtTV8r0Eks1ta6bT05GSvY18Iw3bw1xt2o2GRkGaTFW2pzYb+GOEigpPmND XcIUsi1Wp4IGGU6JEYzy9c6MOiPrxAKgPABwCnd5b/MI55CXzn/vwUQBm/tsdsXJK71W 5YOupD3JPZmHXwC9tQ1ow/wQp3ZYEcbBVwzAkVa/vbvjvkllo/r6o/HUkVloH2n4xk5Q 4c1JZri2WV9YAcl98uR45FWiXf0FUci8THFX5AGWXNujYWfU7hyIZxSRAwgvwnAwxwRc 3u1A== X-Gm-Message-State: ALoCoQlEfU0dJI9qbzXkAk4fyklT+uCcSTFkFGxLgFGW86AfVnri6rKXkPwyX1OMTeTOPMkA94b7 X-Received: by 10.229.95.74 with SMTP id c10mr24382358qcn.17.1428415789081; Tue, 07 Apr 2015 07:09:49 -0700 (PDT) Received: from martin-galvan.dominio.tallertechnologies.com ([200.69.202.173]) by mx.google.com with ESMTPSA id d11sm2462386qgd.31.2015.04.07.07.09.47 for <gdb-patches@sourceware.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Apr 2015 07:09:48 -0700 (PDT) From: Martin Galvan <martin.galvan@tallertechnologies.com> To: gdb-patches@sourceware.org Subject: [PATCH] Fix gdb crash when trying to print the address of a synthetic pointer. Date: Tue, 7 Apr 2015 11:09:43 -0300 Message-Id: <1428415783-15199-1-git-send-email-martin.galvan@tallertechnologies.com> |
Commit Message
Martin Galvan
April 7, 2015, 2:09 p.m. UTC
Trying to print the address of a synthetic pointer (such as a C++ reference after O3 optimization) will cause gdb to crash with the following message: ../gdb/dwarf2loc.c:1625: internal-error: Should not be able to create a lazy value with an enclosing type This patch fixes that by doing a check for synthetic pointers in value_addr and printing an error message. I have a company-wide copyright assignment. I don't have commit access, though, so it would be great if anyone could commit this for me. gdb/ 2015-04-07 Martin Galvan <martin.galvan@tallertechnologies.com> * valops.c (value_addr): Don't try to get the address of a synthetic pointer. --- gdb/valops.c | 7 +++++++ 1 file changed, 7 insertions(+) -- 2.3.5
Comments
Hi Martin, On 04/07/2015 03:09 PM, Martin Galvan wrote: > Trying to print the address of a synthetic pointer (such as a C++ reference after O3 optimization) will cause gdb to crash with the following message: > > ../gdb/dwarf2loc.c:1625: internal-error: Should not be able to create a lazy value with an enclosing type > > This patch fixes that by doing a check for synthetic pointers in value_addr and printing an error message. > > I have a company-wide copyright assignment. I don't have commit access, though, so it would be great if anyone could commit this for me. > Does this pass the testsuite? I seem to recall that the TYPE_CODE_REF path below is used by synthetic pointers, but I could well be wrong. Could you add some test to cover this? We have some <synthetic pointer> tests in gdb.dwarf2/implptr.exp. Maybe add something there? > gdb/ > 2015-04-07 Martin Galvan <martin.galvan@tallertechnologies.com> Two spaces before and after name. > > * valops.c (value_addr): Don't try to get the address of a synthetic pointer. Please wrap this at 80 cols. > > --- > gdb/valops.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/gdb/valops.c b/gdb/valops.c > index 66c63c1..66e2c9d 100644 > --- a/gdb/valops.c > +++ b/gdb/valops.c > @@ -1474,6 +1474,13 @@ value_addr (struct value *arg1) > struct value *arg2; > struct type *type = check_typedef (value_type (arg1)); > > + if (value_bits_synthetic_pointer(arg1, value_embedded_offset (arg1), Missing space before parens. > + TARGET_CHAR_BIT * TYPE_LENGTH (type))) > + { > + error (_("Attempt to take address of a synthetic pointer.")); > + return NULL; This "return" is never reached, as "error" throws. Please remove it, and then remove the then unnecessary braces. Thanks, Pedro Alves
On Tue, Apr 7, 2015 at 11:33 AM, Pedro Alves <palves@redhat.com> wrote: > Hi Martin, > > On 04/07/2015 03:09 PM, Martin Galvan wrote: >> Trying to print the address of a synthetic pointer (such as a C++ reference after O3 optimization) will cause gdb to crash with the following message: >> >> ../gdb/dwarf2loc.c:1625: internal-error: Should not be able to create a lazy value with an enclosing type >> >> This patch fixes that by doing a check for synthetic pointers in value_addr and printing an error message. >> >> I have a company-wide copyright assignment. I don't have commit access, though, so it would be great if anyone could commit this for me. >> > > Does this pass the testsuite? I seem to recall that the > TYPE_CODE_REF path below is used by synthetic pointers, but > I could well be wrong. For some reason this problem doesn't happen with some synthetic pointers, such as the "this" pointer in C++ (I assume those are handled by the TYPE_CODE_REF path). However, I can confirm this happens with C++ references if optimizing with gcc -O3. > Could you add some test to cover this? We have some <synthetic > pointer> tests in gdb.dwarf2/implptr.exp. Maybe add something there? Ok, will do it. >> gdb/ >> 2015-04-07 Martin Galvan <martin.galvan@tallertechnologies.com> > > Two spaces before and after name. > >> >> * valops.c (value_addr): Don't try to get the address of a synthetic pointer. > > Please wrap this at 80 cols. > >> >> --- >> gdb/valops.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/gdb/valops.c b/gdb/valops.c >> index 66c63c1..66e2c9d 100644 >> --- a/gdb/valops.c >> +++ b/gdb/valops.c >> @@ -1474,6 +1474,13 @@ value_addr (struct value *arg1) >> struct value *arg2; >> struct type *type = check_typedef (value_type (arg1)); >> >> + if (value_bits_synthetic_pointer(arg1, value_embedded_offset (arg1), > > Missing space before parens. > >> + TARGET_CHAR_BIT * TYPE_LENGTH (type))) >> + { >> + error (_("Attempt to take address of a synthetic pointer.")); >> + return NULL; > > This "return" is never reached, as "error" throws. Please remove it, > and then remove the then unnecessary braces. Will do. Thanks a lot!
diff --git a/gdb/valops.c b/gdb/valops.c index 66c63c1..66e2c9d 100644 --- a/gdb/valops.c +++ b/gdb/valops.c @@ -1474,6 +1474,13 @@ value_addr (struct value *arg1) struct value *arg2; struct type *type = check_typedef (value_type (arg1)); + if (value_bits_synthetic_pointer(arg1, value_embedded_offset (arg1), + TARGET_CHAR_BIT * TYPE_LENGTH (type))) + { + error (_("Attempt to take address of a synthetic pointer.")); + return NULL; + } + if (TYPE_CODE (type) == TYPE_CODE_REF) { /* Copy the value, but change the type from (T&) to (T*). We