PROPOSAL re CIE version number (new) [correction]

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

From:	SMTP%"brender@gemevn.zko.dec.com" 21-APR-2000 11:00:51.89
To:	DWARF2-WG
CC:	BRENDER
Subj:	PROPOSAL re CIE version number (new)

PROPOSAL re CIE version number.


CONTEXT
-------

The CIE version number was "officially" changed to 2 as a result
of accepting 000330.1.


PROPOSAL
--------

Adopt alternative 1 below (change back to 1).

If that fails, adopt alternative 2 below (allow use of 1 under appropriate
circumstances).


DISCUSSION
----------

>I believe it is necessary to change the version number since there is no way
>for existing DWARF readers to skip the new CIE instructions.

Actually, even if there were a way to skip an unexpected instruction, it is
not clear that a valid operation, such as a traceback, would result from
simply leaving out the unknown step!

But how is this different than if in CIE version 1 a DWARF consumer encounters
a CIE vendor extension (one of the codes 0x1c-0x3f, see Fig 37/page 79)
that is from an "unknown" or "unsupported" vendor? In this case, the
DWARF debugger also has no way to skip the "foreign" instruction -- it
must abandon whatever operation is attempting to use the CIE information,
hopefully gracefully (for example, abort traceback, give error message to user,
etc).

If we bump the version number to 2, then a Dwarf V2.0 debugger is put in
a position where it *must* refuse to use any of the CIE information from
a Dwarf V2.1 producer, even if none of the new codes actually occur. While
"safe", that seems more contrary to our upward compatibility goals than
necessary. And this applies EVEN on machines other than the PowerPC!

>If somebody would like to generate CIE information with the old version
>number we have two options:
>
>1. Refer to the old document
>2. Describe what they should not use.

Alternative 1
-------------

I still suggest that restoring the version to 1 is appropriate.

Alternative 2
-------------

Option 2) is not all that hard to specify at least. For example, I might use
this text in 7.23:

    "The value of the CIE version number is 1, provided that no instruction
    whose code is in the range 0x0f-0x1b, inclusive, is used by that CIE
    or any FDE that refers to it; otherwise, the version number is 2."

This does put a bit more burden on a Dwarf V2.1 producer to either "look
ahead" to see if it is going to need one of the new codes before it generates
a CIE or to otherwise notice ahead of time that the need exists. (For example,
when generating code for the stack alignment in the PowerPC example, a flag
might be set in the routine "node" to indicate that one of the "extended" CIE
operations will be needed for DWARF purposes.)

Alternative 3
-------------

A weaker rule would allow, but not require, a Dwarf V2.1 producer to use
version 1 when appropriate. This rule might be stated using:

    "The value of the CIE version number may be 1, provided that no instruction
    whose code is in the range 0x0f-0x1b, inclusive, is used by that CIE
    or any FDE that refers to it; otherwise, the version number is 2.

    "<i>DWARF producers are encouraged to use a CIE version number of 1
    whenever feasible to facilitate use of newer DWARF V2.1 descriptions
    by existing DWARF V2.0 consumers.</i>"


================== RFC 822 Headers ==================
Date: Fri, 21 Apr 2000 10:56:01 -0400
Message-Id: <00042110560126@gemevn.zko.dec.com>
From: brender@gemevn.zko.dec.com (Ron 603-884-2088)
To: DWARF2@postofc.corp.sgi.com, BRENDER@gemevn.zko.dec.com
Subject: PROPOSAL re CIE version number (new)
X-VMS-To: DWARF2-WG
X-VMS-Cc: BRENDER