Re: PROPOSAL re CIE version number (new) [correction 2]

[davea at quasar dot engr dot sgi dot com (David B Anderson)]

|>1)  Are there any changes in the exiting operations and format?
|
|No.
|
|>2)  Are the new operations optional, that is, do current files conform to 
|>    the 000330.1, or does the proposal require a change?
|
|Yes (ie, no change). Two new operations are added, no existing ones are
|affected.
|
|>If the answer to (1) is no, and (2) is yes, then we should not have changed
|>the version number.  I'm not sure how we can show that there is a minor 
|>change in the version, but I'm also not sure that there is any need to.
|
|That is what I am thinking too.


I just checked the libdwarf reader,and it has a switch
that fails to check for an unexpected operation :-(

However, this is a correctable problem in libdwarf.

I guess your approach above is ok with me.

It does seem wise to indicate that these new ones *are* new
(somehow) so that someone reading the source to an older
consumer and reading the dwarf latest documentation (say 
a draft) could understand why the older consumer source
was missing the entries we are now defining.

And to indicate that an old consumer would, if properly written,
have given up when seeing an unexpected operation anyway.

Everything in frame stuff is so ABI-dependent this should not
be a problem. 

-------------

And, by the way, Felix' other proposal about debug_frame,
000403.1 happens to be completely compatible with
version 1 too, at least for MIPS.  Because the return
register value is < 127, a uleb number and a ubyte
happen to take the same amount of space  and have the
same bit representation!!

Are there any *real* cases (ABIs) where .debug_frame would NOT be
compatible with this return-register
field a uleb number, I wonder?

davea@sgi.com