Re: [PATCH] dlibs: fix access to `major_names data

[Nick Alcock <nick.alcock@oracle.com>]

On 26 Jul 2024, Kris Van Hees outgrape:

> On systems that lack CTF data, all kernel variable have a default type of
> uintptr_t.  That means that an explicit &-operator needs to be applied
> is the kernel variable is e.g. the address of an array because it will not
> be recognized as a ref-type.
>
> Fix this for `major_names access in the io translators.

Ugh. Nasty, and presumably every *other* translator doing a stringof
might have this problem too. (But most are unaffected because they're
doing struct derefs or other things that need the types in scope
anyway.)

> diff --git a/dlibs/aarch64/5.11/io.d b/dlibs/aarch64/5.11/io.d
> index b1958418..c153d5a2 100644
> --- a/dlibs/aarch64/5.11/io.d
> +++ b/dlibs/aarch64/5.11/io.d
> @@ -131,7 +131,7 @@ translator devinfo_t < struct bio *B > {
>  	dev_instance = 0;
>  	dev_name = B->bi_disk == NULL
>  			? "nfs"
> -			: stringof(((struct blk_major_name **)`major_names)[
> +			: stringof(((struct blk_major_name **)&`major_names)[
>  					getmajor(B->bi_disk->part_tbl->part[B->bi_partno]->bd_dev) % 255
>  				   ]->name);
>  	dev_statname = B->bi_disk == NULL ? "nfs" :

I wish this wasn't necessary, and hope that in the future we can reverse
it, but at least it's minimally invasive:

Reviewed-by: Nick Alcock <nick.alcock@oracle.com>