Re: CIE return address register

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

Felix Burton writes:
>=== BACKGROUND
>
>The description of the return_address_register in section 6.4.1 specifies
>that
>a "ubyte" constant represents the column in the rule table.  To my knowledge
>this is the only place a ubyte is used instead of a uleb128.
>
>=== PROPOSAL
>
>Change the description to:
>
>7. return_address_register
>   A uleb128 constant that indicates which column in the rule table
>represents the
>   return address of the function. Note that this column might not
>correspond to an
>   actual machine register.

The existing restriction of a maximum of 255 for the
column in the rule table is not maximally flexible, but
the proposed change  
  a) is not binary compatible 
  b) is not really necessary.
The mapping of frame columns (including the column representing 'return
address') to hardware registers etc is completely implementation
determined: the spec only says (or implies by the ubyte value):
	Be sure to assign  'return address' to a column
	number >=0 and <= 255.
*in the dwarf numbers assigned*.

Even a machine with more than 255 registers (IA-64 is one
such) could have the 'return
address' concept be assigned a column number  >=0 and <= 255.
Independent of how the registers are numbered by the hardware
vendor/chip manufacturer.  Note that every machine seems
to have multiple disjoint sets of registers numbered
starting from 0 or 1 anyway, and some registers
that don't have numbers at all.  So some arbitrary mapping
to dwarf is required.

I could be missing something here, but I don't see why
the change is necessary, and I don't see a way around
the binary compatibility issue (short of changing version number).

I sympathize with the idea of a 'natural integer register mapping'
for the base integer registers, (if that is the motivator here)
but I don't like breaking binary compatibility...

Could you comment on the proposal's motivation, Felix?

Regards,
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/