kbuild: exclude .rodata.(cst|str)* when building ranges

Commit Message

Kris Van Hees March 5, 2025, 7:27 p.m. UTC

The .rodata.(cst|str)* sections are often resized during the final
linking and since these sections do not cover actual symbols there is
no need to include them in the modules.builtin.ranges data.

When these sections were included in processing and resizing occurred,
modules were reported with ranges that extended beyond their true end,
causing subsequent symbols (in address order) to be associated with
the wrong module.

Signed-off-by: Kris Van Hees <[e-mail]>
Reviewed-by: Jack Vogel <[e-mail]>
---
 scripts/generate_builtin_ranges.awk | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Steven Rostedt March 7, 2025, 4:14 p.m. UTC | #1

On Wed,  5 Mar 2025 14:27:58 -0500
Kris Van Hees <[e-mail]> wrote:

> The .rodata.(cst|str)* sections are often resized during the final
> linking and since these sections do not cover actual symbols there is
> no need to include them in the modules.builtin.ranges data.
> 
> When these sections were included in processing and resizing occurred,
> modules were reported with ranges that extended beyond their true end,
> causing subsequent symbols (in address order) to be associated with
> the wrong module.

If that's the case, shouldn't this be considered a fix, and include a fixes
tag as well as Cc stable?

-- Steve


> 
> Signed-off-by: Kris Van Hees <[e-mail]>
> Reviewed-by: Jack Vogel <[e-mail]>
> ---

Masahiro Yamada March 11, 2025, 9:17 a.m. UTC | #2

On Thu, Mar 6, 2025 at 4:28 AM Kris Van Hees <[e-mail]> wrote:
>
> The .rodata.(cst|str)* sections are often resized during the final
> linking and since these sections do not cover actual symbols there is
> no need to include them in the modules.builtin.ranges data.
>
> When these sections were included in processing and resizing occurred,
> modules were reported with ranges that extended beyond their true end,
> causing subsequent symbols (in address order) to be associated with
> the wrong module.
>
> Signed-off-by: Kris Van Hees <[e-mail]>
> Reviewed-by: Jack Vogel <[e-mail]>
> ---

Applied with the following tag:

Fixes: 5f5e7344322f ("kbuild: generate offset range data for builtin modules")

Please let me know if this is wrong.

Masahiro Yamada March 11, 2025, 5:27 p.m. UTC | #3

On Tue, Mar 11, 2025 at 6:17 PM Masahiro Yamada <[e-mail]> wrote:
>
> On Thu, Mar 6, 2025 at 4:28 AM Kris Van Hees <[e-mail]> wrote:
> >
> > The .rodata.(cst|str)* sections are often resized during the final
> > linking and since these sections do not cover actual symbols there is
> > no need to include them in the modules.builtin.ranges data.
> >
> > When these sections were included in processing and resizing occurred,
> > modules were reported with ranges that extended beyond their true end,
> > causing subsequent symbols (in address order) to be associated with
> > the wrong module.
> >
> > Signed-off-by: Kris Van Hees <[e-mail]>
> > Reviewed-by: Jack Vogel <[e-mail]>
> > ---
>
> Applied with the following tag:
>
> Fixes: 5f5e7344322f ("kbuild: generate offset range data for builtin modules")
>
> Please let me know if this is wrong.


Ah, v2 was submitted already.
I will take that one.

Patch

diff --git a/scripts/generate_builtin_ranges.awk b/scripts/generate_builtin_ranges.awk
index b9ec761b3bef..d4bd5c2b998c 100755
--- a/scripts/generate_builtin_ranges.awk
+++ b/scripts/generate_builtin_ranges.awk
@@ -282,6 +282,11 @@  ARGIND == 2 && !anchor && NF == 2 && $1 ~ /^0x/ && $2 !~ /^0x/ {
 # section.
 #
 ARGIND == 2 && sect && NF == 4 && /^ [^ \*]/ && !($1 in sect_addend) {
+	# There are a few sections with constant data (without symbols) that
+	# can get resized during linking, so it is best to ignore them.
+	if ($1 ~ /^\.rodata\.(cst|str)[0-9]/)
+		next;
+
 	if (!($1 in sect_base)) {
 		sect_base[$1] = base;