Received-SPF: pass (google.com: domain of linux-kernel+bounces-180587-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240511224035.27775-1-kris.van.hees@oracle.com>
 <CAK7LNATwSDyAWR2FqccF5RFLpw5CYFyndR0N814nC7G7EaL2Tw@mail.gmail.com> <ZkTnwwyTF0WSMmqI@oracle.com>
In-Reply-To: <ZkTnwwyTF0WSMmqI@oracle.com>
From: Masahiro Yamada <masahiroy@kernel.org>
Date: Thu, 16 May 2024 11:56:39 +0900
Message-ID: <CAK7LNARRzGt8EWhRcXnj=2G7E1KOq4E-PGUX53wBoCXAsmSr_g@mail.gmail.com>
Subject: Re: [PATCH v2 0/6] Generate address range data for built-in modules
To: Kris Van Hees <kris.van.hees@oracle.com>
Cc: linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, 
	linux-modules@vger.kernel.org, linux-trace-kernel@vger.kernel.org, 
	Steven Rostedt <rostedt@goodmis.org>, Luis Chamberlain <mcgrof@kernel.org>, 
	Masami Hiramatsu <mhiramat@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, 
	Jiri Olsa <olsajiri@gmail.com>, Elena Zannoni <elena.zannoni@oracle.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 16, 2024 at 1:50=E2=80=AFAM Kris Van Hees <kris.van.hees@oracle=
com> wrote:
>
> On Mon, May 13, 2024 at 01:43:15PM +0900, Masahiro Yamada wrote:
> > On Sun, May 12, 2024 at 7:42???AM Kris Van Hees <kris.van.hees@oracle.c=
om> wrote:
> > >
> > > Especially for tracing applications, it is convenient to be able to
> > > refer to a symbol using a <module name, symbol name> pair and to be a=
ble
> > > to translate an address into a <nodule mname, symbol name> pair.  But
> > > that does not work if the module is built into the kernel because the
> > > object files that comprise the built-in module implementation are sim=
ply
> > > linked into the kernel image along with all other kernel object files=
.
> > >
> > > This is especially visible when providing tracing scripts for support
> > > purposes, where the developer of the script targets a particular kern=
el
> > > version, but does not have control over whether the target system has
> > > a particular module as loadable module or built-in module.  When trac=
ing
> > > symbols within a module, referring them by <module name, symbol name>
> > > pairs is both convenient and aids symbol lookup.  But that naming wil=
l
> > > not work if the module name information is lost if the module is buil=
t
> > > into the kernel on the target system.
> > >
> > > Earlier work addressing this loss of information for built-in modules
> > > involved adding module name information to the kallsyms data, but tha=
t
> > > required more invasive code in the kernel proper.  This work never di=
d
> > > get merged into the kernel tree.
> > >
> > > All that is really needed is knowing whether a given address belongs =
to
> > > a particular module (or multiple modules if they share an object file=
).
> > > Or in other words, whether that address falls within an address range
> > > that is associated with one or more modules.
> > >
> > > This patch series is baaed on Luis Chamberlain's patch to generate
> > > modules.builtin.objs, associating built-in modules with their object
> > > files.  Using this data, vmlinux.o.map and vmlinux.map can be parsed =
in
> > > a single pass to generate a modules.buitin.ranges file with offset ra=
nge
> > > information (relative to the base address of the associated section) =
for
> > > built-in modules.  The file gets installed along with the other
> > > modules.builtin.* files.
> >
> >
> >
> > I still do not want to see modules.builtin.objs.
> >
> >
> > During the vmlinux.o.map parse, every time an object path
> > is encountered, you can open the corresponding .cmd file.
> >
> >
> >
> > Let's say, you have the following in vmlinux.o.map:
> >
> > .text          0x00000000007d4fe0     0x46c8 drivers/i2c/i2c-core-base.=
o
> >
> >
> >
> > You can check drivers/i2c/.i2c-core-base.o.cmd
> >
> >
> > $ cat drivers/i2c/.i2c-core-base.o.cmd | tr ' ' '\n' | grep KBUILD_MODF=
ILE
> > -DKBUILD_MODFILE=3D'"drivers/i2c/i2c-core"'
> >
> >
> > Now you know this object is part of drivers/i2c/i2c-core
> > (that is, its modname is "i2c-core")
> >
> >
> >
> >
> > Next, you will get the following:
> >
> >  .text          0x00000000007dc550     0x13c4 drivers/i2c/i2c-core-acpi=
o
> >
> >
> > $ cat drivers/i2c/.i2c-core-acpi.o.cmd | tr ' ' '\n' | grep KBUILD_MODF=
ILE
> > -DKBUILD_MODFILE=3D'"drivers/i2c/i2c-core"'
> >
> >
> > This one is also a part of drivers/i2c/i2c-core
> >
> >
> > You will get the address range of "i2c-core" without changing Makefiles=
.
>
> Thank you for this suggestion.  I have this approach now implemented, mak=
ing
> use of both KBUILD_MODFILE and KBUILD_MODNAME (both are needed to conclus=
ively
> determine that an object belongs to a module).
>
> However, this is not catching objects that are compiled from assembler so=
urce,
> because modfile_flags and modname_flags are not added to the assembler fl=
ags,
> and thus KBUILD_MODFILE and KBUILD_MODNAME are not present in the .cmd fi=
le
> for those objects.
>
> It would seem that it is harmless to add those flags to assembler flags, =
so
> would that be an acceptable solution?  It definitely would provide consis=
tency
> with non-asm objects.  And we already pass modfile and modname flags to t=
he
> non-asm builds for objects that most certainly do not belong in modules a=
mnyway,
> e.g.
>
> $ cat arch/x86/boot/.cmdline.o.cmd| tr ' ' '\n' | grep -- -DKBUILD_MOD
> -DKBUILD_MODFILE=3D'"arch/x86/boot/cmdline"'
> -DKBUILD_MODNAME=3D'"cmdline"'


I am fine with passing these to *.S files,
as the -D is a preprocessor option.


--
Best Regards
Masahiro Yamada