From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11837 invoked by alias); 9 Jul 2002 03:00:14 -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 11785 invoked from network); 9 Jul 2002 03:00:11 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 9 Jul 2002 03:00:11 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C61A23CC5 for ; Mon, 8 Jul 2002 22:59:58 -0400 (EDT) Message-ID: <3D2A51AE.3080102@ges.redhat.com> Date: Mon, 08 Jul 2002 20:00:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: ``struct location'' Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00088.txt.bz2 Hello, This is a hunch. I think there should be a ``struct location'' object to go with the ``struct type'' object. The ``struct value'' object would then be made of, the TYPE, LOCATION and, once the value has been read from memory, its VALUE. This would make it possible for location expression evaluators and similar (e.g., unwind functions describing register locations) to return a ``location'' without any need to refer to types. Having the location as an abstraction would also make it possible for GDB's ``location'' code to evolve independantly of the ``struct value'' - this is something we know we need since at present GDB can't describe things like values with a location that spreads across multiple registers and memory. thoughts? Andrew