Re: git: cd73914b01a1 - main - kern: physmem: don't truncate addresses in DEBUG output

On Mon, Feb 20, 2023 at 4:00 PM Kyle Evans <kevans@freebsd.org> wrote:
>
> On Mon, Feb 20, 2023 at 3:59 PM Kyle Evans <kevans@freebsd.org> wrote:
> >
> > On Mon, Feb 20, 2023 at 1:41 PM Jessica Clarke <jrtc27@freebsd.org> wrote:
> > >
> > > On 20 Feb 2023, at 18:55, Kyle Evans <kevans@FreeBSD.org> wrote:
> > > >
> > > > The branch main has been updated by kevans:
> > > >
> > > > URL: https://cgit.FreeBSD.org/src/commit/?id=cd73914b01a1f2300e587f802383cc563f2e7103
> > > >
> > > > commit cd73914b01a1f2300e587f802383cc563f2e7103
> > > > Author:     Kyle Evans <kevans@FreeBSD.org>
> > > > AuthorDate: 2023-02-20 18:54:00 +0000
> > > > Commit:     Kyle Evans <kevans@FreeBSD.org>
> > > > CommitDate: 2023-02-20 18:55:04 +0000
> > > >
> > > >    kern: physmem: don't truncate addresses in DEBUG output
> > > >
> > > >    Make it consistent with the above region printing, otherwise it appears
> > > >    to be somewhat confusing.
> > > > ---
> > > > sys/kern/subr_physmem.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/sys/kern/subr_physmem.c b/sys/kern/subr_physmem.c
> > > > index bb6af5a580aa..d371e1e166c5 100644
> > > > --- a/sys/kern/subr_physmem.c
> > > > +++ b/sys/kern/subr_physmem.c
> > > > @@ -149,10 +149,10 @@ physmem_dump_tables(int (*prfunc)(const char *, ...))
> > > > #ifdef DEBUG
> > > >       prfunc("Avail lists:\n");
> > > >       for (i = 0; phys_avail[i] != 0; ++i) {
> > > > -             prfunc("  phys_avail[%d] 0x%08x\n", i, phys_avail[i]);
> > > > +             prfunc("  phys_avail[%d] 0x%08jx\n", i, phys_avail[i]);
> > >
> > > You need to actually cast them though for 32-bit.
> > >
> >
> > Huh, interesting; wasn't there a compiler warning for this? armv7 and
> > riscv both seemed to have built fine (+ DEBUG), am I misremembering
> > that and it's just a potential source of garbage at runtime?
> >
>
> Oh, well, riscv isn't 32-bit anyways. Still stands for armv7, though.

I delayed to avoid continuing to spam the list, but this is fixed in
7b5cb32fca26 (and a __printflike added to detect it, which I had
realized was the source of no-warning pretty quickly after wondering
out loud). Thanks for the report!