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
