In D54964#1256826, @markj wrote:

In D54964#1256808, @jhb wrote:

I tried using a constraint of "m" and an operand modifier of "a" which I think is more what we want anyway (if you remove the & in the operand), but that gives me ICEs in both GCC 14 and GCC 15. This whole thing seems a bit gross. I realize we want the real symbol here and don't want it to resolve to 'foo@plt' or the like, but this whole thing feels a bit clunky. I guess we can't just do _SDT_ASM_WORD _SDT_PROBE_NAME(...) directly?

Sadly no. This doesn't work for function-scoped static variables, since there the variable name is not equal to that of the emitted symbol. And the DTRACE_PROBE* macros defined in sdt.h (and I think only used by ZFS) need this to work.

(Presumably on CHERI _SDT_WORD here is a .chericap and would really need the symbol name and not some goofy "make the compiler generate a constant address" thing anyway?

It expands to .chericap "%c0" with the operand defined as "i" (__unbounded_addressof(_SDT_PROBE_NAME(...)).

I tried using a constraint of "m" and an operand modifier of "a" which I think is more what we want anyway (if you remove the & in the operand), but that gives me ICEs in both GCC 14 and GCC 15. This whole thing seems a bit gross. I realize we want the real symbol here and don't want it to resolve to 'foo@plt' or the like, but this whole thing feels a bit clunky. I guess we can't just do _SDT_ASM_WORD _SDT_PROBE_NAME(...) directly? (Presumably on CHERI _SDT_WORD here is a .chericap and would really need the symbol name and not some goofy "make the compiler generate a constant address" thing anyway?

Oh dear, GCC added "cc" only in GCC 15. GCC 14 is unable to compile SDT probes with GCC 14 on RISC-V. :(

With this stack, I'm able to build world and the GENERIC kernel for riscv64 using riscv64-gcc15. I will test some other versions of GCC as well.

I don't know why __builtin_ffs for RISC-V on GCC calls ffs rather than __ffssi2 for its libcall. The latter would seem cleaner to me.

I have no idea why clang fails to warn about this as I noted in the commit log. OTOH, if we want to make '%#b' a real thing, we need to document it in the manpage and fix both compilers to intentionally (vs accidentally) accept it.

Need to verify this also builds with clang. Jess believes that clang 17 and later will accept this.

GCC documents operand modifiers here: https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Extended-Asm.html#Generic-Operand-Modifiers

Compare with sys/conf/ldscript.riscv.

Make a no-op so it is MFCable

For MFC purposes, I think I will change this to use BUS_PRIVATE_IVARS + 1 for the buses that currently start at 1 and insert a commit to renumber those. That would let me MFC this change at least.

This looks good to me modulo one style nit I can fix while merging. Is "Marcin Cieslak <saper@saper.info>" the right way to credit you as the author of the commit?

I think changing sysctl_handle_bool directly is fine.

You definitely don't want '-w' by default as it is quite dangerous, but it can be useful on a live system to be able to modify variables in the kernel, and it does mean passing O_RDWR to kvm_open().

Also, you can't do this this way. You have to bump the symbol versions of all symbols that create a FILE object that uses _fileno, and in the old compat version, still limit to 16-bit descriptors because that old software is using the old fileno() macro that reads the file descriptor from the old location. Only in the "new" versions of functions like fopen(), etc. can you actually use the wider fileno field.

I don't think renaming the field does any good here. This isn't the field that existing software accesses directly, and all the software that does is using fileno() which is already part of the API and exposes the ABI.

Oh, this is the sort of thing I really hoped to avoid, was exposing all of FILE as a new ABI. I was careful in my previous versions to figure out which parts of FILE were actually used (not _fileno which doesn't matter, but all the _other_ fields that things like gnulib abuse) and then tried to make FILE mostly opaque, and added the wider _fileno in a slot that was safe to reuse that was near the front still. I think I also used some #ifdef's to ensure that only the fields in FILE that were part of the public ABI were exposed outside of libc. This doesn't do any of that.

This looks good to me btw.

This really shouldn't be needed as drivers like iicsmb and i4giic should create child smbusX devices, and when those devices invoke bus_identify_children that should call the identify routine and voila.

The magic of vn_open_cred() is probably not something that will go away.

Does this mean all TB3 support will be removed? Is there more to cleanup in that case?

Regardless, adding another note to an existing entry in the description seems fine to me.

Hmmm, I tend to use the commit that actually bumped the value as the gitref FWIW. You could try building the website locally (need docproj installed and then you can cd documentation ; make run. After several minutes it will then give you a URL on your localhost you can point a browser at to read the updated docs.