Tracking Issue for `core::arch::return_address`

Feature gate: #![feature(return_address)]

This is a tracking issue for core::arch::return_address

The core::arch::return_address!() macro returns a pointer with an address that corresponds to the caller of the function that invoked the return_address!() macro, or a null pointer if it cannot be determined, for debugging purposes

Public API

// core::arch

// Conceptual Signature: fn return_address() -> *const ();
pub macro return_address();

The core::arch::return_address!() macro returns a pointer with an address that corresponds to the caller of the function that invoked the return_address!() macro, or a null pointer if it cannot be determined. The pointer has no provenance, as if created by core::ptr::without_provenance. It cannot be used to read memory (other than ZSTs)

The value returned by the macro depends highly on the architecture and compiler (including any options set). In particular, it is allowed to be wrong (particularily if inlining is involved), or even contain a nonsense value. The result of this macro must not be relied upon for soundness or correctness, only for debugging purposes.
Formally, this function returns a pointer with a non-deterministic address and no provenance.

This is equivalent to the gcc __builtin_return_address(0) intrinsic (other forms of the intrinsic are not supported). Because the operation can be always performed by the compiler without crashing or causing undefined behaviour, invoking the macro is a safe operation.

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: rust-lang/libs-team#768
• Implementation: #154972
• Implement for gcc and miri
  • Implementation for miri:
  • Implementation for codegen_gcc:
• Final comment period (FCP)^1
• Stabilization PR

Unresolved Questions

• Should this take the form of a macro or an #[inline(always)] function?
• How should we handle "weird" architectures where pointers to code aren't the same size as pointers to data.

Start with the core::arch::return_address!() API and the checked implementation in #154972. Investigate the remaining gcc and miri implementations, while reviewing the unresolved macro-versus-function and unusual-architecture questions. Done means both implementations are addressed and the tracking checklist is updated.