From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22875 invoked by alias); 18 Jan 2002 19:46:49 -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 22791 invoked from network); 18 Jan 2002 19:46:44 -0000 Received: from unknown (HELO nimbus.nj.caldera.com) (132.147.103.56) by sources.redhat.com with SMTP; 18 Jan 2002 19:46:44 -0000 Received: from caldera.com (IDENT:petrs@tetsuo [132.147.135.116]) by nimbus.nj.caldera.com (8.10.1/UW7.1.1-NSCd) with ESMTP id g0IJjYw13082; Fri, 18 Jan 2002 14:45:34 -0500 (EST) Message-ID: <3C487A21.A01567E9@caldera.com> Date: Fri, 18 Jan 2002 11:46:00 -0000 From: Petr Sorfa Reply-To: petrs@caldera.com Organization: Caldera X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Berlin CC: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00216.txt.bz2 Hi Daniel, > > A comment about the patch you mentioned before: > > http://sources.redhat.com/ml/gdb-patches/2001-06/msg00441.html > > > > I noticed that you put new entries into struct symbol of type locexpr. > > I'm not too sure if that is the correct to place them. In my > > understanding these location expressions need only be associated with > > the type of a symbol rather than the symbol itself. > No, it describes the location of a symbol, not of a type. > Two symbols of the same type could be in different places (one in > register, one in memory). > Think of location lists, too. > I could have two symbols of the same type in completely different places > in memory and registers, at a given time (IE each in two different live > ranges). Yes I agree for symbol location. However, other location expressions can describe the lower and upper bounds of an array, or its stride, associative and allocatable values. These are the ones that can be located in the symbol's type. The main reason behind this, is that these other locations are based off the location of the symbol. Petr > > This will remove > > unnecessary replication of data and save the extra few bytes. Or am I > > making to many assumptions here? > Also, part of the idea of using our own bytecode was being able to > describe the location of complex things, such a vtable entry, in a > portable way. -- -------------------------------------------------------- Petr Sorfa Senior Software Engineer Caldera 430 Mountain Ave. http://www.caldera.com Murray Hill 07974 NJ, USA -------------------------------------------------------- Disclaimer: All my comments are my own and nobody else's ----------------------------------------------------------