linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Shmidt <dimitrysh@google.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>,
	Russell King <linux@arm.linux.org.uk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"<linux-arm-kernel@lists.infradead.org>" 
	<linux-arm-kernel@lists.infradead.org>,
	Hante Meuleman <hante.meuleman@broadcom.com>
Subject: Re: building and using modules on arm64 hikey board
Date: Wed, 1 Jun 2016 14:42:29 -0700	[thread overview]
Message-ID: <CAH7ZN-yarOT_0gY+Hvdfx-kjd4SBWkxS24SHMTJ2zr_UXSavBg@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu_=SCHwi8nBXGQ6wux4T59BGAU_H-942+QnSL0KO=zp4w@mail.gmail.com>

On Tue, May 31, 2016 at 1:58 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 31 May 2016 at 22:24, Dmitry Shmidt <dimitrysh@google.com> wrote:
>> On Mon, May 30, 2016 at 4:30 AM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.org> wrote:
>>> This is likely caused by the fact that the Android AArch64 toolchain uses -fpic by default. Could you try adding -fno-pic to the CFLAGS?
>>
>> Actually Arend is using 4.4, and we need to pull your fix, Ard:
>>
>> commit 80a2d83376001f6a1993f2e925670ab0e4cdb76d
>> Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Date:   Tue Jan 5 10:18:52 2016 +0100
>>
>>     arm64: module: avoid undefined shift behavior in reloc_data()
>>
>
> OK, that was going to be my next question to Arend, i.e., to check
> whether he has all the recent fixes we did for the module loader.
>
> But I'd also like to understand how we ended up with PREL32
> relocations in the first place, since those are quite unusual in
> object code generated from generic C source code when using the
> non-pic small model, which is normally GCC's default. Are there any
> other code generation defaults for the Android  AArch64 GCC toolchain
> that you are aware of?

I am still trying to get an answer from toolchain supporters, but it
looks like compiler decides by itself what type of branch to use,
and it is using PREL32 in case it knows for sure that branch will succeed.
I suspect is it done to reduce code size.

>>>> On 30 mei 2016, at 12:21, Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
>>>>
>>>> I got myself an arm64 HiKey board from LeMaker and build an Android AOSP
>>>> image for it (see [1]). For development I would like to use
>>>> CONFIG_MODULES. However, when I try to insmod the build module I get:
>>>>
>>>> [  287.903653] module cfg80211: overflow in relocation type 261 val
>>>> ffffffbffc006530
>>>>
>>>> Looking AArch64 ELF documentation [2], section 4.6.5, it has:
>>>> code|name            |operation |overflow check   |
>>>> 261 |R_AARCH64_PREL32|S + A - P |-2^31 <= X < 2^32|
>>>>
>>>> So basically the highest 32 bits should all be one and so ffffffbf is
>>>> invalid. From what I could find searching internet it could be an issue
>>>> with linker options so I build kernel and modules with V=1. Here the
>>>> linker invocation for them:
>>>>
>>>> + aarch64-linux-android-ld -EL -p --no-undefined -X --build-id -o vmlinux \
>>>> -T ./arch/arm64/kernel/vmlinux.lds arch/arm64/kernel/head.o
>>>> init/built-in.o \
>>>> --start-group usr/built-in.o arch/arm64/kernel/built-in.o
>>>> arch/arm64/mm/built-in.o \
>>>> arch/arm64/net/built-in.o arch/arm64/kvm/built-in.o
>>>> arch/arm64/crypto/built-in.o \
>>>> ./drivers/firmware/efi/libstub/lib.a kernel/built-in.o certs/built-in.o
>>>> mm/built-in.o \
>>>> fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o
>>>> block/built-in.o \
>>>> arch/arm64/lib/lib.a lib/lib.a arch/arm64/lib/built-in.o lib/built-in.o
>>>> drivers/built-in.o \
>>>> sound/built-in.o firmware/built-in.o net/built-in.o virt/built-in.o
>>>> --end-group .tmp_kallsyms2.o
>>>>
>>>>  aarch64-linux-android-ld -EL -r  -T ./scripts/module-common.lds
>>>> --build-id \
>>>>  -o net/wireless/cfg80211.ko net/wireless/cfg80211.o
>>>> net/wireless/cfg80211.mod.o
>>>>
>>>> Attached are vmlinux.lds and module-common.lds. I also tried taking
>>>> upstream arch/arm64/kernel/module.lds in hikey-linaro tree. If someone
>>>> can give a hint or educated guess at what to try it would be appreciated.
>>>>
>>>> Regards,
>>>> Arend
>>>>
>>>> [1] https://source.android.com/source/devices.html#building-kernel
>>>> [2]
>>>> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf
>>>> <module-common.lds>
>>>> <vmlinux.lds>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      parent reply	other threads:[~2016-06-01 21:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-30 10:21 building and using modules on arm64 hikey board Arend Van Spriel
2016-05-30 11:30 ` Ard Biesheuvel
2016-05-30 18:54   ` Arend van Spriel
2016-05-31  1:53     ` Jisheng Zhang
2016-05-31 20:24   ` Dmitry Shmidt
2016-05-31 20:58     ` Ard Biesheuvel
2016-06-01  9:01       ` Arend Van Spriel
2016-06-01 14:40         ` Arend van Spriel
2016-06-01 21:42       ` Dmitry Shmidt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH7ZN-yarOT_0gY+Hvdfx-kjd4SBWkxS24SHMTJ2zr_UXSavBg@mail.gmail.com \
    --to=dimitrysh@google.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arend.vanspriel@broadcom.com \
    --cc=hante.meuleman@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).