From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24669 invoked by alias); 22 Mar 2002 23:28:38 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 24648 invoked from network); 22 Mar 2002 23:28:35 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 22 Mar 2002 23:28:35 -0000 Received: from [192.168.1.100] (pool-151-204-231-67.bos.east.verizon.net [151.204.231.67]) (authenticated (0 bits)) by dberlin.org (8.11.6/8.11.6) with ESMTP id g2MNSYm17512; Fri, 22 Mar 2002 18:28:34 -0500 Subject: Re: dwarf3 and location expressions et. al From: Daniel Berlin To: gdb@sources.redhat.com Cc: ac131313@cygnus.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: Fri, 22 Mar 2002 15:28:00 -0000 Message-Id: <1016839714.15707.50.camel@localhost.localdomain> Mime-Version: 1.0 X-SW-Source: 2002-03/txt/msg00203.txt.bz2 > I'm wondering if the thing to do is to map (baton, frame) onto a > ``struct expression'' rather than directly onto a ``struct value''. I'm > wondering of the CFI stuff should also do this. CFI definitely can't be supported with the current expression ops. > Once you have an expression for a variable, it should be possible to use > existing infrastructure to evaluate or encode it. Not without adding a few opcodes, and trying to figure out a nice mapping. I tried this once, and it didn't work out so well. It also adds another layer. Since the expressions are built on the fly, we'll end up reading a location expression , then converting it, then evaluating it. Rather than just reading it and evaluating it. In addition, expression evaluation is language specific. DWARF2 locations are not. > This also has the advantage of keeping expresion evaluation in one place > - if the expression evaluation is ever made asynchronous then there is > only one evaluator to fix for instance. You've looked at this from the wrong level. Expressions in GDB are analogous to language-dependent trees in gcc. DWARF2 locations are analagous to a mid-level RTL (IE pretend GCC's RTL was language and machine independent. We'll have a mid-level RTL soon). The language-dependent trees have type information, and all kinds of language specific semantics. mid-RTL has no types, and can be evaluated without any regard to the language involved. Same with gdb expressions (language dependent semantics, language specific ops, type information) vs dwarf2 locations (language independent, no type info). You don't want to mix layers like you are suggesting. It leads to evil. In effect, converting dwarf2 locations to struct expression's and evaluating would be like converting RTL back to C and compiling it.