No, I really want to point into the stack and walk stack frames, look at the guts of objects, arrays, map memory, forge pointers to new code (because I wrote a JIT compiler), etc. That is brazen UB in C/C++ and compilers will do horrible things to you.
If you really want guaranteed frame/stack layout I don't think there is any other way than writing your own compiler/IR. No optimizing compiler written in the last 50 years will give you such a guarantee.
If you "just" want introspection, that's a little bit more reasonable; in principle something like dwarf unwind info could be extended for that. But, a) that a lot of work for an extremely niche problem and b) there is no guarantee that the in-memory representation of objects is stable at instruction boundaries, I think you would need something like GC write barriers.
With C there is the ABI which is platform specific but can't change without all hell breaking loose. Also after twenty terrible years for profilers frame pointer are returning.
So the ABI allows you to do this sort of stuff reliably as long as the compiler isn't doing inane things with UB.
The ABI doesn't mandate were locals are located on a stack frame thought so I'm not sure how would you inspect those.
If you simply meant that you want rely on an ABI, then that's fine, although relying on those details might be UB for standard conforming code, it is obviously well defined for compilers that conform to the ABI. Just because it is undefined from a standard point of view, doesn't mean is still undefined for a specific compiler + platform.
You will still need to use compilation firewalls and barriers to avoid aliasing or pointer provenance issues of course.