Re: 11.0-CURRENT Bug 205904 "unresolvable R_ARM_MOVW_ABS_NC relocation" vs. forced -fPIC use
On Mon, 2016-01-04 at 20:36 -0800, Mark Millard wrote: > I had in Bug 205904 reported that trying "portmaster -DK > textproc/expat2" in a -march=armv7-a -mcpu=cortex-a7 context (on an > rpi2b) gets (for -r293129 and its /usr/bin/ tools): > > > unresolvable R_ARM_MOVW_ABS_NC relocation against symbol > > `malloc@@FBSD_1.0' > > in an attempted link operation. > > I've now added a comment saying in part: > > > Investigating the issue I had the portmaster activity use the > > /usr/local/arm-gnueabi-freebsd/bin/ tools instead (via > > /etc/make.conf changes) and in that context the message is > > different but it was still an error: > > > > > relocation R_ARM_MOVW_ABS_NC against `malloc' can not be used > > > when making a shared object; recompile with -fPIC > > > > > > Trying again with -fPIC does let the portmaster command complete in > > this /usr/local/arm-gnueabi-freebsd/bin/ based tool context. > > > > > > Going back and trying -fPIC in the /usr/bin/ based tools context > > also lets the portmaster command complete. (That context without > > -fPIC did not directly indicate to try -fPIC in its messages.) > > > > > > So maybe part of the issue is having compiler arguments like -fPIC > > show up in commands for contexts like -march=armv7-a -mcpu=cortex > > -a7 without manual intervention in each case. For ports: some parts > > of a more complicated port might need[] such and other parts might > > not. > > I used /etc/make.conf to force -fPIC being present. > > I started this investigation to try some things after Ian Lepore's > -r292964 for the /usr/bin/ binutils. I picked on textproc/expat2 > initially as something fairly simple and limited to C. (clang++ has > problems under SCTLR bit[1]==1 [alignment required] on arm that make > clang++ Bus Error during most C++ compiles). > > === > Mark Millard > markmi at dsl-only.net All of this is a complex way of saying "there is a bug in the expat2 port" (that being that it tries to build a shared library from object files that were compiled without -fpic). Adding -fpic via make.conf is absolutely not a fix or even a marginally viable workaround. -- Ian ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk
On Tue, 2016-01-05 at 11:35 -0700, Warner Losh wrote: > On Tue, Jan 5, 2016 at 11:27 AM, Mark Millard > wrote: > > > llvm.org's Bugzilla reports that clang trunk has been fixed and > > clang 3.8 > > will contain the fixes: > > > > James Molloy changed bug 25958 > > WhatRemoved Added > > Status NEW RESOLVED > > Resolution --- FIXED > > Comment # 8 on bug 25958 from James Molloy > > Hi Mark, > > > > Thanks for your detailed investigation. I can confirm that this is > > fixed on > > trunk and therefore will be fixed for LLVM 3.8. > > > > The fixes were done for SPARC, which requires strict accesses much > > as ARM > > does > > with SCTLR=1. > > > > There was a sequence of commits by James Knight that fixed these, > > but an > > example is http://reviews.llvm.org/rL242554 . > > > > The fixes were in a similar vein to yours, but required changes in > > fewer > > places > > and there were a few more sticky issues to solve too. I'll CC James > > here in > > case he wants to comment on the current state of the clang codebase > > for > > self-hosting in a strict alignment environment. > > > > Cheers, > > > > James > > > > There's a projects/clang-380-import that you might want to try... It's a non-starter for us, because unfortunately they appear to have removed support for the -arm-use-movt=0 command line option, so now we can't build ubldr or kernel modules. -- Ian ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk
On Tue, Jan 5, 2016 at 11:27 AM, Mark Millard wrote: > llvm.org's Bugzilla reports that clang trunk has been fixed and clang 3.8 > will contain the fixes: > > James Molloy changed bug 25958 > WhatRemoved Added > Status NEW RESOLVED > Resolution --- FIXED > Comment # 8 on bug 25958 from James Molloy > Hi Mark, > > Thanks for your detailed investigation. I can confirm that this is fixed on > trunk and therefore will be fixed for LLVM 3.8. > > The fixes were done for SPARC, which requires strict accesses much as ARM > does > with SCTLR=1. > > There was a sequence of commits by James Knight that fixed these, but an > example is http://reviews.llvm.org/rL242554 . > > The fixes were in a similar vein to yours, but required changes in fewer > places > and there were a few more sticky issues to solve too. I'll CC James here in > case he wants to comment on the current state of the clang codebase for > self-hosting in a strict alignment environment. > > Cheers, > > James > There's a projects/clang-380-import that you might want to try... Warner ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk
llvm.org's Bugzilla reports that clang trunk has been fixed and clang 3.8 will contain the fixes: James Molloy changed bug 25958 WhatRemoved Added Status NEW RESOLVED Resolution --- FIXED Comment # 8 on bug 25958 from James Molloy Hi Mark, Thanks for your detailed investigation. I can confirm that this is fixed on trunk and therefore will be fixed for LLVM 3.8. The fixes were done for SPARC, which requires strict accesses much as ARM does with SCTLR=1. There was a sequence of commits by James Knight that fixed these, but an example is http://reviews.llvm.org/rL242554 . The fixes were in a similar vein to yours, but required changes in fewer places and there were a few more sticky issues to solve too. I'll CC James here in case he wants to comment on the current state of the clang codebase for self-hosting in a strict alignment environment. Cheers, James === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
