Re: 64-bit safe environment -- sorry, meant to cc all, not be private

[brender at gemevn dot zko dot dec dot com (Ron 603-884-2088)]

From:	SMTP%"brender@gemevn.zko.dec.com" 12-APR-2000 14:58:44.26
To:	SMTP%"eager@eagercon.com"
CC:	BRENDER
Subj:	Re: 64-bit safe environment

>Ron 603-884-2088 wrote:
>>
>>         "In a 64-bit safe environment, this field is an 8-byte unsigned
>>         offset."
>
>I saw this terminology in the draft and I have no idea what it means.
>What is a "64-bit safe environment"?  What does being safe mean?  
>(I thought that all of Dwarf2 was safe, or at least, not dangerous.)   

The definition of a "64-bit safe DWARF description" is intended to be
provided in Section 7.4, as proposed by 000331.1. There is a placeholder
there in the current draft1.

>Why are we talking about environments?  (There is no mention of environments 
>in the Dwarf2 standard.)  What is an environment in the context of a standard 
>debugging format?  Certainly Dwarf2 can be interpreted in whatever environment
>one chooses.  And why should we care?

It would help if I quoted myself accurately. The actual phrasiology is

	"In a 64-bit safe DWARF description, this field..."

So the word "environment" never occurs, so your concerns about its meaning
are unfounded.

>Proposal 991102.1, which has been adopted, describes modifications to 
>support 64-bit architectures.  

Yes, sorta. But as you observed during the multiple exchanges between
Dave Anderson and myself, that description was from far from clear in calling
out all of the implications of its few well chosen words. 

Actually, DWARF2 already has everything needed to "support 64-bit
architectures", as was noted in some of the discussion leading up to 991102.1.
What 991102.1 does is provide an alternative DWARF representation that can
"support" DWARF *descriptions* in which there are one or more sections whose
size exceeds 2**32 bytes. Since DWARF2 does does not allow such a description
which can conceivably be required, it is not completely "safe" for use on
64-bit architectures.

>Proposal 000331.1, which has NOT been adopted, uses this terminology.
>Proposals which have not been adopted should not be incorporated
>into the draft.  

I plead a bit guilty on this count, but I don't feel all that guilty. First,
I think it critical that we all understand all of the places that are impacted
by 991102.1 -- I sure didn't. So I did stray a tad ahead of the formal
consideration of 000331.1. Second, if after formal consideration the 000331.1
wording is abandoned or changed, I will happily bring the subsequent draft
into conformance. Third, this is still a "working" document -- not an end-
point which, if we all dropped dead this evening, could be adopted by the
world as is as a done deal. Finally, I already had explicit agreement from
Dave to adopt 000331.1 (3 Apr version) and no contrary thoughts from anyone
else, so I did not feel like I was acting fast and loose with the document.

>I hope that this is just some local (or IA64) jargon.  I do not see that 
>there is a concept here that needs to be incorporated in the Dwarf standard.  
>Whatever value it may have in the discussion of proposal 000331.1, material
>from an unapproved proposal shouldn't be in the draft.

No, it has nothing to do with IA64 or any local jargon. And it is not part
of the discussion of 000331.1, it is part of the proposal proper; that is,
it is a proposed technical phrase for DWARF itself if you will. I have no
special attachment to that phrase and am certainly open to alternatives to
consider as part of the discussion of 000331.1.

Ron
================== RFC 822 Headers ==================
Date: Wed, 12 Apr 2000 13:28:36 -0400
Message-Id: <00041213283669@gemevn.zko.dec.com>
From: brender@gemevn.zko.dec.com (Ron 603-884-2088)
To: eager@eagercon.com, BRENDER@gemevn.zko.dec.com
Subject: Re: 64-bit safe environment
X-VMS-To: SMTP%"eager@eagercon.com"
X-VMS-Cc: BRENDER