From: Petr Sorfa <petrs@caldera.com>
To: Daniel Berlin <dan@dberlin.org>
Cc: Daniel Jacobowitz <drow@mvista.com>, gdb@sources.redhat.com
Subject: Re: Upcoming DWARF 3 and FORTRAN95 patches for 5.1.1 or 5.2?
Date: Fri, 18 Jan 2002 11:46:00 -0000 [thread overview]
Message-ID: <3C487A21.A01567E9@caldera.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0201181430490.25029-100000@dberlin.org>
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
----------------------------------------------------------
next prev parent reply other threads:[~2002-01-18 19:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-17 14:08 Petr Sorfa
2002-01-17 14:56 ` Daniel Jacobowitz
2002-01-17 15:07 ` Daniel Berlin
2002-01-17 15:10 ` Daniel Jacobowitz
2002-01-17 15:46 ` Petr Sorfa
2002-01-17 16:12 ` Daniel Berlin
2002-01-18 7:08 ` Petr Sorfa
2002-01-18 8:09 ` Petr Sorfa
2002-01-18 12:09 ` Daniel Berlin
2002-01-18 11:46 ` Petr Sorfa [this message]
2002-01-18 12:10 ` Daniel Berlin
2002-01-23 15:41 ` Jim Blandy
2002-01-23 16:18 ` Daniel Berlin
2002-01-23 16:36 ` Andrew Cagney
2002-01-23 17:10 ` Daniel Berlin
2002-01-23 16:38 ` Daniel Jacobowitz
2002-01-23 17:19 ` Daniel Berlin
2002-02-01 13:44 ` Jim Blandy
2002-02-04 9:13 ` Daniel Berlin
2002-02-04 17:13 ` Andrew Cagney
2002-02-15 12:47 ` Jim Blandy
2002-02-04 16:29 ` Andrew Cagney
2002-01-17 15:20 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C487A21.A01567E9@caldera.com \
--to=petrs@caldera.com \
--cc=dan@dberlin.org \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox