From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5888 invoked by alias); 9 May 2011 14:54:11 -0000 Received: (qmail 5873 invoked by uid 22791); 9 May 2011 14:54:09 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_CP,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 May 2011 14:53:49 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p49Erf3r004373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 May 2011 10:53:41 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p49ErfpI005291; Mon, 9 May 2011 10:53:41 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p49EreIj011199; Mon, 9 May 2011 10:53:40 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 10164378498; Mon, 9 May 2011 08:53:39 -0600 (MDT) From: Tom Tromey To: Yao Qi Cc: gdb-patches@sourceware.org Subject: Re: RFC: fix `gdb -write' case References: <4DC75B31.2020501@codesourcery.com> Date: Mon, 09 May 2011 14:54:00 -0000 In-Reply-To: <4DC75B31.2020501@codesourcery.com> (Yao Qi's message of "Mon, 09 May 2011 11:10:41 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 X-SW-Source: 2011-05/txt/msg00218.txt.bz2 >>>>> "Yao" == Yao Qi writes: Tom> https://bugzilla.redhat.com/show_bug.cgi?id=696148 Yao> FYI, I can't access this bug. I am told "You are not authorized to Yao> access bug #696148." Oops, sorry. It is a private bug -- not for any good reason AFAICT, but I can't change it. Here is Jan's one-line reproducer: echo 'char s[]="a";main(){return s[0]=='"'a';}"|gcc -o v -x c - -g;./v;echo $?;~/redhat/gdb-6.8/gdb/gdb -nx -write ./v -ex 'set var s="b"' -ex q;./v;echo $? Tom> + result = allocate_value (expect_type); Tom> + memcpy (value_contents_raw (result), obstack_base (&output), Tom> + obstack_object_size (&output)); Yao> Compared with value_cstring, the difference is that expect_type is used Yao> here, while type used in value_cstring is got from lookup_array_range_type. Yao> struct type *stringtype Yao> = lookup_array_range_type (char_type, lowbound, highbound + lowbound Yao> - 1); Yao> Any difference on these two type variables (expect_type vs. stringtype)? Yes. You can wind up with a different "char" type following the logic in c-lang.c. In this case some higher level will try to cast the string to the correct type, which will try to force it to memory, leading to the bad result. The checks in the patch are intended to ensure that the expected type isn't "too weird" -- that we don't do something nonsensical. Tom