[strict provenance] make panic_unwind conform

[Gankra]

This issue is part of the Strict Provenance Experiment - #95228

The panic_unwind component is full of lots of pointer provenance crimes.

In particular, I noticed that dwarf/eh.rs is just a complete hairball of uniformly mixing pointers and integers:

rust/library/panic_unwind/src/dwarf/eh.rs

Lines 144 to 148 in bb5c437

	unsafe fn read_encoded_pointer(
	reader: &mut DwarfReader,
	context: &EHContext<'_>,
	encoding: u8,
	) -> Result<usize, ()> {

And seh.rs has some sketchy stuff too:

rust/library/panic_unwind/src/seh.rs

Lines 129 to 134 in bb5c437

	macro_rules! ptr {
	(0) => (0);
	($e:expr) => {
	(($e as usize) - (&imp::__ImageBase as *const _ as usize)) as u32
	}
	}

I ran into this fairly early, so these seemed like pretty overwhelmingly hard problems at the time, but with a bit of time to sleep on it I think it might be possible to fix a lot of this by just making everything be pointers by default and then if you "notice" something is actually an offset, only cast it to an integer at that point.

In general it's ok for integers to pretend to be pointers "for fun", and if anything is ever int | ptr the valid union of these types is ptr.

[Gankra]

And if you're wondering: CHERI actually puts proper capabilities in its debuginfo, so yeah, this stuff should "work" under it!

[niluxv]

With #114534 merged, EH unwinding should mostly conform. (There is still a fixme in the code for SjLj unwinding.)

SEH unwinding on 64-bit platforms doesn't seem fixable. Windows expects pointers to be represented as 32-bit offsets from ImageBase, so it is impossible to pass the required provenance.

[carbotaniuman]

Windows expects pointers to be represented as 32-bit offsets from ImageBase, so it is impossible to pass the required provenance

This doesn't seem like a problem? An offset is still an offset, no matter what Microsoft calls it at - the code on Microsoft's will have to add the offsets to ImageBase to get real pointers anyways.

[niluxv]

the code on Microsoft's will have to add the offsets to ImageBase to get real pointers anyways.

Yes, but ImageBase won't have provenance for our statics.

EDIT: To be clear, these pointers are not some landing pad locations or so, but pointers to static muts that are used to pass information from Rust to the Windows error handling machinery.

EDIT2: A solution would be to put #[no_mangle] on these static muts. But then we need names that don't risk a symbol name collision, so I don't think that is better than expose().