[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNAQcUkr8Phtj_cv6vD-QUvjO+7LEsQ5Tx+AuPAB1rbTU9w@mail.gmail.com>
Date: Fri, 25 Aug 2023 08:09:13 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Fangrui Song <maskray@...gle.com>
Cc: Denis Nikitin <denik@...omium.org>, linux-kbuild@...r.kernel.org,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nathan Chancellor <nathan@...nel.org>,
Nicolas Schier <nicolas@...sle.eu>, Tom Rix <trix@...hat.com>,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
Douglas Anderson <dianders@...omium.org>
Subject: Re: [PATCH v2] modpost: Skip .llvm.call-graph-profile section check
On Fri, Aug 25, 2023 at 2:30 AM Fangrui Song <maskray@...gle.com> wrote:
>
> On Wed, Aug 23, 2023 at 4:13 PM Denis Nikitin <denik@...omium.org> wrote:
> >
> > On Wed, Aug 23, 2023 at 4:02 PM Masahiro Yamada <masahiroy@...nel.org> wrote:
> > >
> > > On Wed, Aug 23, 2023 at 3:00 AM Fangrui Song <maskray@...gle.com> wrote:
> > > >
> > > > On Tue, Aug 22, 2023 at 10:49 AM Denis Nikitin <denik@...omium.org> wrote:
> > > > >
> > > > > .llvm.call-graph-profile section is added by clang when the kernel is
> > > > > built with profiles (e.g. -fprofile-sample-use= or -fprofile-use=).
> > > > >
> > > > > The section contains edge information derived from text sections,
> > > > > so .llvm.call-graph-profile itself doesn't need more analysis as
> > > > > the text sections have been analyzed.
> > > > >
> > > > > This change fixes the kernel build with clang and a sample profile
> > > > > which currently fails with:
> > > > >
> > > > > "FATAL: modpost: Please add code to calculate addend for this architecture"
> > >
> > >
> > > Curious.
> > >
> > > This message is only displayed for REL.
> > >
> > > (Please not it is located in section_rel() function)
> > >
> > >
> > > I think modern architectures use RELA instead of REL.
> > > Which architecture are we talking about?
> >
> > Aarch64. There was also a report on x86-64 but the error message could be
> > different there.
>
> Regarding REL:
>
> The original format of .llvm.call-graph-profile
> (SHT_LLVM_CALL_GRAPH_PROFILE=0x6fff4c02) used symbol indices without
> relocations and could be corrupted by symbol table change.
> https://github.com/llvm/llvm-project/commit/a224c5199b327ed0efcdcd87b6dbf950cf4d9ee1
> (2021) changed the format to represent call edge information with
> R_*_NONE and changed SHT_LLVM_CALL_GRAPH_PROFILE to 0x6fff4c09.
>
> We don't use the addend field of R_*_NONE relocations, so I proposed
> that we use REL for all targets.
> My https://github.com/llvm/llvm-project/commit/ca3bdb57fa1ac98b711a735de048c12b5fdd8086
> selected REL for .llvm.call-graph-profile
>
> aaelf64 says:
>
> > A binary file may use ``REL`` or ``RELA`` relocations or a mixture of the two (but multiple relocations of the same place must use only one type).
>
> Other psABI documents may be more vague on how REL is used, but as
> long as the tool that needs to process it (currently just lld and
> readelf like tools) supports it, it's fine.
> binutils seems to support REL for all ELF targets, even if its
> objcopy/strip may unintentionally convert REL to RELA. lld can consume
> RELA SHT_LLVM_CALL_GRAPH_PROFILE.
>
> > >
> > >
> > > What does the output of this command look like?
> > >
> > > $ llvm-readelf -S vmlinux.o | grep .llvm.call-graph-profile
> > >
> > >
> > > Is it REL?
> > >
> >
> > [119] .llvm.call-graph-profile LLVM_CALL_GRAPH_PROFILE 0000000000000000
> > 1c74a458 0104c8 08 E 0 0 1
> > [120] .rel.llvm.call-graph-profile REL 0000000000000000 1c75a920 041320 10
> > I 26090 119 8
> >
> > Thanks,
> > Denis
Thanks, Fangrui.
I'd like the commit log to record the use of REL for
.llvm.call-graph-profile is intentional.
Denis, could you add some more comments?
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists