[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNASvQJT5rCGGQT+L+JtRX32_amZz05QCn9cvT4W4+uVJuA@mail.gmail.com>
Date: Tue, 11 Mar 2025 18:17:08 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Kris Van Hees <kris.van.hees@...cle.com>
Cc: linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
linux-modules@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
Nick Alcock <nick.alcock@...cle.com>, Alan Maguire <alan.maguire@...cle.com>,
Steven Rostedt <rostedt@...dmis.org>, Sam James <sam@...too.org>,
Luis Chamberlain <mcgrof@...nel.org>, Masami Hiramatsu <mhiramat@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>, Jiri Olsa <olsajiri@...il.com>,
Elena Zannoni <elena.zannoni@...cle.com>, Daniel Gomez <da.gomez@...sung.com>,
Jack Vogel <jack.vogel@...cle.com>
Subject: Re: [PATCH] kbuild: exclude .rodata.(cst|str)* when building ranges
On Thu, Mar 6, 2025 at 4:28 AM Kris Van Hees <kris.van.hees@...cle.com> 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 <kris.van.hees@...cle.com>
> Reviewed-by: Jack Vogel <jack.vogel@...cle.com>
> ---
Applied with the following tag:
Fixes: 5f5e7344322f ("kbuild: generate offset range data for builtin modules")
Please let me know if this is wrong.
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists