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

[Louis Chauvet]

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.
> 
> 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.

>
>
> 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?

> @@ -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.

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>