lkml.org 
[lkml]   [2020]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Re: linux-next: build warning after merge of the bpf-next tree
    On Fri, 10 Jan 2020 14:28:17 PST (-0800), alexandre@ghiti.fr wrote:
    > Hi guys,
    >
    > On 10/27/19 8:02 PM, Stephen Rothwell wrote:
    >> Hi all,
    >>
    >> On Fri, 18 Oct 2019 10:56:57 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
    >>> Hi all,
    >>>
    >>> After merging the bpf-next tree, today's linux-next build (powerpc
    >>> ppc64_defconfig) produced this warning:
    >>>
    >>> WARNING: 2 bad relocations
    >>> c000000001998a48 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_start
    >>> c000000001998a50 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_end
    >>>
    >>> Introduced by commit
    >>>
    >>> 8580ac9404f6 ("bpf: Process in-kernel BTF")
    >> This warning now appears in the net-next tree build.
    >>
    >>
    > I bump that thread up because Zong also noticed that 2 new relocations for
    > those symbols appeared in my riscv relocatable kernel branch following
    > that commit.
    >
    > I also noticed 2 new relocations R_AARCH64_ABS64 appearing in arm64 kernel.
    >
    > Those 2 weak undefined symbols have existed since commit
    > 341dfcf8d78e ("btf: expose BTF info through sysfs") but this is the fact
    > to declare those symbols into btf.c that produced those relocations.
    >
    > I'm not sure what this all means, but this is not something I expected
    > for riscv for
    > a kernel linked with -shared/-fpie. Maybe should we just leave them to
    > zero ?
    >
    > I think that deserves a deeper look if someone understands all this
    > better than I do.

    Can you give me a pointer to your tree and how to build a relocatable kernel?
    Weak undefined symbols have the absolute value 0, but the kernel is linked at
    an address such that 0 can't be reached by normal means. When I added support
    to binutils for this I did it in a way that required almost no code --
    essetially I just stopped dissallowing x0 as a possible base register for PCREL
    relocations, which results in 0 always being accessible. I just wanted to get
    the kernel to build again, so I didn't worry about chasing around all the
    addressing modes. The PIC/PIE support generates different relocations and I
    wouldn't be surprised if I just missed one (or more likely all) of them.

    It's probably a simple fix, though I feel like every time I say that about the
    linker I end up spending a month in there...

    \
     
     \ /
      Last update: 2020-01-11 01:20    [W:3.727 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site