[Note: At present I can buildworld using WITH_LIB32= on
powerpc64 for TARGET_ARCH=powerpc64 via clang 3.9.0 from a
minor variant of head -r309179 . That does not work for
amd64 cross compiling to powerpc64 due to assembler
notation rejections.]
When I attempt to buildkernel (with WERROR= ) via Fre
Can you try this patch?
Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
===
--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
@@ -2373,6 +2373,12 @@
def MF
On 2016-Dec-5, at 8:19 AM, Roman Divacky wrote:
> Can you try this patch?
>
> Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> ===
> --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
> +++ llvm/lib/Target/PowerPC/PPCIn
[Top post of a retry using a different SRC_CONF_ENV file.]
Well it looks like:
WITHOUT_CROSS_COMPILER=
WITH_SYSTEM_COMPILER=
ignores the .td file change but
WITH_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
may use it.
I had accidentally used a SRC_CONF_ENV file that
was of the first form.
So I'
On 2016-Dec-5, at 5:16 PM, Mark Millard wrote:
> Well it looks like:
>
> WITHOUT_CROSS_COMPILER=
> WITH_SYSTEM_COMPILER=
>
> ignores the .td file change but
>
> WITH_CROSS_COMPILER=
> WITHOUT_SYSTEM_COMPILER=
>
> may use it.
>
> I had accidentally used a SRC_CONF_ENV file that
> was of the f
Can the compiler you built with the patch process this file:
typedef int register_t;
#define mtpmr(reg, val) \
__asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
#define mfpmr(reg) \
On 2016-Dec-7, at 11:00 AM, Roman Divacky wrote:
> Can the compiler you built with the patch process this file:
>
> typedef int register_t;
> #define mtpmr(reg, val) \
>__asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val))
> #define mfpmr(
Top post of a FYI [head -r309656 powerpc64 context]:
I commented out the one -mminimal-toc use in the modules and tried
buildkernel again (cross build).
It reached the end. But it dies immediately if I try to
boot it after installing a copy.
This was based on:
# svnlite diff /usr/src/sys/module
Can you try to investigate why it dies? I am not convinced -mminimal-toc
would result in a boot failure. I think the kernel would fail to link.
On Wed, Dec 07, 2016 at 09:52:47PM -0800, Mark Millard wrote:
> Top post of a FYI [head -r309656 powerpc64 context]:
>
> I commented out the one -mminima
[I have dropped the patch related information and just have
failing-boot related information here.]
On 2016-Dec-8, at 10:55 AM, Roman Divacky wrote:
> Can you try to investigate why it dies? I am not convinced -mminimal-toc
> would result in a boot failure. I think the kernel would fail to link.
I believe the code comes from sys/powerpc/aim/locore64.S and if you compare
the different values from the disssembly with the .S code you can see
it's __tocbase and TOC_REF().
I wonder if the assembly has the -mminimal-toc knowledge hardcoded in somehow.
I am not sure what expectations the locore6
On 2016-Dec-8, at 2:14 PM, Roman Divacky wrote:
> I believe the code comes from sys/powerpc/aim/locore64.S and if you compare
> the different values from the disssembly with the .S code you can see
> it's __tocbase and TOC_REF().
>
> I wonder if the assembly has the -mminimal-toc knowledge hard
[Top post noting a systematic stupid typo of mine.]
I keep typing 2.47 instead of 2.27 for devel/binutils
and devel/powerpc64-binutils .
===
Mark Millard
markmi at dsl-only.net
On 2016-Dec-8, at 3:01 PM, Mark Millard wrote:
On 2016-Dec-8, at 2:14 PM, Roman Divacky wrote:
> I believe the co
A context point that I forgot to mention. . .
I had to use WERROR= in order for buildkernel
to complete under clang 3.9.0 . Otherwise it
stopped based on:
converts between pointers to integer types with different sign
[-Werror,-Wpointer-sign]
===
Mark Millard
markmi at dsl-only.net
On 2016-Dec
Ping Can you take a look Nathan?
Thanks! Roman
On Thu, Dec 08, 2016 at 11:14:52PM +0100, Roman Divacky wrote:
> I believe the code comes from sys/powerpc/aim/locore64.S and if you compare
> the different values from the disssembly with the .S code you can see
> it's __tocbase and TOC_REF().
>
The patch is incorrect, the 'xo' values are off by one bit (inline
change):
On Dec 5, 2016, at 10:19 AM, Roman Divacky wrote:
Can you try this patch?
Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
===
--- llvm/lib/Target/PowerP
Are you sure? My coy of PowerISA lists the numbers that I used? What makes you
think it should be shifted by one bit?
On Mon, Jan 16, 2017 at 08:45:58PM -0600, Justin Hibbits wrote:
> The patch is incorrect, the 'xo' values are off by one bit (inline
> change):
>
>
> On Dec 5, 2016, at 10:19 A
I was incorrect. The Freescale reference actually lists both numbers in the
instruction list (167/231 in A.1 and A.5, 334/462 in A.2). The values you
listed are correct, and match what GCC generates as well.
- Justin
On Jan 17, 2017 13:49, "Roman Divacky" wrote:
> Are you sure? My coy of Power
[Summary: I tracked the boot code problem back to clang 3.9.x using
R_PPC64_ADDR16_DS
with .toc in locore.o (that does not work) but xtoolchain using R_PPC64_TOC16_DS
with .toc in locore.o (that does work).]
On 2016-Dec-12, at 1:09 PM, Roman Divacky wrote:
> Ping Can you take a look Nathan?
That's a great progress. Can you produce minimal self contained test case that
exhibits this bug? And submit it to llvm bugzilla?
Also, clang3.9 defaults to using it's own internal asm, what happens if you
add -no-integrated-as to CFLAGS and recompile the kernel? That should remove
this llvm assem
On 2017-Jan-7, at 12:51 AM, Roman Divacky wrote:
> That's a great progress. Can you produce minimal self contained test case that
> exhibits this bug? And submit it to llvm bugzilla?
>
> Also, clang3.9 defaults to using it's own internal asm, what happens if you
> add -no-integrated-as to CFLAGS
[I've supplied a list of places that adding @toc notation should
make clang 3.9.1 targeting powerpc64 do the right thing for
this issue.]
On 2017-Jan-7, at 2:07 PM, Mark Millard wrote:
> On 2017-Jan-7, at 12:51 AM, Roman Divacky wrote:
>
>> That's a great progress. Can you produce minimal self
[Top post about FreeBSD bugzilla 215819 and llvm bugzilla
31574 submittals for the issue involved.]
My guess is that FreeBSD will view this as a kernel
source code issue and not as a toolchain issue. But
it is only a guess on my part.
I have submitted llvm bugzilla 31574 for this issue. It
inclu
I think we should add the @toc notations to all the places where it's needed.
Can you submit such a patch (perhaps with the one for adding 0 to the cmp
instruction) so they can be committed to FreeBSD repo?
If gnu as warns and llvm assembler does the wrong thing without @toc and both
do the correc
On 2017-Jan-8, at 1:03 AM, Roman Divacky wrote:
> I think we should add the @toc notations to all the places where it's needed.
> Can you submit such a patch (perhaps with the one for adding 0 to the cmp
> instruction) so they can be committed to FreeBSD repo?
In order to test I added @toc to e
[I forgot to indicate that I still can not use the system bootstrapped
ld command and so there is a reason that I used devel/powerpc64-binutils.]
On 2017-Jan-8, at 2:24 AM, Mark Millard wrote:
> On 2017-Jan-8, at 1:03 AM, Roman Divacky wrote:
>
>> I think we should add the @toc notations to al
Mark,
Would you be interested in trying lld? It has some support for ppc/ppc64, which
is probably quite incomplete but it would be nice to know what exactly is
missing.
We also have some people (emaste@, davide@) that have non-trivial lld knowledge
so perhaps progress can be achieved on this side
[I've not tried lldb yet but I have good news. . .]
Well it turns out I was wrong: after the @toc changes (now in the
TOC_REF(...) macro instead of per instruction) I can boot a kernel built
using the bootstrap system binutils and clang as well.
devel/powerpc64-binutils or the like is not required
I'll note that:
Bug 214855 - head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based cross build:
powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 [FreeBSD] 2007-07-03
internal error
means that I can not use the bootstrap binutils to do buildworld for powerpc64.
I've confirmed that it still
I have added the patches to my various historical submittals
and submitted some I'd never made submittals for.
For the sys/modules/zfs/Makefile I eliminated the extra blank line
that was added in what I showed earlier for the patches.
Some of the patches are tied to allowing all 3 types of
buidlw
Hi Mark,
Thanks for all the work you've put into getting FreeBSD/powerpc*
building with clang, it's much appreciated. As time permits I'll be
reviewing and marshalling your patches in.
The fix for PR 215819 just went in (r311912), and will be MFC'd along
with all the other patches after
Hi Justin,
On 2017-Jan-10, at 6:26 PM, Justin Hibbits wrote:
> Hi Mark,
>
> Thanks for all the work you've put into getting FreeBSD/powerpc* building
> with clang, it's much appreciated. As time permits I'll be reviewing and
> marshalling your patches in.
>
> The fix for PR 215819 just went
32 matches
Mail list logo
