Some kernel modules build ok using the 'p' constraint with the 'a' operand modifier, but not all.

Works fine for me on arm64. There is one last issue with the usage message, once it's fixed I can land this.

When uploading diffs, please include extra context by adding -U 999999 to the diff command options: https://wiki.freebsd.org/Phabricator#Create_a_Revision_via_Web_Interface

Always print a message

In D55075#1260660, @andrew wrote:

In D55075#1258873, @markj wrote:

Does D55079 fix the problem for you?

I've asked @sarah.walker2_arm.com to test. I have confirmed that eff is the issue. If I move it off the stack I can boot without needing either this patch or changing the sanitizer runtimes.

In D55077#1260024, @tembun_bk.ru wrote:

In D55077#1259991, @markj wrote:

In D55077#1259978, @tembun_bk.ru wrote:

So should /usr/lib/debug/boot directory itself be included in DEBUG_DIRS?

No, I think it shouldn't. So I guess the proper thing would be to exclude \! -d /usr/lib/debug/boot/* \! -d /usr/lib/debug/boot. Maybe there's a cleaner way to write that.

Maybe we can do something like this: find -E <...> \! -regex "${DESTDIR}usr/lib/debug/boot(/.*)?"?

There's a bunch of references to the current name in development.7 and in the doc tree, plus in the git-arc man page, plus the phabricator wiki page. Rather than renaming the package and thus invalidating the documentation and existing tribal knowledge, can we add an alias for the package, and/or identify documentation which refers to git-arc but does not mention the package, and update that? jrm's suggestion also seems ok.

Sorry for the delay. I think this is ok.

In D55120#1259960, @emaste wrote:

It's not necessarily abandoned, this could also be used for patches submitted in non-email contexts, e.g. in a reddit comment.

In D55077#1259978, @tembun_bk.ru wrote:

So should /usr/lib/debug/boot directory itself be included in DEBUG_DIRS?

In D55077#1259930, @kib wrote:

In D55077#1258804, @tembun_bk.ru wrote:

In D55077#1258798, @emaste wrote:

Kernel debug files aren't controlled by WITH_/WITHOUT_DEBUG_FILES so should not be removed here

Oh, I see, these seem to be controlled by WITH[OUT]_SPLIT_KERNEL_DEBUG. But where we should put the code that will mark files in /usr/lib/debug/boot/{kernel,modules} 'obsolete'? I guess it must be somewhere in sys/, but I'm not sure where exactly.

When make installkernel is performed, the symbols become insta-stale, isn't it?

Might be, we need somewhat different model of installation of the debug symbols, which would take into account the name of /boot/kernel directory (like /usr/lib/debug/boot/kernel.GENERIC for /boot/kernel.GENERIC).

In D55066#1259408, @bz wrote:

My historic understanding was that we would have all the pr_* options/check inside kern_jail.c and have accessor functions for them passing td or cred.

In D55066#1259408, @bz wrote:

My historic understanding was that we would have all the pr_* options/check inside kern_jail.c and have accessor functions for them passing td or cred.
I do not know how this evolved over the years (and I do see prison_add_allow()) for other flags so adding #jail to the review list in case @jamie wants to comment on that.

Looks ok aside from the comments.

Have you tested with PCI passthru configured? With just this patch applied, I get an assertion failure in update_bar_address(). Same result if I test your github branch.

In D55033#1258447, @jlduran wrote:

Note that I would have "accepted" the previous version if it wasn't for Eugene's remark. I can try adding a simple test that checks it is warning and not erroring when parsing a configuration file if you believe it is necessary.

Does D55079 fix the problem for you?

Update the KMSAN runtime too.

In D55075#1258850, @andrew wrote:

I'm not sure if it's worth complicating the KASAN runtime for just one function.

In D55075#1258823, @andrew wrote:

The memset call is in __asan_set_shadow_f8, so is only indirectly called.

Isn't this the problem that memset_early() etc. are supposed to solve? Where exactly is the memset() call happening?

In D55049#1258481, @mav wrote:

It seems to make sense to know that we at least tried to orphan the device, even if it may still be open for a while. But I don't remember why it was not done before.

Seems ok to me. You might give a few days for other reviewers to chime in.

Make syslogd more forgiving of configuration errors

In D54964#1257775, @jrtc27 wrote:

IIRC GNU as and LLVM IAS disagree on what .weak and .glob[a]l mean. LLVM IAS doesn't let you mix them, but that's not really sensible, since one is binding and the other is visibility. We use .weak for linker sets but not .glob[a]l (I think used to use both) because one version of LLVM introduced that error, whilst I think GNU as wants what we used to have where we put both. I should probably raise it with upstream LLVM to point out that what they did doesn't make sense.

I retested SDT with gcc14 on amd64. There is a problem (not related to this patch): the linker decides that the start_set_sdt_providers_set and stop_set_sdt_providers_set symbols are unreferenced and removes them. This means that linker_file_lookup_set() returns nothing for those sets, which causes further problems.