From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9392 invoked by alias); 19 Dec 2007 16:01:28 -0000 Received: (qmail 9347 invoked by uid 22791); 19 Dec 2007 16:01:17 -0000 X-Spam-Check-By: sourceware.org Received: from wr-out-0506.google.com (HELO wr-out-0506.google.com) (64.233.184.238) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Dec 2007 16:01:11 +0000 Received: by wr-out-0506.google.com with SMTP id 60so2231403wri.8 for ; Wed, 19 Dec 2007 08:01:09 -0800 (PST) Received: by 10.142.251.9 with SMTP id y9mr223279wfh.43.1198080066936; Wed, 19 Dec 2007 08:01:06 -0800 (PST) Received: by 10.142.14.10 with HTTP; Wed, 19 Dec 2007 08:01:06 -0800 (PST) Message-ID: <4aca3dc20712190801o16d5ff60i72c9407fee026a09@mail.gmail.com> Date: Wed, 19 Dec 2007 16:12:00 -0000 From: "Daniel Berlin" To: "Alexandre Oliva" Subject: Re: Designs for better debug info in GCC Cc: "Diego Novillo" , "Mark Mitchell" , "Robert Dewar" , "Ian Lance Taylor" , "Richard Guenther" , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4766B8E5.60500@google.com> <4766DF5C.1020802@google.com> <47671BF4.5050704@google.com> <4aca3dc20712181519rb637c16oea78bbcc18abe097@mail.gmail.com> X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00574.txt.bz2 On 12/18/07, Alexandre Oliva wrote: > On Dec 18, 2007, "Daniel Berlin" wrote: > > >> int c = z; > >> whatever0(c); > >> c = x; > > > Because you have added information you have no way of knowing. > > How exactly did you compute that the call *definitely sets c to the > > value of z_0*, and definitely sets the value of c to x_2. > > Err... I guess you're thinking memory, global variables, alias > analysis and that sort of stuff. > Yes, i mixed your examples up, i apologize. > None of this applies to gimple registers, which is all the annotations > are about. > > > > However, value equivalene does not imply location equivalence, and all > > of our debug formats deal with locations of variables, except for > > constants. > > Dwarf enables arbitrary value expressions too. Well, uh, no. The only way to directly specify the value of a variable is for constants. DW_AT_const_value does not allow location descriptions. "An entry describing a variable or formal parameter whose value is constant and not represented by an object in the address space of the program, or an entry describing a named constant, does not have a location attribute. Such entries have a DW_AT_const_value attribute, whose value may be a string or any of the constant data or data block forms, as appropriate for the representation of the variable's value. The value of this attribute is the actual constant value of the variable, represented as it would be on the target architecture. " There are no other provisions in DWARF for describing the value of a variable, it is expected you describe their locations using DW_AT_location (which gives you the full power of location descriptions, but requires you to return a location, not a value) > There's some > discussion about lvalue vs rvalue in the document, and this is also > something that will take some experimenting. I'm not entirely sure > where to draw the line, and I'm not entirely sure there is a perfect > answer. I'm still curious where you think it describes value expressions for variables other than constants (which again, can't use the location description language) Again, i'd support such an extension, but it does not currently exist. Rest answers in other message.