Re: [PATCH v11 01/65] dyndbg: fix NULL ptr on i386 due to section alignment

[jim . cromie]

On Fri, Mar 20, 2026 at 10:41 AM Louis Chauvet
<louis.chauvet@xxxxxxxxxxx> wrote:
>
> On Fri, 13 Mar 2026 07:19:26 -0600, Jim Cromie <jim.cromie@xxxxxxxxx> wrote:
> > [...]
> > smaller alignments, *and* scripts/sorttable.c does not tolerate the
> > added ALIGN(8) padding.
> >

More specifically, it counts records in 2 sections, and insists
they're the same count,
and there's no slop/extra space.  the align(8) broke that last constraint.

> > Reported-by: kernel test robot <oliver.sang@xxxxxxxxx>
> > Closes: https://lore.kernel.org/oe-lkp/202601211325.7e1f336-lkp@xxxxxxxxx
> > Signed-off-by: Jim Cromie <jim.cromie@xxxxxxxxx>
>
> comments may be wrong.


in v12, I found a way to use the makefile to conditionally include a "header"
file which invokes DYNAMIC_DEBUG_CLASSMAP_USE().

In doing this, I encountered some lost sections (lacking a KEEP in modules)
which I fixed by reusing the codetag.lds.h model, to make dyndbg.lds.h,
which reuses the (now separated out) BOUNDED_SECTION* macros,
and contains MOD_DYNDBG_SECTIONS(). which scripts/module.lds.S invokes.
So, those comments are now obsolete.


>
> >
> >
> > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> > index eeb070f330bd..a2ba7e3d9994 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -212,11 +212,13 @@
> > [ ... skip 7 lines ... ]
> >
> >  #define BOUNDED_SECTION_POST_LABEL(_sec_, _label_, _BEGIN_, _END_)   \
> > +     . = ALIGN(8);                                                   \
> >       _label_##_BEGIN_ = .;                                           \
> >       KEEP(*(_sec_))                                                  \
> >       _label_##_END_ = .;
>
> This affects a lot of existing BOUNDED_SECTION_BY. I agree that it is
> not a big issue (most of them already have ALIGN(8) or ALIGN(32), but
> some have ALIGN(4) or just not aligned at all). I think this can increase
> the size of the kernel in other places.
>
> What do you think about a new macro or a
> BOUNDED_SECTION_BY_ALIGNED(sec,label,align) with explicit aligement?

Thats not crazy, but Im not sure its justified by the 6 lines that the
_ALIGNED() variant would save.  It does add some modest complexity to
the macros.


>
> > @@ -867,15 +869,21 @@
> > [ ... skip 15 lines ... ]
> >       . = ALIGN(2);                                                   \
> >       .orc_unwind : AT(ADDR(.orc_unwind) - LOAD_OFFSET) {             \
> > -             BOUNDED_SECTION_BY(.orc_unwind, _orc_unwind)            \
> > +             __start_orc_unwind = .;                                 \
> > +             KEEP(*(.orc_unwind))                                    \
> > +             __stop_orc_unwind = .;                                  \
>
> You already noticed an issue here for example, and you had to manually
> expand the macro to "disable" the align. This is error-prone, I think it is
> better to keep BOUNDED_SECTION_BY here.
>

I'll look at it - there is a stack of 3-4 macros that would need adjusting.

> Note: I don't understand well linker scripts and all the implications, my
>
> Note: I don't understand well linker scripts and all the implications, my
>
> --
> Louis Chauvet <louis.chauvet@xxxxxxxxxxx>

thanks Louis,
Jim