On Wed, Jun 19, 2024 at 04:03:45AM +0900, Masahiro Yamada wrote:
> On Wed, Jun 19, 2024 at 2:18 AM Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Wed, Jun 19, 2024 at 01:50:36AM +0900, Masahiro Yamada wrote:
> > > On Wed, Jun 19, 2024 at 1:44 AM Greg Kroah-Hartman
> > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > > >
> > > > That's cool, can the C code be switched to also use this? That way we
> > > > only have one path/code for all of this?
> > >
> > >
> > > As the description says, it requires CONFIG_DEBUG_INFO.
> > > We can strip the debug info from the final vmlinux, but
> > > I guess the build speed will be even slower than the current genksyms.
> >
> > For people who want genksyms (i.e. distros), don't they normally already
> > enable DEBUG_INFO as well? The problems of genksyms are well known and
> > a pain (I speak from experience), so replacing it with info based on
> > DWARF would be great, I'll gladly trade off the DEBUG_INFO issue for
> > stablilty!
> >
> > thanks,
> >
> > greg k-h
> >
>
>
>
> I do not think gendwarfksyms is a drop-in replacement,
> because it relies on libelf and libdw, which will not
> work with LLVM bitcode when CONFIG_LTO_CLANG=y.
>
> His "Let's postpone this until final linking" stuff will
> come back?
> Then, vmlinux.o is processed to extract the CRC
> of all symbols?
I agree, this won't work with LTO unless we process vmlinux.o.
> In my benchmark, this tool took 3.84 sec just for processing
> a single rust/core.o object.
To be fair, Rust currently exports all globals and core.o has 400
exported symbols as a result. During my brief testing, this tool is
faster than genksyms for normal C code.
> I'd love to see how long it will take to process vmlinux.o
It's obviously going to be quite slow, my defconfig vmlinux.o has
14k exported symbols:
Performance counter stats for './tools/gendwarfksyms/gendwarfksyms vmlinux.o':
371,527.67 msec task-clock:u # 1.000 CPUs utilized
0 context-switches:u # 0.000 /sec
0 cpu-migrations:u # 0.000 /sec
231,554 page-faults:u # 623.248 /sec
<not supported> cycles:u
<not supported> instructions:u
<not supported> branches:u
<not supported> branch-misses:u
371.686151684 seconds time elapsed
370.534637000 seconds user
0.987825000 seconds sys
The tool is currently single-threaded, so if we really want to go this
route, it could probably be made a bit faster.
> And this occurs even when a single source file is changed
> and vmlinux.o is re-linked.
I suppose anyone using LTO already knows it won't be a quick rebuild
though.
Sami
