Any more input on this one?

kib: style fixup

In D45918#1046830, @kib wrote:

It seems that db_error() is the only caller of kdb_reenter_silent(). And then it might be better to panic in kdb_reenter_silent() instead, I am not sure. [To make kdb_reenter_silent() more strict]

In D45891#1046815, @arichardson wrote:

No sure how much the builtins optimization matters here but if it does the other workaround would be:

void* memcpy_for_plt(void*, const void*, size_t) asm("memcpy")

And then call that.

kib: comment the cflag

kib: just disable all builtins

In D45891#1046235, @kib wrote:

Should we disable all built-ins for the file, for the same reasoning?

Yeah, we should use the value from sx_try_lock, and we'd like to enforce that it's checked too I guess.

imp: sx_xlock too

In D45875#1045918, @imp wrote:

Why didn't sx_lock() complain?

In D45826#1045245, @kib wrote:

In D45826#1044991, @rlibby wrote:

By the way, I thought about also making these strict-aliasing safe with a union. It's straightforward and also gets rid of the casts. However, since we explicitly build with -fno-strict-aliasing, there's not much motivation. But in case you'd prefer that, I can tweak these patches.

Why would a special treat for aliasing needed? There is the "memory" clobber.

By the way, I thought about also making these strict-aliasing safe with a union. It's straightforward and also gets rid of the casts. However, since we explicitly build with -fno-strict-aliasing, there's not much motivation. But in case you'd prefer that, I can tweak these patches.

In D45825#1044906, @imp wrote:

Ok. So non c11 env?

In D45825#1044894, @imp wrote:

Seems fine... what compilers / build env hits this?

diff -u1000 sys/{i386,amd64}/include/pcpu.h for comparison to D45826. Ignore the #if 0 for testing.

Test patch used to examine codegen:

Filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280039

imp: s/vm_offset_t/uintptr_t/

In D45750#1043538, @imp wrote:

why the crazy vm_offset_t instead of uintptr_t??

In D45751#1043496, @tuexen wrote:

Why is an uint64_t not good enough to hold a pointer? Aren't pointers 32-bit or 64-bit on all architectures FreeBSD supports?

In D45707#1042749, @markj wrote:

Given that the next 70 lines are mostly manually setting bits in the mask, I'd err on the side of entirely removing this initialization.