Re: Unwinding CFI gcc practice of assumed `same value' regs

[Roland McGrath <roland@redhat.com>]

GCC's unwinder doesn't distinguish undefined from same_value, because it
doesn't matter for EH unwinding purposes.  Both mean "nothing to be done
for this register".  The distinction only matters to informative unwinding
purposes like debugging.  I'm not sure why libgcc's unwinder really ought
to care.  It's not that I'm against it knowing the difference; that
certainly seems a cleaner way for it to be internally.  But as to the idea
that it needs to distinguish them for correctness, and thus other things
need to rely on having a libgcc_s version that does, and so forth, I don't
see the motivation.  

In the ideal world, things would use cfi_undefined on the pc regno to
indicate the base frame, as the dwarf3 spec says to.  I certainly think it
would be cleanest for everything to do that.  But again, in practice on
i386 and x86_64, I'm not sure I see the need.  Correct unwind info should
always restore the caller's bp register value.  When that unwinds to the
outermost frame, that will be a zero value as the runtime code of base
frames sets it.  

My reading is that the "ABI authoring body" for GNU systems or the
"compilation system authoring body" for GNU compilers already specifies
that the default rule is same_value for callee-saves registers (as chosen
by each particular ABI), even if this has not been formally documented
anywhere heretofore.  (This is how I've written ABI support in another
unwinder implementation I've worked on.)  As you've said, this is the only
reading by which current CFI is correct and complete for getting the values
of callee-saves registers.  I presume that GCC's omission of rules for
those registers is in fact simply because EH unwinding doesn't care and
people on the generation side just didn't think about it beyond that.
Regardless of the true reasons for the history, the description above
applies to the manifest practice that constitutes what we want the formal
specification to mean.


Thanks,
Roland