Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Sat, Dec 29, 2018 at 4:27 AM Stefan Agner wrote: > > On 05.12.2018 20:45, Nathan Chancellor wrote: > > On Wed, Dec 05, 2018 at 07:39:55PM +0100, Ard Biesheuvel wrote: > >> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor > >> wrote: > >> > > >> > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote: > >> > > (+ Arnd) > >> > > > >> > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor > >> > > wrote: > >> > > > > >> > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote: > >> > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor > >> > > > > wrote: > >> > > > > > > >> > > > > > This flag is not supported by lld: > >> > > > > > > >> > > > > > ld.lld: error: unknown argument: --pic-veneer > >> > > > > > > >> > > > > > Signed-off-by: Nathan Chancellor > >> > > > > > >> > > > > Hi Nate, > >> > > > > > >> > > > > Does this mean ld.lld is guaranteed to produce position independent > >> > > > > veneers if you build kernels that are bigger than the typical > >> > > > > range of > >> > > > > a relative branch? Just for the list, 2 patches to lld: https://github.com/ClangBuiltLinux/linux/issues/286#issuecomment-452027802 -- Thanks, ~Nick Desaulniers
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On 05.12.2018 20:45, Nathan Chancellor wrote:
> On Wed, Dec 05, 2018 at 07:39:55PM +0100, Ard Biesheuvel wrote:
>> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor
>> wrote:
>> >
>> > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
>> > > (+ Arnd)
>> > >
>> > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
>> > > wrote:
>> > > >
>> > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
>> > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
>> > > > > wrote:
>> > > > > >
>> > > > > > This flag is not supported by lld:
>> > > > > >
>> > > > > > ld.lld: error: unknown argument: --pic-veneer
>> > > > > >
>> > > > > > Signed-off-by: Nathan Chancellor
>> > > > >
>> > > > > Hi Nate,
>> > > > >
>> > > > > Does this mean ld.lld is guaranteed to produce position independent
>> > > > > veneers if you build kernels that are bigger than the typical range
>> > > > > of
>> > > > > a relative branch?
>> > > > >
>> > > >
>> > > > Hi Ard,
>> > > >
>> > > > Honestly, I'm not quite sure. I saw your commit that introduced this
>> > > > flag and I wasn't quite sure what to make of it for lld. What
>> > > > configuration would I use to verify and what would I check for?
>> > > >
>> > >
>> > > Try building allyesconfig, and check the resulting binary for veneers
>> > > (which have 'veneer' in the symbol name, at least when ld.bfd emits
>> > > them). These veneers should not take the [virtual] address of the
>> > > branch target directly, but take a PC relative offset (as in the
>> > > example in the commit log of that patch you are referring to)
>> > >
>> >
>> > Alright, compiling with allyesconfig is a little rough at the moment
>> > (bug reports I will file in due time) but I was able to do it. Here's
>> > the disassembly specifically for the functions you had in your commit,
>> > my assembly knowledge is pretty much non-existent unfortunately so I am
>> > not sure what to make of it (it doesn't look like there is a virtual
>> > address for pc in that mix?). I am happy to provide any more information
>> > that is needed.
>> >
>> > c03030cc <__enable_mmu>:
>> > c03030cc: e3c2bic r0, r0, #2
>> > c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
>> > c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
>> > c03030d8: e3a05051mov r5, #81 ; 0x51
>> > c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
>> > c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
>> > c03030e4: eafff3c5b c030 <__turn_mmu_on>
>> > c03030e8: e320f000nop {0}
>> > c03030ec: e320f000nop {0}
>> > c03030f0: e320f000nop {0}
>> > c03030f4: e320f000nop {0}
>> > c03030f8: e320f000nop {0}
>> > c03030fc: e320f000nop {0}
>> >
>> > c030 <__turn_mmu_on>:
>> > c030: e1a0nop ; (mov r0, r0)
>> > c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
>> > c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
>> > c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
>> > c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
>> > c0300014: e1a03003mov r3, r3
>> > c0300018: e1a0300dmov r3, sp
>> > c030001c: e1a0f003mov pc, r3
>> >
>>
>> Thanks Nate.
>>
>> So these functions no longer appear to reside far away from each
>> other, so there no veneer has been emitted.
>>
>> What we're looking for are veneers, i.e., snippets inserted by the
>> linker that serve as a trampoline so a branch target that is far away
>> can be reached.
>>
>> If no symbols exist with 'veneer' in their name *, it might make sense
>> to rebuild the kernel as Thumb2, which has a branching range of only 8
>> MB (as opposed to 16 MB for ARM mode)
>>
>> * I have no idea whether lld names its veneers like this, or even at all
>
> Thanks Ard, I understand now, I appreciate that.
>
> I compiled with CONFIG_THUMB2_KERNEL (config attached) and I am still
> not seeing any veneers or thunks as Peter said they would be called for
> lld in the LLVM bug report linked earlier in the thread. Peter did note
> that the branch ranges were 32MB and 16MB for ARM and Thumb2
> respectively, which could be playing into this.
>
> c03028d0 <__enable_mmu>:
> c03028d0: f020 0002 bic.w r0, r0, #2
> c03028d4: f420 6000 bic.w r0, r0, #2048 ; 0x800
> c03028d8: f420 5080 bic.w r0, r0, #4096 ; 0x1000
> c03028dc: f04f 0551 mov.w r5, #81 ; 0x51
> c03028e0: ee03 5f10 mcr 15, 0, r5, cr3, cr0, {0}
> c03028e4: ee02 4f10 mcr 15, 0, r4, cr2, cr0, {0}
> c03028e8: f7fd bb8a b.w c030 <__turn_mmu_on>
> c03028ec: f3af 8000 nop.w
> c03028f0: f3af 8000 nop.w
> c03028f4: f3af 8000 nop.w
> c03028f8:
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 5, 2018 at 2:59 PM Stefan Agner wrote:
>
> On 05.12.2018 19:41, Nick Desaulniers wrote:
> > On Wed, Dec 5, 2018 at 10:40 AM Ard Biesheuvel
> > wrote:
> >>
> >> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor
> >> wrote:
> >> >
> >> > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> >> > > (+ Arnd)
> >> > >
> >> > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
> >> > > wrote:
> >> > > >
> >> > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> >> > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
> >> > > > > wrote:
> >> > > > > >
> >> > > > > > This flag is not supported by lld:
> >> > > > > >
> >> > > > > > ld.lld: error: unknown argument: --pic-veneer
> >> > > > > >
> >> > > > > > Signed-off-by: Nathan Chancellor
> >> > > > >
> >> > > > > Hi Nate,
> >> > > > >
> >> > > > > Does this mean ld.lld is guaranteed to produce position independent
> >> > > > > veneers if you build kernels that are bigger than the typical
> >> > > > > range of
> >> > > > > a relative branch?
> >> > > > >
> >> > > >
> >> > > > Hi Ard,
> >> > > >
> >> > > > Honestly, I'm not quite sure. I saw your commit that introduced this
> >> > > > flag and I wasn't quite sure what to make of it for lld. What
> >> > > > configuration would I use to verify and what would I check for?
> >> > > >
> >> > >
> >> > > Try building allyesconfig, and check the resulting binary for veneers
> >> > > (which have 'veneer' in the symbol name, at least when ld.bfd emits
> >> > > them). These veneers should not take the [virtual] address of the
> >> > > branch target directly, but take a PC relative offset (as in the
> >> > > example in the commit log of that patch you are referring to)
> >> > >
> >> >
> >> > Alright, compiling with allyesconfig is a little rough at the moment
> >> > (bug reports I will file in due time) but I was able to do it. Here's
> >> > the disassembly specifically for the functions you had in your commit,
> >> > my assembly knowledge is pretty much non-existent unfortunately so I am
> >> > not sure what to make of it (it doesn't look like there is a virtual
> >> > address for pc in that mix?). I am happy to provide any more information
> >> > that is needed.
> >> >
> >> > c03030cc <__enable_mmu>:
> >> > c03030cc: e3c2bic r0, r0, #2
> >> > c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
> >> > c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
> >> > c03030d8: e3a05051mov r5, #81 ; 0x51
> >> > c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
> >> > c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
> >> > c03030e4: eafff3c5b c030 <__turn_mmu_on>
> >> > c03030e8: e320f000nop {0}
> >> > c03030ec: e320f000nop {0}
> >> > c03030f0: e320f000nop {0}
> >> > c03030f4: e320f000nop {0}
> >> > c03030f8: e320f000nop {0}
> >> > c03030fc: e320f000nop {0}
> >> >
> >> > c030 <__turn_mmu_on>:
> >> > c030: e1a0nop ; (mov r0, r0)
> >> > c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> >> > c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
> >> > c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
> >> > c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> >> > c0300014: e1a03003mov r3, r3
> >> > c0300018: e1a0300dmov r3, sp
> >> > c030001c: e1a0f003mov pc, r3
> >> >
> >>
> >> Thanks Nate.
> >>
> >> So these functions no longer appear to reside far away from each
> >> other, so there no veneer has been emitted.
> >>
> >> What we're looking for are veneers, i.e., snippets inserted by the
> >> linker that serve as a trampoline so a branch target that is far away
> >> can be reached.
> >>
> >> If no symbols exist with 'veneer' in their name *, it might make sense
> >> to rebuild the kernel as Thumb2, which has a branching range of only 8
> >> MB (as opposed to 16 MB for ARM mode)
> >
> > Heh, Arnd and I were just talking about this yesterday. Is there a
> > config that sets Thumb2 mode for the kernel?
> >
>
> Yes there is CONFIG_THUMB2_KERNEL, and it works also with LLVM/Clang.
Sounds like something we should put under CI?
https://github.com/ClangBuiltLinux/continuous-integration/issues/94
>
> However, it sometimes leads to surprising issues, like I just
> encountered a few days ago:
>
> https://lore.kernel.org/linux-pci/20181126161645.8177-1-ste...@agner.ch/
>
> --
> Stefan
>
> >>
> >> * I have no idea whether lld names its veneers like this, or even at all
--
Thanks,
~Nick Desaulniers
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 5, 2018 at 2:59 PM Stefan Agner wrote:
>
> On 05.12.2018 19:41, Nick Desaulniers wrote:
> > On Wed, Dec 5, 2018 at 10:40 AM Ard Biesheuvel
> > wrote:
> >>
> >> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor
> >> wrote:
> >> >
> >> > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> >> > > (+ Arnd)
> >> > >
> >> > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
> >> > > wrote:
> >> > > >
> >> > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> >> > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
> >> > > > > wrote:
> >> > > > > >
> >> > > > > > This flag is not supported by lld:
> >> > > > > >
> >> > > > > > ld.lld: error: unknown argument: --pic-veneer
> >> > > > > >
> >> > > > > > Signed-off-by: Nathan Chancellor
> >> > > > >
> >> > > > > Hi Nate,
> >> > > > >
> >> > > > > Does this mean ld.lld is guaranteed to produce position independent
> >> > > > > veneers if you build kernels that are bigger than the typical
> >> > > > > range of
> >> > > > > a relative branch?
> >> > > > >
> >> > > >
> >> > > > Hi Ard,
> >> > > >
> >> > > > Honestly, I'm not quite sure. I saw your commit that introduced this
> >> > > > flag and I wasn't quite sure what to make of it for lld. What
> >> > > > configuration would I use to verify and what would I check for?
> >> > > >
> >> > >
> >> > > Try building allyesconfig, and check the resulting binary for veneers
> >> > > (which have 'veneer' in the symbol name, at least when ld.bfd emits
> >> > > them). These veneers should not take the [virtual] address of the
> >> > > branch target directly, but take a PC relative offset (as in the
> >> > > example in the commit log of that patch you are referring to)
> >> > >
> >> >
> >> > Alright, compiling with allyesconfig is a little rough at the moment
> >> > (bug reports I will file in due time) but I was able to do it. Here's
> >> > the disassembly specifically for the functions you had in your commit,
> >> > my assembly knowledge is pretty much non-existent unfortunately so I am
> >> > not sure what to make of it (it doesn't look like there is a virtual
> >> > address for pc in that mix?). I am happy to provide any more information
> >> > that is needed.
> >> >
> >> > c03030cc <__enable_mmu>:
> >> > c03030cc: e3c2bic r0, r0, #2
> >> > c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
> >> > c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
> >> > c03030d8: e3a05051mov r5, #81 ; 0x51
> >> > c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
> >> > c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
> >> > c03030e4: eafff3c5b c030 <__turn_mmu_on>
> >> > c03030e8: e320f000nop {0}
> >> > c03030ec: e320f000nop {0}
> >> > c03030f0: e320f000nop {0}
> >> > c03030f4: e320f000nop {0}
> >> > c03030f8: e320f000nop {0}
> >> > c03030fc: e320f000nop {0}
> >> >
> >> > c030 <__turn_mmu_on>:
> >> > c030: e1a0nop ; (mov r0, r0)
> >> > c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> >> > c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
> >> > c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
> >> > c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> >> > c0300014: e1a03003mov r3, r3
> >> > c0300018: e1a0300dmov r3, sp
> >> > c030001c: e1a0f003mov pc, r3
> >> >
> >>
> >> Thanks Nate.
> >>
> >> So these functions no longer appear to reside far away from each
> >> other, so there no veneer has been emitted.
> >>
> >> What we're looking for are veneers, i.e., snippets inserted by the
> >> linker that serve as a trampoline so a branch target that is far away
> >> can be reached.
> >>
> >> If no symbols exist with 'veneer' in their name *, it might make sense
> >> to rebuild the kernel as Thumb2, which has a branching range of only 8
> >> MB (as opposed to 16 MB for ARM mode)
> >
> > Heh, Arnd and I were just talking about this yesterday. Is there a
> > config that sets Thumb2 mode for the kernel?
> >
>
> Yes there is CONFIG_THUMB2_KERNEL, and it works also with LLVM/Clang.
Sounds like something we should put under CI?
https://github.com/ClangBuiltLinux/continuous-integration/issues/94
>
> However, it sometimes leads to surprising issues, like I just
> encountered a few days ago:
>
> https://lore.kernel.org/linux-pci/20181126161645.8177-1-ste...@agner.ch/
>
> --
> Stefan
>
> >>
> >> * I have no idea whether lld names its veneers like this, or even at all
--
Thanks,
~Nick Desaulniers
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On 05.12.2018 19:41, Nick Desaulniers wrote:
> On Wed, Dec 5, 2018 at 10:40 AM Ard Biesheuvel
> wrote:
>>
>> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor
>> wrote:
>> >
>> > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
>> > > (+ Arnd)
>> > >
>> > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
>> > > wrote:
>> > > >
>> > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
>> > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
>> > > > > wrote:
>> > > > > >
>> > > > > > This flag is not supported by lld:
>> > > > > >
>> > > > > > ld.lld: error: unknown argument: --pic-veneer
>> > > > > >
>> > > > > > Signed-off-by: Nathan Chancellor
>> > > > >
>> > > > > Hi Nate,
>> > > > >
>> > > > > Does this mean ld.lld is guaranteed to produce position independent
>> > > > > veneers if you build kernels that are bigger than the typical range
>> > > > > of
>> > > > > a relative branch?
>> > > > >
>> > > >
>> > > > Hi Ard,
>> > > >
>> > > > Honestly, I'm not quite sure. I saw your commit that introduced this
>> > > > flag and I wasn't quite sure what to make of it for lld. What
>> > > > configuration would I use to verify and what would I check for?
>> > > >
>> > >
>> > > Try building allyesconfig, and check the resulting binary for veneers
>> > > (which have 'veneer' in the symbol name, at least when ld.bfd emits
>> > > them). These veneers should not take the [virtual] address of the
>> > > branch target directly, but take a PC relative offset (as in the
>> > > example in the commit log of that patch you are referring to)
>> > >
>> >
>> > Alright, compiling with allyesconfig is a little rough at the moment
>> > (bug reports I will file in due time) but I was able to do it. Here's
>> > the disassembly specifically for the functions you had in your commit,
>> > my assembly knowledge is pretty much non-existent unfortunately so I am
>> > not sure what to make of it (it doesn't look like there is a virtual
>> > address for pc in that mix?). I am happy to provide any more information
>> > that is needed.
>> >
>> > c03030cc <__enable_mmu>:
>> > c03030cc: e3c2bic r0, r0, #2
>> > c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
>> > c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
>> > c03030d8: e3a05051mov r5, #81 ; 0x51
>> > c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
>> > c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
>> > c03030e4: eafff3c5b c030 <__turn_mmu_on>
>> > c03030e8: e320f000nop {0}
>> > c03030ec: e320f000nop {0}
>> > c03030f0: e320f000nop {0}
>> > c03030f4: e320f000nop {0}
>> > c03030f8: e320f000nop {0}
>> > c03030fc: e320f000nop {0}
>> >
>> > c030 <__turn_mmu_on>:
>> > c030: e1a0nop ; (mov r0, r0)
>> > c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
>> > c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
>> > c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
>> > c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
>> > c0300014: e1a03003mov r3, r3
>> > c0300018: e1a0300dmov r3, sp
>> > c030001c: e1a0f003mov pc, r3
>> >
>>
>> Thanks Nate.
>>
>> So these functions no longer appear to reside far away from each
>> other, so there no veneer has been emitted.
>>
>> What we're looking for are veneers, i.e., snippets inserted by the
>> linker that serve as a trampoline so a branch target that is far away
>> can be reached.
>>
>> If no symbols exist with 'veneer' in their name *, it might make sense
>> to rebuild the kernel as Thumb2, which has a branching range of only 8
>> MB (as opposed to 16 MB for ARM mode)
>
> Heh, Arnd and I were just talking about this yesterday. Is there a
> config that sets Thumb2 mode for the kernel?
>
Yes there is CONFIG_THUMB2_KERNEL, and it works also with LLVM/Clang.
However, it sometimes leads to surprising issues, like I just
encountered a few days ago:
https://lore.kernel.org/linux-pci/20181126161645.8177-1-ste...@agner.ch/
--
Stefan
>>
>> * I have no idea whether lld names its veneers like this, or even at all
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On 05.12.2018 19:41, Nick Desaulniers wrote:
> On Wed, Dec 5, 2018 at 10:40 AM Ard Biesheuvel
> wrote:
>>
>> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor
>> wrote:
>> >
>> > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
>> > > (+ Arnd)
>> > >
>> > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
>> > > wrote:
>> > > >
>> > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
>> > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
>> > > > > wrote:
>> > > > > >
>> > > > > > This flag is not supported by lld:
>> > > > > >
>> > > > > > ld.lld: error: unknown argument: --pic-veneer
>> > > > > >
>> > > > > > Signed-off-by: Nathan Chancellor
>> > > > >
>> > > > > Hi Nate,
>> > > > >
>> > > > > Does this mean ld.lld is guaranteed to produce position independent
>> > > > > veneers if you build kernels that are bigger than the typical range
>> > > > > of
>> > > > > a relative branch?
>> > > > >
>> > > >
>> > > > Hi Ard,
>> > > >
>> > > > Honestly, I'm not quite sure. I saw your commit that introduced this
>> > > > flag and I wasn't quite sure what to make of it for lld. What
>> > > > configuration would I use to verify and what would I check for?
>> > > >
>> > >
>> > > Try building allyesconfig, and check the resulting binary for veneers
>> > > (which have 'veneer' in the symbol name, at least when ld.bfd emits
>> > > them). These veneers should not take the [virtual] address of the
>> > > branch target directly, but take a PC relative offset (as in the
>> > > example in the commit log of that patch you are referring to)
>> > >
>> >
>> > Alright, compiling with allyesconfig is a little rough at the moment
>> > (bug reports I will file in due time) but I was able to do it. Here's
>> > the disassembly specifically for the functions you had in your commit,
>> > my assembly knowledge is pretty much non-existent unfortunately so I am
>> > not sure what to make of it (it doesn't look like there is a virtual
>> > address for pc in that mix?). I am happy to provide any more information
>> > that is needed.
>> >
>> > c03030cc <__enable_mmu>:
>> > c03030cc: e3c2bic r0, r0, #2
>> > c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
>> > c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
>> > c03030d8: e3a05051mov r5, #81 ; 0x51
>> > c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
>> > c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
>> > c03030e4: eafff3c5b c030 <__turn_mmu_on>
>> > c03030e8: e320f000nop {0}
>> > c03030ec: e320f000nop {0}
>> > c03030f0: e320f000nop {0}
>> > c03030f4: e320f000nop {0}
>> > c03030f8: e320f000nop {0}
>> > c03030fc: e320f000nop {0}
>> >
>> > c030 <__turn_mmu_on>:
>> > c030: e1a0nop ; (mov r0, r0)
>> > c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
>> > c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
>> > c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
>> > c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
>> > c0300014: e1a03003mov r3, r3
>> > c0300018: e1a0300dmov r3, sp
>> > c030001c: e1a0f003mov pc, r3
>> >
>>
>> Thanks Nate.
>>
>> So these functions no longer appear to reside far away from each
>> other, so there no veneer has been emitted.
>>
>> What we're looking for are veneers, i.e., snippets inserted by the
>> linker that serve as a trampoline so a branch target that is far away
>> can be reached.
>>
>> If no symbols exist with 'veneer' in their name *, it might make sense
>> to rebuild the kernel as Thumb2, which has a branching range of only 8
>> MB (as opposed to 16 MB for ARM mode)
>
> Heh, Arnd and I were just talking about this yesterday. Is there a
> config that sets Thumb2 mode for the kernel?
>
Yes there is CONFIG_THUMB2_KERNEL, and it works also with LLVM/Clang.
However, it sometimes leads to surprising issues, like I just
encountered a few days ago:
https://lore.kernel.org/linux-pci/20181126161645.8177-1-ste...@agner.ch/
--
Stefan
>>
>> * I have no idea whether lld names its veneers like this, or even at all
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, 5 Dec 2018 at 20:45, Nathan Chancellor wrote:
>
> On Wed, Dec 05, 2018 at 07:39:55PM +0100, Ard Biesheuvel wrote:
> > On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor
> > wrote:
> > >
> > > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> > > > (+ Arnd)
> > > >
> > > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
> > > > wrote:
> > > > >
> > > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> > > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
> > > > > > wrote:
> > > > > > >
> > > > > > > This flag is not supported by lld:
> > > > > > >
> > > > > > > ld.lld: error: unknown argument: --pic-veneer
> > > > > > >
> > > > > > > Signed-off-by: Nathan Chancellor
> > > > > >
> > > > > > Hi Nate,
> > > > > >
> > > > > > Does this mean ld.lld is guaranteed to produce position independent
> > > > > > veneers if you build kernels that are bigger than the typical range
> > > > > > of
> > > > > > a relative branch?
> > > > > >
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > Honestly, I'm not quite sure. I saw your commit that introduced this
> > > > > flag and I wasn't quite sure what to make of it for lld. What
> > > > > configuration would I use to verify and what would I check for?
> > > > >
> > > >
> > > > Try building allyesconfig, and check the resulting binary for veneers
> > > > (which have 'veneer' in the symbol name, at least when ld.bfd emits
> > > > them). These veneers should not take the [virtual] address of the
> > > > branch target directly, but take a PC relative offset (as in the
> > > > example in the commit log of that patch you are referring to)
> > > >
> > >
> > > Alright, compiling with allyesconfig is a little rough at the moment
> > > (bug reports I will file in due time) but I was able to do it. Here's
> > > the disassembly specifically for the functions you had in your commit,
> > > my assembly knowledge is pretty much non-existent unfortunately so I am
> > > not sure what to make of it (it doesn't look like there is a virtual
> > > address for pc in that mix?). I am happy to provide any more information
> > > that is needed.
> > >
> > > c03030cc <__enable_mmu>:
> > > c03030cc: e3c2bic r0, r0, #2
> > > c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
> > > c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
> > > c03030d8: e3a05051mov r5, #81 ; 0x51
> > > c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
> > > c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
> > > c03030e4: eafff3c5b c030 <__turn_mmu_on>
> > > c03030e8: e320f000nop {0}
> > > c03030ec: e320f000nop {0}
> > > c03030f0: e320f000nop {0}
> > > c03030f4: e320f000nop {0}
> > > c03030f8: e320f000nop {0}
> > > c03030fc: e320f000nop {0}
> > >
> > > c030 <__turn_mmu_on>:
> > > c030: e1a0nop ; (mov r0, r0)
> > > c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> > > c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
> > > c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
> > > c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> > > c0300014: e1a03003mov r3, r3
> > > c0300018: e1a0300dmov r3, sp
> > > c030001c: e1a0f003mov pc, r3
> > >
> >
> > Thanks Nate.
> >
> > So these functions no longer appear to reside far away from each
> > other, so there no veneer has been emitted.
> >
> > What we're looking for are veneers, i.e., snippets inserted by the
> > linker that serve as a trampoline so a branch target that is far away
> > can be reached.
> >
> > If no symbols exist with 'veneer' in their name *, it might make sense
> > to rebuild the kernel as Thumb2, which has a branching range of only 8
> > MB (as opposed to 16 MB for ARM mode)
> >
> > * I have no idea whether lld names its veneers like this, or even at all
>
> Thanks Ard, I understand now, I appreciate that.
>
> I compiled with CONFIG_THUMB2_KERNEL (config attached) and I am still
> not seeing any veneers or thunks as Peter said they would be called for
> lld in the LLVM bug report linked earlier in the thread. Peter did note
> that the branch ranges were 32MB and 16MB for ARM and Thumb2
> respectively, which could be playing into this.
>
Ah, indeed. Off by one :-)
However, even when building in ARM rather than Thumb2 mode,
allyesconfig gives me
ard@harold:~/linux-build-arm$ size vmlinux
textdata bss dec hex filename
107708906 50335363 15258568 173302837 a546435 vmlinux
ard@harold:~/linux-build-arm$ grep -cE _veneer$ System.map
16199
so surely, lld is emitting veneers but perhaps it doesn't emit symbols
for them in the same way as ld.bfd does.
Actually, most of those veneers are fine, given that the vast majority
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, 5 Dec 2018 at 20:45, Nathan Chancellor wrote:
>
> On Wed, Dec 05, 2018 at 07:39:55PM +0100, Ard Biesheuvel wrote:
> > On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor
> > wrote:
> > >
> > > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> > > > (+ Arnd)
> > > >
> > > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
> > > > wrote:
> > > > >
> > > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> > > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
> > > > > > wrote:
> > > > > > >
> > > > > > > This flag is not supported by lld:
> > > > > > >
> > > > > > > ld.lld: error: unknown argument: --pic-veneer
> > > > > > >
> > > > > > > Signed-off-by: Nathan Chancellor
> > > > > >
> > > > > > Hi Nate,
> > > > > >
> > > > > > Does this mean ld.lld is guaranteed to produce position independent
> > > > > > veneers if you build kernels that are bigger than the typical range
> > > > > > of
> > > > > > a relative branch?
> > > > > >
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > Honestly, I'm not quite sure. I saw your commit that introduced this
> > > > > flag and I wasn't quite sure what to make of it for lld. What
> > > > > configuration would I use to verify and what would I check for?
> > > > >
> > > >
> > > > Try building allyesconfig, and check the resulting binary for veneers
> > > > (which have 'veneer' in the symbol name, at least when ld.bfd emits
> > > > them). These veneers should not take the [virtual] address of the
> > > > branch target directly, but take a PC relative offset (as in the
> > > > example in the commit log of that patch you are referring to)
> > > >
> > >
> > > Alright, compiling with allyesconfig is a little rough at the moment
> > > (bug reports I will file in due time) but I was able to do it. Here's
> > > the disassembly specifically for the functions you had in your commit,
> > > my assembly knowledge is pretty much non-existent unfortunately so I am
> > > not sure what to make of it (it doesn't look like there is a virtual
> > > address for pc in that mix?). I am happy to provide any more information
> > > that is needed.
> > >
> > > c03030cc <__enable_mmu>:
> > > c03030cc: e3c2bic r0, r0, #2
> > > c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
> > > c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
> > > c03030d8: e3a05051mov r5, #81 ; 0x51
> > > c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
> > > c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
> > > c03030e4: eafff3c5b c030 <__turn_mmu_on>
> > > c03030e8: e320f000nop {0}
> > > c03030ec: e320f000nop {0}
> > > c03030f0: e320f000nop {0}
> > > c03030f4: e320f000nop {0}
> > > c03030f8: e320f000nop {0}
> > > c03030fc: e320f000nop {0}
> > >
> > > c030 <__turn_mmu_on>:
> > > c030: e1a0nop ; (mov r0, r0)
> > > c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> > > c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
> > > c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
> > > c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> > > c0300014: e1a03003mov r3, r3
> > > c0300018: e1a0300dmov r3, sp
> > > c030001c: e1a0f003mov pc, r3
> > >
> >
> > Thanks Nate.
> >
> > So these functions no longer appear to reside far away from each
> > other, so there no veneer has been emitted.
> >
> > What we're looking for are veneers, i.e., snippets inserted by the
> > linker that serve as a trampoline so a branch target that is far away
> > can be reached.
> >
> > If no symbols exist with 'veneer' in their name *, it might make sense
> > to rebuild the kernel as Thumb2, which has a branching range of only 8
> > MB (as opposed to 16 MB for ARM mode)
> >
> > * I have no idea whether lld names its veneers like this, or even at all
>
> Thanks Ard, I understand now, I appreciate that.
>
> I compiled with CONFIG_THUMB2_KERNEL (config attached) and I am still
> not seeing any veneers or thunks as Peter said they would be called for
> lld in the LLVM bug report linked earlier in the thread. Peter did note
> that the branch ranges were 32MB and 16MB for ARM and Thumb2
> respectively, which could be playing into this.
>
Ah, indeed. Off by one :-)
However, even when building in ARM rather than Thumb2 mode,
allyesconfig gives me
ard@harold:~/linux-build-arm$ size vmlinux
textdata bss dec hex filename
107708906 50335363 15258568 173302837 a546435 vmlinux
ard@harold:~/linux-build-arm$ grep -cE _veneer$ System.map
16199
so surely, lld is emitting veneers but perhaps it doesn't emit symbols
for them in the same way as ld.bfd does.
Actually, most of those veneers are fine, given that the vast majority
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, 5 Dec 2018 at 18:22, Nick Desaulniers wrote: > > On Wed, Dec 5, 2018 at 12:10 AM Ard Biesheuvel > wrote: > > > > (+ Arnd) > > > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor > > wrote: > > > > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote: > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor > > > > wrote: > > > > > > > > > > This flag is not supported by lld: > > > > > > > > > > ld.lld: error: unknown argument: --pic-veneer > > > > > > > > > > Signed-off-by: Nathan Chancellor > > > > > > > > Hi Nate, > > > > > > > > Does this mean ld.lld is guaranteed to produce position independent > > > > veneers if you build kernels that are bigger than the typical range of > > > > a relative branch? > > (+ Peter) who might be able to answer this. > LLD will only use position independent veneers when --shared or --pie is used, otherwise it will use veneers with absolute addresses. If the kernel must use position independent veneers even when the rest of the code isn't then we'll have to implement --pic-veneer. Peter > > > > > > > > > > Hi Ard, > > > > > > Honestly, I'm not quite sure. I saw your commit that introduced this > > > flag and I wasn't quite sure what to make of it for lld. What > > > configuration would I use to verify and what would I check for? > > > > > > > Try building allyesconfig, and check the resulting binary for veneers > > (which have 'veneer' in the symbol name, at least when ld.bfd emits > > them). These veneers should not take the [virtual] address of the > > branch target directly, but take a PC relative offset (as in the > > example in the commit log of that patch you are referring to) > > Not sure clang can compile an arm32 allyesconfig (haven't tried > personally, yet, TODO), but we could try gcc+lld. > > > > > > Additionally, I have filed an LLVM bug for the lld developers to > > > check and see if this is a flag they should support: > > > > > > https://bugs.llvm.org/show_bug.cgi?id=39886 > > > > > > Thanks for the quick reply, > > > Nathan > > > > > > > > --- > > > > > arch/arm/Makefile | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > > > > index e2a0baf36766..4fab2aa29570 100644 > > > > > --- a/arch/arm/Makefile > > > > > +++ b/arch/arm/Makefile > > > > > @@ -10,7 +10,7 @@ > > > > > # > > > > > # Copyright (C) 1995-2001 by Russell King > > > > > > > > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer > > > > > +LDFLAGS_vmlinux:= --no-undefined -X $(call > > > > > ld-option,--pic-veneer) > > > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) > > > > > LDFLAGS_vmlinux+= --be8 > > > > > KBUILD_LDFLAGS_MODULE += --be8 > > > > > -- > > > > > 2.20.0.rc1 > > > > > > > > > -- > Thanks, > ~Nick Desaulniers
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, 5 Dec 2018 at 18:22, Nick Desaulniers wrote: > > On Wed, Dec 5, 2018 at 12:10 AM Ard Biesheuvel > wrote: > > > > (+ Arnd) > > > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor > > wrote: > > > > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote: > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor > > > > wrote: > > > > > > > > > > This flag is not supported by lld: > > > > > > > > > > ld.lld: error: unknown argument: --pic-veneer > > > > > > > > > > Signed-off-by: Nathan Chancellor > > > > > > > > Hi Nate, > > > > > > > > Does this mean ld.lld is guaranteed to produce position independent > > > > veneers if you build kernels that are bigger than the typical range of > > > > a relative branch? > > (+ Peter) who might be able to answer this. > LLD will only use position independent veneers when --shared or --pie is used, otherwise it will use veneers with absolute addresses. If the kernel must use position independent veneers even when the rest of the code isn't then we'll have to implement --pic-veneer. Peter > > > > > > > > > > Hi Ard, > > > > > > Honestly, I'm not quite sure. I saw your commit that introduced this > > > flag and I wasn't quite sure what to make of it for lld. What > > > configuration would I use to verify and what would I check for? > > > > > > > Try building allyesconfig, and check the resulting binary for veneers > > (which have 'veneer' in the symbol name, at least when ld.bfd emits > > them). These veneers should not take the [virtual] address of the > > branch target directly, but take a PC relative offset (as in the > > example in the commit log of that patch you are referring to) > > Not sure clang can compile an arm32 allyesconfig (haven't tried > personally, yet, TODO), but we could try gcc+lld. > > > > > > Additionally, I have filed an LLVM bug for the lld developers to > > > check and see if this is a flag they should support: > > > > > > https://bugs.llvm.org/show_bug.cgi?id=39886 > > > > > > Thanks for the quick reply, > > > Nathan > > > > > > > > --- > > > > > arch/arm/Makefile | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > > > > index e2a0baf36766..4fab2aa29570 100644 > > > > > --- a/arch/arm/Makefile > > > > > +++ b/arch/arm/Makefile > > > > > @@ -10,7 +10,7 @@ > > > > > # > > > > > # Copyright (C) 1995-2001 by Russell King > > > > > > > > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer > > > > > +LDFLAGS_vmlinux:= --no-undefined -X $(call > > > > > ld-option,--pic-veneer) > > > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) > > > > > LDFLAGS_vmlinux+= --be8 > > > > > KBUILD_LDFLAGS_MODULE += --be8 > > > > > -- > > > > > 2.20.0.rc1 > > > > > > > > > -- > Thanks, > ~Nick Desaulniers
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 5, 2018 at 10:40 AM Ard Biesheuvel
wrote:
>
> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor
> wrote:
> >
> > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> > > (+ Arnd)
> > >
> > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
> > > wrote:
> > > >
> > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
> > > > > wrote:
> > > > > >
> > > > > > This flag is not supported by lld:
> > > > > >
> > > > > > ld.lld: error: unknown argument: --pic-veneer
> > > > > >
> > > > > > Signed-off-by: Nathan Chancellor
> > > > >
> > > > > Hi Nate,
> > > > >
> > > > > Does this mean ld.lld is guaranteed to produce position independent
> > > > > veneers if you build kernels that are bigger than the typical range of
> > > > > a relative branch?
> > > > >
> > > >
> > > > Hi Ard,
> > > >
> > > > Honestly, I'm not quite sure. I saw your commit that introduced this
> > > > flag and I wasn't quite sure what to make of it for lld. What
> > > > configuration would I use to verify and what would I check for?
> > > >
> > >
> > > Try building allyesconfig, and check the resulting binary for veneers
> > > (which have 'veneer' in the symbol name, at least when ld.bfd emits
> > > them). These veneers should not take the [virtual] address of the
> > > branch target directly, but take a PC relative offset (as in the
> > > example in the commit log of that patch you are referring to)
> > >
> >
> > Alright, compiling with allyesconfig is a little rough at the moment
> > (bug reports I will file in due time) but I was able to do it. Here's
> > the disassembly specifically for the functions you had in your commit,
> > my assembly knowledge is pretty much non-existent unfortunately so I am
> > not sure what to make of it (it doesn't look like there is a virtual
> > address for pc in that mix?). I am happy to provide any more information
> > that is needed.
> >
> > c03030cc <__enable_mmu>:
> > c03030cc: e3c2bic r0, r0, #2
> > c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
> > c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
> > c03030d8: e3a05051mov r5, #81 ; 0x51
> > c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
> > c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
> > c03030e4: eafff3c5b c030 <__turn_mmu_on>
> > c03030e8: e320f000nop {0}
> > c03030ec: e320f000nop {0}
> > c03030f0: e320f000nop {0}
> > c03030f4: e320f000nop {0}
> > c03030f8: e320f000nop {0}
> > c03030fc: e320f000nop {0}
> >
> > c030 <__turn_mmu_on>:
> > c030: e1a0nop ; (mov r0, r0)
> > c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> > c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
> > c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
> > c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> > c0300014: e1a03003mov r3, r3
> > c0300018: e1a0300dmov r3, sp
> > c030001c: e1a0f003mov pc, r3
> >
>
> Thanks Nate.
>
> So these functions no longer appear to reside far away from each
> other, so there no veneer has been emitted.
>
> What we're looking for are veneers, i.e., snippets inserted by the
> linker that serve as a trampoline so a branch target that is far away
> can be reached.
>
> If no symbols exist with 'veneer' in their name *, it might make sense
> to rebuild the kernel as Thumb2, which has a branching range of only 8
> MB (as opposed to 16 MB for ARM mode)
Heh, Arnd and I were just talking about this yesterday. Is there a
config that sets Thumb2 mode for the kernel?
>
> * I have no idea whether lld names its veneers like this, or even at all
--
Thanks,
~Nick Desaulniers
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 5, 2018 at 10:40 AM Ard Biesheuvel
wrote:
>
> On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor
> wrote:
> >
> > On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> > > (+ Arnd)
> > >
> > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
> > > wrote:
> > > >
> > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> > > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
> > > > > wrote:
> > > > > >
> > > > > > This flag is not supported by lld:
> > > > > >
> > > > > > ld.lld: error: unknown argument: --pic-veneer
> > > > > >
> > > > > > Signed-off-by: Nathan Chancellor
> > > > >
> > > > > Hi Nate,
> > > > >
> > > > > Does this mean ld.lld is guaranteed to produce position independent
> > > > > veneers if you build kernels that are bigger than the typical range of
> > > > > a relative branch?
> > > > >
> > > >
> > > > Hi Ard,
> > > >
> > > > Honestly, I'm not quite sure. I saw your commit that introduced this
> > > > flag and I wasn't quite sure what to make of it for lld. What
> > > > configuration would I use to verify and what would I check for?
> > > >
> > >
> > > Try building allyesconfig, and check the resulting binary for veneers
> > > (which have 'veneer' in the symbol name, at least when ld.bfd emits
> > > them). These veneers should not take the [virtual] address of the
> > > branch target directly, but take a PC relative offset (as in the
> > > example in the commit log of that patch you are referring to)
> > >
> >
> > Alright, compiling with allyesconfig is a little rough at the moment
> > (bug reports I will file in due time) but I was able to do it. Here's
> > the disassembly specifically for the functions you had in your commit,
> > my assembly knowledge is pretty much non-existent unfortunately so I am
> > not sure what to make of it (it doesn't look like there is a virtual
> > address for pc in that mix?). I am happy to provide any more information
> > that is needed.
> >
> > c03030cc <__enable_mmu>:
> > c03030cc: e3c2bic r0, r0, #2
> > c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
> > c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
> > c03030d8: e3a05051mov r5, #81 ; 0x51
> > c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
> > c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
> > c03030e4: eafff3c5b c030 <__turn_mmu_on>
> > c03030e8: e320f000nop {0}
> > c03030ec: e320f000nop {0}
> > c03030f0: e320f000nop {0}
> > c03030f4: e320f000nop {0}
> > c03030f8: e320f000nop {0}
> > c03030fc: e320f000nop {0}
> >
> > c030 <__turn_mmu_on>:
> > c030: e1a0nop ; (mov r0, r0)
> > c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> > c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
> > c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
> > c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> > c0300014: e1a03003mov r3, r3
> > c0300018: e1a0300dmov r3, sp
> > c030001c: e1a0f003mov pc, r3
> >
>
> Thanks Nate.
>
> So these functions no longer appear to reside far away from each
> other, so there no veneer has been emitted.
>
> What we're looking for are veneers, i.e., snippets inserted by the
> linker that serve as a trampoline so a branch target that is far away
> can be reached.
>
> If no symbols exist with 'veneer' in their name *, it might make sense
> to rebuild the kernel as Thumb2, which has a branching range of only 8
> MB (as opposed to 16 MB for ARM mode)
Heh, Arnd and I were just talking about this yesterday. Is there a
config that sets Thumb2 mode for the kernel?
>
> * I have no idea whether lld names its veneers like this, or even at all
--
Thanks,
~Nick Desaulniers
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 5, 2018 at 10:36 AM Nathan Chancellor
wrote:
>
> On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> > (+ Arnd)
> >
> > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
> > wrote:
> > >
> > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
> > > > wrote:
> > > > >
> > > > > This flag is not supported by lld:
> > > > >
> > > > > ld.lld: error: unknown argument: --pic-veneer
> > > > >
> > > > > Signed-off-by: Nathan Chancellor
> > > >
> > > > Hi Nate,
> > > >
> > > > Does this mean ld.lld is guaranteed to produce position independent
> > > > veneers if you build kernels that are bigger than the typical range of
> > > > a relative branch?
> > > >
> > >
> > > Hi Ard,
> > >
> > > Honestly, I'm not quite sure. I saw your commit that introduced this
> > > flag and I wasn't quite sure what to make of it for lld. What
> > > configuration would I use to verify and what would I check for?
> > >
> >
> > Try building allyesconfig, and check the resulting binary for veneers
> > (which have 'veneer' in the symbol name, at least when ld.bfd emits
> > them). These veneers should not take the [virtual] address of the
> > branch target directly, but take a PC relative offset (as in the
> > example in the commit log of that patch you are referring to)
> >
>
> Alright, compiling with allyesconfig is a little rough at the moment
> (bug reports I will file in due time) but I was able to do it. Here's
> the disassembly specifically for the functions you had in your commit,
> my assembly knowledge is pretty much non-existent unfortunately so I am
> not sure what to make of it (it doesn't look like there is a virtual
> address for pc in that mix?). I am happy to provide any more information
> that is needed.
Nathan,
Thanks for getting a build working! I think Ard is looking for the
presence of symbols with `veneer` in the name.
Something like `llvm-objdump -t vmlinux | grep veneer` or `llvm-nm
vmlinux | grep veneer` should tell you if such symbols exist.
If they do, Ard was then looking for the disassembly of those labels
(like you provided for __enable_mmu/__turn_mmu_on).
>
> c03030cc <__enable_mmu>:
> c03030cc: e3c2bic r0, r0, #2
> c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
> c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
> c03030d8: e3a05051mov r5, #81 ; 0x51
> c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
> c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
> c03030e4: eafff3c5b c030 <__turn_mmu_on>
> c03030e8: e320f000nop {0}
> c03030ec: e320f000nop {0}
> c03030f0: e320f000nop {0}
> c03030f4: e320f000nop {0}
> c03030f8: e320f000nop {0}
> c03030fc: e320f000nop {0}
>
> c030 <__turn_mmu_on>:
> c030: e1a0nop ; (mov r0, r0)
> c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
> c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
> c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> c0300014: e1a03003mov r3, r3
> c0300018: e1a0300dmov r3, sp
> c030001c: e1a0f003mov pc, r3
>
> Thanks,
> Nathan
>
> > > Additionally, I have filed an LLVM bug for the lld developers to
> > > check and see if this is a flag they should support:
> > >
> > > https://bugs.llvm.org/show_bug.cgi?id=39886
> > >
> > > Thanks for the quick reply,
> > > Nathan
> > >
> > > > > ---
> > > > > arch/arm/Makefile | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > > > > index e2a0baf36766..4fab2aa29570 100644
> > > > > --- a/arch/arm/Makefile
> > > > > +++ b/arch/arm/Makefile
> > > > > @@ -10,7 +10,7 @@
> > > > > #
> > > > > # Copyright (C) 1995-2001 by Russell King
> > > > >
> > > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer
> > > > > +LDFLAGS_vmlinux:= --no-undefined -X $(call
> > > > > ld-option,--pic-veneer)
> > > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
> > > > > LDFLAGS_vmlinux+= --be8
> > > > > KBUILD_LDFLAGS_MODULE += --be8
> > > > > --
> > > > > 2.20.0.rc1
> > > > >
--
Thanks,
~Nick Desaulniers
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 5, 2018 at 10:36 AM Nathan Chancellor
wrote:
>
> On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> > (+ Arnd)
> >
> > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
> > wrote:
> > >
> > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
> > > > wrote:
> > > > >
> > > > > This flag is not supported by lld:
> > > > >
> > > > > ld.lld: error: unknown argument: --pic-veneer
> > > > >
> > > > > Signed-off-by: Nathan Chancellor
> > > >
> > > > Hi Nate,
> > > >
> > > > Does this mean ld.lld is guaranteed to produce position independent
> > > > veneers if you build kernels that are bigger than the typical range of
> > > > a relative branch?
> > > >
> > >
> > > Hi Ard,
> > >
> > > Honestly, I'm not quite sure. I saw your commit that introduced this
> > > flag and I wasn't quite sure what to make of it for lld. What
> > > configuration would I use to verify and what would I check for?
> > >
> >
> > Try building allyesconfig, and check the resulting binary for veneers
> > (which have 'veneer' in the symbol name, at least when ld.bfd emits
> > them). These veneers should not take the [virtual] address of the
> > branch target directly, but take a PC relative offset (as in the
> > example in the commit log of that patch you are referring to)
> >
>
> Alright, compiling with allyesconfig is a little rough at the moment
> (bug reports I will file in due time) but I was able to do it. Here's
> the disassembly specifically for the functions you had in your commit,
> my assembly knowledge is pretty much non-existent unfortunately so I am
> not sure what to make of it (it doesn't look like there is a virtual
> address for pc in that mix?). I am happy to provide any more information
> that is needed.
Nathan,
Thanks for getting a build working! I think Ard is looking for the
presence of symbols with `veneer` in the name.
Something like `llvm-objdump -t vmlinux | grep veneer` or `llvm-nm
vmlinux | grep veneer` should tell you if such symbols exist.
If they do, Ard was then looking for the disassembly of those labels
(like you provided for __enable_mmu/__turn_mmu_on).
>
> c03030cc <__enable_mmu>:
> c03030cc: e3c2bic r0, r0, #2
> c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
> c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
> c03030d8: e3a05051mov r5, #81 ; 0x51
> c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
> c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
> c03030e4: eafff3c5b c030 <__turn_mmu_on>
> c03030e8: e320f000nop {0}
> c03030ec: e320f000nop {0}
> c03030f0: e320f000nop {0}
> c03030f4: e320f000nop {0}
> c03030f8: e320f000nop {0}
> c03030fc: e320f000nop {0}
>
> c030 <__turn_mmu_on>:
> c030: e1a0nop ; (mov r0, r0)
> c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
> c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
> c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> c0300014: e1a03003mov r3, r3
> c0300018: e1a0300dmov r3, sp
> c030001c: e1a0f003mov pc, r3
>
> Thanks,
> Nathan
>
> > > Additionally, I have filed an LLVM bug for the lld developers to
> > > check and see if this is a flag they should support:
> > >
> > > https://bugs.llvm.org/show_bug.cgi?id=39886
> > >
> > > Thanks for the quick reply,
> > > Nathan
> > >
> > > > > ---
> > > > > arch/arm/Makefile | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > > > > index e2a0baf36766..4fab2aa29570 100644
> > > > > --- a/arch/arm/Makefile
> > > > > +++ b/arch/arm/Makefile
> > > > > @@ -10,7 +10,7 @@
> > > > > #
> > > > > # Copyright (C) 1995-2001 by Russell King
> > > > >
> > > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer
> > > > > +LDFLAGS_vmlinux:= --no-undefined -X $(call
> > > > > ld-option,--pic-veneer)
> > > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
> > > > > LDFLAGS_vmlinux+= --be8
> > > > > KBUILD_LDFLAGS_MODULE += --be8
> > > > > --
> > > > > 2.20.0.rc1
> > > > >
--
Thanks,
~Nick Desaulniers
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor wrote:
>
> On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> > (+ Arnd)
> >
> > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
> > wrote:
> > >
> > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
> > > > wrote:
> > > > >
> > > > > This flag is not supported by lld:
> > > > >
> > > > > ld.lld: error: unknown argument: --pic-veneer
> > > > >
> > > > > Signed-off-by: Nathan Chancellor
> > > >
> > > > Hi Nate,
> > > >
> > > > Does this mean ld.lld is guaranteed to produce position independent
> > > > veneers if you build kernels that are bigger than the typical range of
> > > > a relative branch?
> > > >
> > >
> > > Hi Ard,
> > >
> > > Honestly, I'm not quite sure. I saw your commit that introduced this
> > > flag and I wasn't quite sure what to make of it for lld. What
> > > configuration would I use to verify and what would I check for?
> > >
> >
> > Try building allyesconfig, and check the resulting binary for veneers
> > (which have 'veneer' in the symbol name, at least when ld.bfd emits
> > them). These veneers should not take the [virtual] address of the
> > branch target directly, but take a PC relative offset (as in the
> > example in the commit log of that patch you are referring to)
> >
>
> Alright, compiling with allyesconfig is a little rough at the moment
> (bug reports I will file in due time) but I was able to do it. Here's
> the disassembly specifically for the functions you had in your commit,
> my assembly knowledge is pretty much non-existent unfortunately so I am
> not sure what to make of it (it doesn't look like there is a virtual
> address for pc in that mix?). I am happy to provide any more information
> that is needed.
>
> c03030cc <__enable_mmu>:
> c03030cc: e3c2bic r0, r0, #2
> c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
> c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
> c03030d8: e3a05051mov r5, #81 ; 0x51
> c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
> c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
> c03030e4: eafff3c5b c030 <__turn_mmu_on>
> c03030e8: e320f000nop {0}
> c03030ec: e320f000nop {0}
> c03030f0: e320f000nop {0}
> c03030f4: e320f000nop {0}
> c03030f8: e320f000nop {0}
> c03030fc: e320f000nop {0}
>
> c030 <__turn_mmu_on>:
> c030: e1a0nop ; (mov r0, r0)
> c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
> c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
> c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> c0300014: e1a03003mov r3, r3
> c0300018: e1a0300dmov r3, sp
> c030001c: e1a0f003mov pc, r3
>
Thanks Nate.
So these functions no longer appear to reside far away from each
other, so there no veneer has been emitted.
What we're looking for are veneers, i.e., snippets inserted by the
linker that serve as a trampoline so a branch target that is far away
can be reached.
If no symbols exist with 'veneer' in their name *, it might make sense
to rebuild the kernel as Thumb2, which has a branching range of only 8
MB (as opposed to 16 MB for ARM mode)
* I have no idea whether lld names its veneers like this, or even at all
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, 5 Dec 2018 at 19:36, Nathan Chancellor wrote:
>
> On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> > (+ Arnd)
> >
> > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
> > wrote:
> > >
> > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
> > > > wrote:
> > > > >
> > > > > This flag is not supported by lld:
> > > > >
> > > > > ld.lld: error: unknown argument: --pic-veneer
> > > > >
> > > > > Signed-off-by: Nathan Chancellor
> > > >
> > > > Hi Nate,
> > > >
> > > > Does this mean ld.lld is guaranteed to produce position independent
> > > > veneers if you build kernels that are bigger than the typical range of
> > > > a relative branch?
> > > >
> > >
> > > Hi Ard,
> > >
> > > Honestly, I'm not quite sure. I saw your commit that introduced this
> > > flag and I wasn't quite sure what to make of it for lld. What
> > > configuration would I use to verify and what would I check for?
> > >
> >
> > Try building allyesconfig, and check the resulting binary for veneers
> > (which have 'veneer' in the symbol name, at least when ld.bfd emits
> > them). These veneers should not take the [virtual] address of the
> > branch target directly, but take a PC relative offset (as in the
> > example in the commit log of that patch you are referring to)
> >
>
> Alright, compiling with allyesconfig is a little rough at the moment
> (bug reports I will file in due time) but I was able to do it. Here's
> the disassembly specifically for the functions you had in your commit,
> my assembly knowledge is pretty much non-existent unfortunately so I am
> not sure what to make of it (it doesn't look like there is a virtual
> address for pc in that mix?). I am happy to provide any more information
> that is needed.
>
> c03030cc <__enable_mmu>:
> c03030cc: e3c2bic r0, r0, #2
> c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
> c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
> c03030d8: e3a05051mov r5, #81 ; 0x51
> c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
> c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
> c03030e4: eafff3c5b c030 <__turn_mmu_on>
> c03030e8: e320f000nop {0}
> c03030ec: e320f000nop {0}
> c03030f0: e320f000nop {0}
> c03030f4: e320f000nop {0}
> c03030f8: e320f000nop {0}
> c03030fc: e320f000nop {0}
>
> c030 <__turn_mmu_on>:
> c030: e1a0nop ; (mov r0, r0)
> c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
> c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
> c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
> c0300014: e1a03003mov r3, r3
> c0300018: e1a0300dmov r3, sp
> c030001c: e1a0f003mov pc, r3
>
Thanks Nate.
So these functions no longer appear to reside far away from each
other, so there no veneer has been emitted.
What we're looking for are veneers, i.e., snippets inserted by the
linker that serve as a trampoline so a branch target that is far away
can be reached.
If no symbols exist with 'veneer' in their name *, it might make sense
to rebuild the kernel as Thumb2, which has a branching range of only 8
MB (as opposed to 16 MB for ARM mode)
* I have no idea whether lld names its veneers like this, or even at all
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> (+ Arnd)
>
> On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
> wrote:
> >
> > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
> > > wrote:
> > > >
> > > > This flag is not supported by lld:
> > > >
> > > > ld.lld: error: unknown argument: --pic-veneer
> > > >
> > > > Signed-off-by: Nathan Chancellor
> > >
> > > Hi Nate,
> > >
> > > Does this mean ld.lld is guaranteed to produce position independent
> > > veneers if you build kernels that are bigger than the typical range of
> > > a relative branch?
> > >
> >
> > Hi Ard,
> >
> > Honestly, I'm not quite sure. I saw your commit that introduced this
> > flag and I wasn't quite sure what to make of it for lld. What
> > configuration would I use to verify and what would I check for?
> >
>
> Try building allyesconfig, and check the resulting binary for veneers
> (which have 'veneer' in the symbol name, at least when ld.bfd emits
> them). These veneers should not take the [virtual] address of the
> branch target directly, but take a PC relative offset (as in the
> example in the commit log of that patch you are referring to)
>
Alright, compiling with allyesconfig is a little rough at the moment
(bug reports I will file in due time) but I was able to do it. Here's
the disassembly specifically for the functions you had in your commit,
my assembly knowledge is pretty much non-existent unfortunately so I am
not sure what to make of it (it doesn't look like there is a virtual
address for pc in that mix?). I am happy to provide any more information
that is needed.
c03030cc <__enable_mmu>:
c03030cc: e3c2bic r0, r0, #2
c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
c03030d8: e3a05051mov r5, #81 ; 0x51
c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
c03030e4: eafff3c5b c030 <__turn_mmu_on>
c03030e8: e320f000nop {0}
c03030ec: e320f000nop {0}
c03030f0: e320f000nop {0}
c03030f4: e320f000nop {0}
c03030f8: e320f000nop {0}
c03030fc: e320f000nop {0}
c030 <__turn_mmu_on>:
c030: e1a0nop ; (mov r0, r0)
c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
c0300014: e1a03003mov r3, r3
c0300018: e1a0300dmov r3, sp
c030001c: e1a0f003mov pc, r3
Thanks,
Nathan
> > Additionally, I have filed an LLVM bug for the lld developers to
> > check and see if this is a flag they should support:
> >
> > https://bugs.llvm.org/show_bug.cgi?id=39886
> >
> > Thanks for the quick reply,
> > Nathan
> >
> > > > ---
> > > > arch/arm/Makefile | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > > > index e2a0baf36766..4fab2aa29570 100644
> > > > --- a/arch/arm/Makefile
> > > > +++ b/arch/arm/Makefile
> > > > @@ -10,7 +10,7 @@
> > > > #
> > > > # Copyright (C) 1995-2001 by Russell King
> > > >
> > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer
> > > > +LDFLAGS_vmlinux:= --no-undefined -X $(call
> > > > ld-option,--pic-veneer)
> > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
> > > > LDFLAGS_vmlinux+= --be8
> > > > KBUILD_LDFLAGS_MODULE += --be8
> > > > --
> > > > 2.20.0.rc1
> > > >
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 05, 2018 at 09:09:56AM +0100, Ard Biesheuvel wrote:
> (+ Arnd)
>
> On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor
> wrote:
> >
> > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote:
> > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor
> > > wrote:
> > > >
> > > > This flag is not supported by lld:
> > > >
> > > > ld.lld: error: unknown argument: --pic-veneer
> > > >
> > > > Signed-off-by: Nathan Chancellor
> > >
> > > Hi Nate,
> > >
> > > Does this mean ld.lld is guaranteed to produce position independent
> > > veneers if you build kernels that are bigger than the typical range of
> > > a relative branch?
> > >
> >
> > Hi Ard,
> >
> > Honestly, I'm not quite sure. I saw your commit that introduced this
> > flag and I wasn't quite sure what to make of it for lld. What
> > configuration would I use to verify and what would I check for?
> >
>
> Try building allyesconfig, and check the resulting binary for veneers
> (which have 'veneer' in the symbol name, at least when ld.bfd emits
> them). These veneers should not take the [virtual] address of the
> branch target directly, but take a PC relative offset (as in the
> example in the commit log of that patch you are referring to)
>
Alright, compiling with allyesconfig is a little rough at the moment
(bug reports I will file in due time) but I was able to do it. Here's
the disassembly specifically for the functions you had in your commit,
my assembly knowledge is pretty much non-existent unfortunately so I am
not sure what to make of it (it doesn't look like there is a virtual
address for pc in that mix?). I am happy to provide any more information
that is needed.
c03030cc <__enable_mmu>:
c03030cc: e3c2bic r0, r0, #2
c03030d0: e3c00b02bic r0, r0, #2048 ; 0x800
c03030d4: e3c00a01bic r0, r0, #4096 ; 0x1000
c03030d8: e3a05051mov r5, #81 ; 0x51
c03030dc: ee035f10mcr 15, 0, r5, cr3, cr0, {0}
c03030e0: ee024f10mcr 15, 0, r4, cr2, cr0, {0}
c03030e4: eafff3c5b c030 <__turn_mmu_on>
c03030e8: e320f000nop {0}
c03030ec: e320f000nop {0}
c03030f0: e320f000nop {0}
c03030f4: e320f000nop {0}
c03030f8: e320f000nop {0}
c03030fc: e320f000nop {0}
c030 <__turn_mmu_on>:
c030: e1a0nop ; (mov r0, r0)
c034: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
c038: ee010f10mcr 15, 0, r0, cr1, cr0, {0}
c03c: ee103f10mrc 15, 0, r3, cr0, cr0, {0}
c0300010: ee070f95mcr 15, 0, r0, cr7, cr5, {4}
c0300014: e1a03003mov r3, r3
c0300018: e1a0300dmov r3, sp
c030001c: e1a0f003mov pc, r3
Thanks,
Nathan
> > Additionally, I have filed an LLVM bug for the lld developers to
> > check and see if this is a flag they should support:
> >
> > https://bugs.llvm.org/show_bug.cgi?id=39886
> >
> > Thanks for the quick reply,
> > Nathan
> >
> > > > ---
> > > > arch/arm/Makefile | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > > > index e2a0baf36766..4fab2aa29570 100644
> > > > --- a/arch/arm/Makefile
> > > > +++ b/arch/arm/Makefile
> > > > @@ -10,7 +10,7 @@
> > > > #
> > > > # Copyright (C) 1995-2001 by Russell King
> > > >
> > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer
> > > > +LDFLAGS_vmlinux:= --no-undefined -X $(call
> > > > ld-option,--pic-veneer)
> > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
> > > > LDFLAGS_vmlinux+= --be8
> > > > KBUILD_LDFLAGS_MODULE += --be8
> > > > --
> > > > 2.20.0.rc1
> > > >
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 5, 2018 at 12:10 AM Ard Biesheuvel wrote: > > (+ Arnd) > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor > wrote: > > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote: > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor > > > wrote: > > > > > > > > This flag is not supported by lld: > > > > > > > > ld.lld: error: unknown argument: --pic-veneer > > > > > > > > Signed-off-by: Nathan Chancellor > > > > > > Hi Nate, > > > > > > Does this mean ld.lld is guaranteed to produce position independent > > > veneers if you build kernels that are bigger than the typical range of > > > a relative branch? (+ Peter) who might be able to answer this. > > > > > > > Hi Ard, > > > > Honestly, I'm not quite sure. I saw your commit that introduced this > > flag and I wasn't quite sure what to make of it for lld. What > > configuration would I use to verify and what would I check for? > > > > Try building allyesconfig, and check the resulting binary for veneers > (which have 'veneer' in the symbol name, at least when ld.bfd emits > them). These veneers should not take the [virtual] address of the > branch target directly, but take a PC relative offset (as in the > example in the commit log of that patch you are referring to) Not sure clang can compile an arm32 allyesconfig (haven't tried personally, yet, TODO), but we could try gcc+lld. > > > Additionally, I have filed an LLVM bug for the lld developers to > > check and see if this is a flag they should support: > > > > https://bugs.llvm.org/show_bug.cgi?id=39886 > > > > Thanks for the quick reply, > > Nathan > > > > > > --- > > > > arch/arm/Makefile | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > > > index e2a0baf36766..4fab2aa29570 100644 > > > > --- a/arch/arm/Makefile > > > > +++ b/arch/arm/Makefile > > > > @@ -10,7 +10,7 @@ > > > > # > > > > # Copyright (C) 1995-2001 by Russell King > > > > > > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer > > > > +LDFLAGS_vmlinux:= --no-undefined -X $(call > > > > ld-option,--pic-veneer) > > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) > > > > LDFLAGS_vmlinux+= --be8 > > > > KBUILD_LDFLAGS_MODULE += --be8 > > > > -- > > > > 2.20.0.rc1 > > > > -- Thanks, ~Nick Desaulniers
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 5, 2018 at 12:10 AM Ard Biesheuvel wrote: > > (+ Arnd) > > On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor > wrote: > > > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote: > > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor > > > wrote: > > > > > > > > This flag is not supported by lld: > > > > > > > > ld.lld: error: unknown argument: --pic-veneer > > > > > > > > Signed-off-by: Nathan Chancellor > > > > > > Hi Nate, > > > > > > Does this mean ld.lld is guaranteed to produce position independent > > > veneers if you build kernels that are bigger than the typical range of > > > a relative branch? (+ Peter) who might be able to answer this. > > > > > > > Hi Ard, > > > > Honestly, I'm not quite sure. I saw your commit that introduced this > > flag and I wasn't quite sure what to make of it for lld. What > > configuration would I use to verify and what would I check for? > > > > Try building allyesconfig, and check the resulting binary for veneers > (which have 'veneer' in the symbol name, at least when ld.bfd emits > them). These veneers should not take the [virtual] address of the > branch target directly, but take a PC relative offset (as in the > example in the commit log of that patch you are referring to) Not sure clang can compile an arm32 allyesconfig (haven't tried personally, yet, TODO), but we could try gcc+lld. > > > Additionally, I have filed an LLVM bug for the lld developers to > > check and see if this is a flag they should support: > > > > https://bugs.llvm.org/show_bug.cgi?id=39886 > > > > Thanks for the quick reply, > > Nathan > > > > > > --- > > > > arch/arm/Makefile | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > > > index e2a0baf36766..4fab2aa29570 100644 > > > > --- a/arch/arm/Makefile > > > > +++ b/arch/arm/Makefile > > > > @@ -10,7 +10,7 @@ > > > > # > > > > # Copyright (C) 1995-2001 by Russell King > > > > > > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer > > > > +LDFLAGS_vmlinux:= --no-undefined -X $(call > > > > ld-option,--pic-veneer) > > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) > > > > LDFLAGS_vmlinux+= --be8 > > > > KBUILD_LDFLAGS_MODULE += --be8 > > > > -- > > > > 2.20.0.rc1 > > > > -- Thanks, ~Nick Desaulniers
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
(+ Arnd) On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor wrote: > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote: > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor > > wrote: > > > > > > This flag is not supported by lld: > > > > > > ld.lld: error: unknown argument: --pic-veneer > > > > > > Signed-off-by: Nathan Chancellor > > > > Hi Nate, > > > > Does this mean ld.lld is guaranteed to produce position independent > > veneers if you build kernels that are bigger than the typical range of > > a relative branch? > > > > Hi Ard, > > Honestly, I'm not quite sure. I saw your commit that introduced this > flag and I wasn't quite sure what to make of it for lld. What > configuration would I use to verify and what would I check for? > Try building allyesconfig, and check the resulting binary for veneers (which have 'veneer' in the symbol name, at least when ld.bfd emits them). These veneers should not take the [virtual] address of the branch target directly, but take a PC relative offset (as in the example in the commit log of that patch you are referring to) > Additionally, I have filed an LLVM bug for the lld developers to > check and see if this is a flag they should support: > > https://bugs.llvm.org/show_bug.cgi?id=39886 > > Thanks for the quick reply, > Nathan > > > > --- > > > arch/arm/Makefile | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > > index e2a0baf36766..4fab2aa29570 100644 > > > --- a/arch/arm/Makefile > > > +++ b/arch/arm/Makefile > > > @@ -10,7 +10,7 @@ > > > # > > > # Copyright (C) 1995-2001 by Russell King > > > > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer > > > +LDFLAGS_vmlinux:= --no-undefined -X $(call > > > ld-option,--pic-veneer) > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) > > > LDFLAGS_vmlinux+= --be8 > > > KBUILD_LDFLAGS_MODULE += --be8 > > > -- > > > 2.20.0.rc1 > > >
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
(+ Arnd) On Wed, 5 Dec 2018 at 09:06, Nathan Chancellor wrote: > > On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote: > > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor > > wrote: > > > > > > This flag is not supported by lld: > > > > > > ld.lld: error: unknown argument: --pic-veneer > > > > > > Signed-off-by: Nathan Chancellor > > > > Hi Nate, > > > > Does this mean ld.lld is guaranteed to produce position independent > > veneers if you build kernels that are bigger than the typical range of > > a relative branch? > > > > Hi Ard, > > Honestly, I'm not quite sure. I saw your commit that introduced this > flag and I wasn't quite sure what to make of it for lld. What > configuration would I use to verify and what would I check for? > Try building allyesconfig, and check the resulting binary for veneers (which have 'veneer' in the symbol name, at least when ld.bfd emits them). These veneers should not take the [virtual] address of the branch target directly, but take a PC relative offset (as in the example in the commit log of that patch you are referring to) > Additionally, I have filed an LLVM bug for the lld developers to > check and see if this is a flag they should support: > > https://bugs.llvm.org/show_bug.cgi?id=39886 > > Thanks for the quick reply, > Nathan > > > > --- > > > arch/arm/Makefile | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > > index e2a0baf36766..4fab2aa29570 100644 > > > --- a/arch/arm/Makefile > > > +++ b/arch/arm/Makefile > > > @@ -10,7 +10,7 @@ > > > # > > > # Copyright (C) 1995-2001 by Russell King > > > > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer > > > +LDFLAGS_vmlinux:= --no-undefined -X $(call > > > ld-option,--pic-veneer) > > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) > > > LDFLAGS_vmlinux+= --be8 > > > KBUILD_LDFLAGS_MODULE += --be8 > > > -- > > > 2.20.0.rc1 > > >
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote: > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor > wrote: > > > > This flag is not supported by lld: > > > > ld.lld: error: unknown argument: --pic-veneer > > > > Signed-off-by: Nathan Chancellor > > Hi Nate, > > Does this mean ld.lld is guaranteed to produce position independent > veneers if you build kernels that are bigger than the typical range of > a relative branch? > Hi Ard, Honestly, I'm not quite sure. I saw your commit that introduced this flag and I wasn't quite sure what to make of it for lld. What configuration would I use to verify and what would I check for? Additionally, I have filed an LLVM bug for the lld developers to check and see if this is a flag they should support: https://bugs.llvm.org/show_bug.cgi?id=39886 Thanks for the quick reply, Nathan > > --- > > arch/arm/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > index e2a0baf36766..4fab2aa29570 100644 > > --- a/arch/arm/Makefile > > +++ b/arch/arm/Makefile > > @@ -10,7 +10,7 @@ > > # > > # Copyright (C) 1995-2001 by Russell King > > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer > > +LDFLAGS_vmlinux:= --no-undefined -X $(call ld-option,--pic-veneer) > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) > > LDFLAGS_vmlinux+= --be8 > > KBUILD_LDFLAGS_MODULE += --be8 > > -- > > 2.20.0.rc1 > >
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, Dec 05, 2018 at 08:37:05AM +0100, Ard Biesheuvel wrote: > On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor > wrote: > > > > This flag is not supported by lld: > > > > ld.lld: error: unknown argument: --pic-veneer > > > > Signed-off-by: Nathan Chancellor > > Hi Nate, > > Does this mean ld.lld is guaranteed to produce position independent > veneers if you build kernels that are bigger than the typical range of > a relative branch? > Hi Ard, Honestly, I'm not quite sure. I saw your commit that introduced this flag and I wasn't quite sure what to make of it for lld. What configuration would I use to verify and what would I check for? Additionally, I have filed an LLVM bug for the lld developers to check and see if this is a flag they should support: https://bugs.llvm.org/show_bug.cgi?id=39886 Thanks for the quick reply, Nathan > > --- > > arch/arm/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > > index e2a0baf36766..4fab2aa29570 100644 > > --- a/arch/arm/Makefile > > +++ b/arch/arm/Makefile > > @@ -10,7 +10,7 @@ > > # > > # Copyright (C) 1995-2001 by Russell King > > > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer > > +LDFLAGS_vmlinux:= --no-undefined -X $(call ld-option,--pic-veneer) > > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) > > LDFLAGS_vmlinux+= --be8 > > KBUILD_LDFLAGS_MODULE += --be8 > > -- > > 2.20.0.rc1 > >
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor wrote: > > This flag is not supported by lld: > > ld.lld: error: unknown argument: --pic-veneer > > Signed-off-by: Nathan Chancellor Hi Nate, Does this mean ld.lld is guaranteed to produce position independent veneers if you build kernels that are bigger than the typical range of a relative branch? > --- > arch/arm/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index e2a0baf36766..4fab2aa29570 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -10,7 +10,7 @@ > # > # Copyright (C) 1995-2001 by Russell King > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer > +LDFLAGS_vmlinux:= --no-undefined -X $(call ld-option,--pic-veneer) > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) > LDFLAGS_vmlinux+= --be8 > KBUILD_LDFLAGS_MODULE += --be8 > -- > 2.20.0.rc1 >
Re: [PATCH 2/2] ARM: Wrap '--pic-veneer' with ld-option
On Wed, 5 Dec 2018 at 02:42, Nathan Chancellor wrote: > > This flag is not supported by lld: > > ld.lld: error: unknown argument: --pic-veneer > > Signed-off-by: Nathan Chancellor Hi Nate, Does this mean ld.lld is guaranteed to produce position independent veneers if you build kernels that are bigger than the typical range of a relative branch? > --- > arch/arm/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index e2a0baf36766..4fab2aa29570 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -10,7 +10,7 @@ > # > # Copyright (C) 1995-2001 by Russell King > > -LDFLAGS_vmlinux:= --no-undefined -X --pic-veneer > +LDFLAGS_vmlinux:= --no-undefined -X $(call ld-option,--pic-veneer) > ifeq ($(CONFIG_CPU_ENDIAN_BE8),y) > LDFLAGS_vmlinux+= --be8 > KBUILD_LDFLAGS_MODULE += --be8 > -- > 2.20.0.rc1 >
