BTW I used LR as return_address_register on s390 and ppc because there is no DWARF number for PC and the CFI seems wrongly addressing LR there (moreover under two different numbers - and really not that one of them should be PC).
return_address_register does not have to be a register number that has a meaning assigned in the spec. It is really just a private choice for the particular CIE. If there is no specified number for the PC, then it can be any number that is not specified as being for another particular register.
So in the case of ARM having real DWARF number for PC it should be probably used for return_address_register. But I do not know how to read .ARM.extab to verify how the unwind tables look there - if they use the register 15.
There is readelf -u in binutils and see https://wiki.linaro.org/KenWerner/Sandbox/libunwind#unwinding_on_ARM (actual spec in http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf ). And you can look at .debug_frame tables. But that's really neither here nor there. It doesn't matter what the compiler does for some particular FDEs (or for all that it emits). All that matters is that the number you choose for a particular CIE is the one that its FDEs describe correctly for rematerializing the return address and is not one specified to mean a particular register if the caller's value of that register has a value that is not the same as the return address.
For machines with a link-register calling convention, "the caller's value of the link register" is the same thing as "the return address" on entry. The benefit of distinguishing them is that you can more precisely describe what is required for unwinding without falsely stating that more is required. That is, the link register is call-clobbered in the ABI and to unwind to the caller it would be sufficient to set the PC to the return address while not restoring the link register. By using a different return_address_register, you could describe a situation where, e.g. the return address is recoverable from the stack or another register, but the link register per se will be left as "undefined". In the case of ARM, imagine the code:
mov r0, lr mov lr, #0 bx r0
Now, it would be correct enough to say that return_address_register is r0, that r0's rule is same-value, and that lr's rule is undefined (or is register r0, if you like). That is not entirely precise, since it says the caller's value of r0 was knowable when in fact it's undefined. But as to the return address and lr, it's perfectly correct and precise. In actual fact, the compiler would never generate code like that because the hardware makes it optimal always to use "bx lr" for return (it has a call/return prediction stack and "bx lr" is specifically recognized as "return").
So it's not really clear which is "better", because it depends on what your goals are.
If you just want to unwind and that's all, then it's best to arrange that unwinding does as little work as possible. It's not necessary to restore the caller's value to lr, since lr is call-clobbered anyway. So then it's better to use the PC number (or an unassigned number, on machines with no number assigned for the PC) as return_address_register and an undefined rule for lr. Depending on the code, that may even be a more precisely correct description, because the code might return to the caller's lr without putting that address back into lr:
push {..., lr} bl other_function @ clobber lr pop {..., pc} @ restore regs & return in one insn, leave lr clobbered
That is, the epilogue won't restore lr, so unwinding is closer to the effect of a natural return if it doesn't restore lr either.
For general debugging purposes, we usually say that the compiler should describe how to recover everything that truly can be recovered. (This is a different predicate from "everything that a natural return would actually restore".) So it's nice to describe lr with a rule other than undefined (i.e. same-value in the trivial case), because that means that when you go up a frame you can see the value the register truly had at the call site rather than being told it's unavailable. Then it just seems redundant and wasteful to use a different value for return_address_register, because then you need to process pc=lr rule as well (or if lr is no longer same-value, you need to repeat the same rule for lr and for return_address_register).
OTOH, if return_address_register != lr and the rule for return_address_register gives a location that is mutable (i.e. some other register or memory location) and that location is not also used in some other register's rule, then the CFI describes how you can change the machine state to warp the eventual return of the frame without changing any caller register. From the debugger perspective that seems ideal, but a case where you could actually do that seems extremely unlikely (unless you give lr an undefined rule so that the stack slot where the incoming lr was saved is described as being the return address, as in the pop-to-pc example above).
Thanks, Roland