Re: if_igb.ko symbolic link generation is still messed up in that it hard wires the path at installkernel time, messing up copying to other places

[Ian Lepore]

On Sat, 2017-09-09 at 15:31 -0700, Simon J. Gerraty wrote:
> Mark Millard  wrote:
> > 
> > # ls -lTt /media/boot/kernel/if_igb.ko /mnt/boot/kerndb/if_igb.ko
> > lrwxr-xr-x  1 root  wheel  25 Sep  8 22:47:36 2017
> > /mnt/boot/kerndb/if_igb.ko -> /mnt/boot/kernel/if_em.ko
> > lrwxr-xr-x  1 root  wheel  68 Sep  6 20:27:20 2017
> > /media/boot/kernel/if_igb.ko -> /usr/obj/DESTDIRs/clang-cortexA53-
> > installkernel/boot/kernel/if_em.ko
> > 
> > In both of these cases the /mnt and /usr/obj/DESTDIRs/ prefixes
> > would not exist for booting the PINE64 that the USB SSD is for:
> > so file not found if a usage attempt is made.
> Yes, when making symlinks in presence of DESTDIR, the src should have
> $DESTDIR removed - the following should usually be safe:
> 
> ln -s ${src#$DESTDIR} $DESTDIR${target#$DESTDIR}
> 

I think the modern fix for this would be "install -l rs $src $DESTDIR",
that should result in if_igb.ko -> if_em.ko without any dir nodes in
the link.

-- 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: FCP-100: armv7 plan

[Ian Lepore]

On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote:
> Warner Losh  writes:
> 
> > 
> > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich 
> > wrote:
> > 
> > > 
> > > Warner Losh  writes:
> > > 
> > > > 
> > > > Greetings,
> > > > 
> > > > This will serve as 'Last Call' for any objections to the plan
> > > > to create
> > > an
> > > > 
> > > > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100.
> > > [...]
> > > 
> > > Some ports want NEON support but FCP-0100 is vague about FreeBSD-
> > > specific
> > > differences between armv6 and armv7. Clang appears to enable NEON
> > > for all
> > > *-gnueabi* targets but I have no clue about GCC. Apparently,
> > > Android and
> > > Debian don't assume NEON on armv7.
> > > 
> > > related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898
> > > 
> > Yes. We are vague about it on purpose. Just like we're vague about
> > MMX,
> > MMX2, etc on x86 because different processors can/want use
> > different
> > things.
> Do you mean similar to how FreeBSD i386 is vague about not supporting
> real i386, only i486 or later?
> 
> > 
> > The goal, if it doesn't work already, is for NEON to work if used,
> > but not be required, just like all the other optional features of a
> > CPU.
> FreeBSD doesn't support detecting NEON at runtime unlike Linux.

We should fix that.  In fact, we should probably fix it in exactly the
way linux does it (does it today, I think it's their 3rd scheme so
far), using getauxval() and elf AT_HWCAP.

Adding the AT_HWCAP stuff would be relatively easy.  I'm not as sure
what to do about getauxval().  To be maximally linux-compatible (which
would be good for ports) we'd put getauxval() in libc and make it work
just like the linux one.  That's a bit at odds with the support we have
now, which is procstat_getauxv() in libprocstat.  It's not very
compatible with how linux getauxval() works, so using just that might
lead to a lot of patches in ports.

-- Ian

>  Do you
> mean at compile time? If so then the following probably needs to
> change
> 
> $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - |& fgrep -i neon
> #define __ARM_NEON 1
> #define __ARM_NEON_FP 0x4
> #define __ARM_NEON__ 1
> ___

___
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: cpp behavior?

[Ian Lepore]

On Fri, 2017-05-19 at 17:07 -0700, Steve Kargl wrote:
> % which cpp
> /usr/bin/cpp
> troutmask:kargl[408] cpp --version
> FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on
> LLVM 4.0.0)
> Target: x86_64-unknown-freebsd12.0
> Thread model: posix
> InstalledDir: /usr/bin
> troutmask:kargl[409] cpp --help |grep trad
>   -traditional-cppEnable some traditional CPP emulation
> troutmask:kargl[410] cpp -traditional-cpp boxmuller.F90 
> cpp: error: unable to execute command: Executable "gcc" doesn't
> exist!
> 
> OK, so what is the preprocessor for clang?
> 

It looks like the problem is that it sees the .F90 and wants to "do the
right thing" for fortran sources, which is "invoke gcc".  I got a clue
by adding '-###' (quotes required) to see what cpp was trying to do
internally.

You might get the effect you want by either adding something like -x
assembler-with-cpp, or maybe by hiding the filetype from cpp:

 cat boxmuller.F90 | cpp -traditional-cpp

-- 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: =mcpu=cortex-a7 buildlworld (for example) vs. __aeabi_uidiv use in ports from pkg

[Ian Lepore]

On Thu, 2017-01-26 at 02:10 -0800, Mark Millard wrote:
> If I buildworld buildkernel for arm.armv6 with the likes of:
> 
> CFLAGS+= =mcpu=cortex-a7
> CXXFLAGS+= =mcpu=cortex-a7
> CPPFLAGS+= =mcpu=cortex-a7
> 
> (say for targeting a bpim3 or rpi2) then what package
> installs for that context tends to report:
> 
> Undefined symbol "__aeabi_uidiv"
> 
> In other words __aeabi_uidiv is only implemented
> for armv6 buildworld, not if one explicitly targets
> armv7. (armv7 has instruction support but that does
> not make software built to support other processor
> variants that are without instruction support also
> work unless the routine is still provided.)
> 
> Note: I normally build ports from source anyway
> so this is just an FYI in case the lack of
> __aeabi_uidiv was not deliberate.
> 
> ===
> Mark Millard
> markmi at dsl-only.net

I believe problems like this will not go away unless we stop trying to
pretend that armv6 and armv7 are the same thing, and actually start
treating armv7 as its own arch, especially for the purpose of packages
and ports.

I've said/suggested this more than once, and every time it gets shot
down by the people who actually understand what it takes to create a
new arch (if I knew how to do it, I would have, long ago).  As near as
I can tell, the argument against doing it is essentially "because it's
hard".

So I guess... don't expect it to get better any time soon.

-- 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: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]

[Ian Lepore]

On Tue, 2016-06-21 at 15:30 -0700, Mark Millard wrote:
> Ian Lepore ian at freebsd.org  wrote on Tue Jun 21 17:55:28 UTC 2016
> :
> 
> > On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote:
> > > Em 21/06/2016 07:33, Keith White escreveu:
> > > > In an earlier message Ian said that he thought he knew what the
> > > > problem was... 
> > > 
> > > Here the problem occurs  when using wifi. I do not have tested
> > > wired 
> > > because I don't have a cable here.
> > > 
> > > 
> > > []'s
> > > 
> > > -Otacilio
> > 
> > The wifi alignment fault should be fixed as of r302064.  Sorry it
> > took
> > so long.
> > 
> > -- Ian
> > 
> 
> FYI: I've not had any -r301975 problems with WiFi on my rpi2.
> 
> But I cross build for TARGET_ARCH=armv6 with:
> 
> > XCFLAGS+= -march=armv7-a -mcpu=cortex-a7
> > XCXXFLAGS+= -march=armv7-a -mcpu=cortex-a7
> 
> (And similarly for self-hosted.) It may be that the -march and/or 
> -mcpu matter to the code generation and explain my lack of problems.
> 
> The builds also have INVARIANTS and WITNESS off.
> 
> ===
> Mark Millard
> markmi at dsl-only.net

INVARIANTS being on was one of the things required to trigger the
alignment fault.

-- 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: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses]

[Ian Lepore]

On Fri, 2016-05-27 at 09:30 +0200, Matthias Andree wrote:
> Am 27.05.2016 um 06:14 schrieb Cedric Blancher:
> > 
[...]
> 
> 
> 2 - find someone to review the ARM and AARCH related #if preprocessor
> stuff in ./include/lzo/lzodefs.h in the port's WRKSRC after
> unpacking.
> 

I just had a look.  I think the cause of bugzilla 207096 is probably
found on line 2544 of lzodefs.h:

#  elif 1 && defined(__TARGET_ARCH_ARM) && ((__TARGET_ARCH_ARM)+0 >= 7)

A similar check on line 2551 assumes armv6-a and -r profiles also
support unaligned.

Our freebsd clang would normally not define __ARM_FEATURE_UNALIGNED
(checked on line 2528 of lzodefs.h) unless someone had specifically
added the -munaligned-access option; in the PR we see it specifically
has -mno-unaligned-access.  But it also has -march=armv7 (our default
is v6 due to the rpi and the ongoing stupidity that we pretend v6 and
v7 are "the same enough" to not need separate names).

So with __ARM_FEATURE_UNALIGNED not defined and arch = armv7, the check
on line 2544 makes the assumption (incorrect until a few days ago) that
if the arch is v7, we must have support for unaligned access.  I think
that assumption is right for every major OS, but there could be special
embedded environments where it's incorrect.  (In fact, a highly
specialized embedded system is pretty much the ONLY place you'd expect
someone to legitimately disable unaligned accesses, now that freebsd
gets it right).

I think the right thing to do is: if __ARM_ARCH is defined, that means
the current compiler properly supports the ACLE feature symbols[1] and
thus only __ARM_FEATURE_UNALIGNED should be consulted.  If __ARM_ARCH
is not defined, then __ARM_FEATURE_UNALIGNED can't be used, and a
fallback to guessing based on arch might be valid.

[1] 
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf

-- 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: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses]

[Ian Lepore]

On Fri, 2016-05-27 at 04:35 -0700, Mark Millard wrote:
> On 2016-May-27, at 12:30 AM, Matthias Andree 
> wrote:
> 
> > Am 27.05.2016 um 06:14 schrieb Cedric Blancher:
> > > [...]

> The rpi vintage matters:
> 
> Original rpi's (before rpi2): ARM1176JZF-S, 32-bit (not armv6 nor
> armv7-a/cortex-a7)
> 

Original rpi is indeed 1176JZF-S, which IS armv6.  The differences
between it and armv7 are almost entirely in the cache maintenence
routines, and notably not in handling unaligned access the way we now
configure the hardware.  Bottom line:  this is an old slow chip and
you'll be nothing but frustrated using it.

If you're going to get an rpi, get the much faster rpi2, which is a
quad-core system.

These days you may be even better off with something even newer based
on the Allwinner chips (banana pi, cubieboard, a bunch of others),
thanks to the excellent support work done recent (and still happening)
by Jarred and Emmanuel.  But I'm not sure of the price comparisons.

-- 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

[Ian Lepore]

On Sat, 2016-01-09 at 15:03 +0100, Dimitry Andric wrote:
> On 09 Jan 2016, at 04:46, Mark Millard  wrote:
> > 
> > On 2016-Jan-7, at 2:57 PM, Dimitry Andric 
> > wrote:
> ...
> > > FYI, I have added a -mno-movt option for this purpose upstream,
> > > and
> > > imported a newer snapshot into the clang380-import branch.  As of
> > > r293384, it now uses the new option spelling for modules, if your
> > > clang
> > > is 3.8.0 or higher.
> > > 
> > > -Dimitry
> > 
> > I've not been able to get to the point of running clang++ 3.8 on
> > the rpi2 yet: R_ARM_CALL and R_ARM_JUMP24 relocation truncations
> > during the cross build's buildworld interfere.
> 
> Yes, this is caused by too large call distances.  In other words, the
> clang executable is getting to big to link.  Apparently we need to do
> some tricks with -mlongcall to fix this.  As I am no arm expert, I
> welcome any patch submissions. :-)
> 
> -Dimitry
> 

Here's the patch I got from Andy for the clang380 branch, modified with
Warner's suggestion to use MACHINE_CPUARCH instead of MACHINE.  With
this I can get a working arm world that will build a runnable
helloworld.c (and .cc) on a dreamplug.  (I.e., it appears clang 3.8.0
fixes the problem we had with clang 3.7.x where it wouldn't run at all
on armv4/5 systems).  I have not tried compling anything complex yet.

-- Ian
Index: lib/clang/clang.lib.mk
===
--- lib/clang/clang.lib.mk	(revision 293584)
+++ lib/clang/clang.lib.mk	(working copy)
@@ -6,4 +6,8 @@ LLVM_SRCS= ${.CURDIR}/../../../contrib/llvm
 
 INTERNALLIB=
 
+.if ${MACHINE_CPUARCH} == "arm"
+STATIC_CXXFLAGS+=-mlong-calls
+.endif
+
 .include 
Index: lib/csu/arm/Makefile
===
--- lib/csu/arm/Makefile	(revision 293584)
+++ lib/csu/arm/Makefile	(working copy)
@@ -23,7 +23,7 @@ CLEANFILES+=	crt1.s gcrt1.s Scrt1.s
 # directly compiled to .o files.
 
 crt1.s: crt1.c
-	${CC} ${CFLAGS} -S -o ${.TARGET} ${.CURDIR}/crt1.c
+	${CC} ${CFLAGS} -mlong-calls -S -o ${.TARGET} ${.CURDIR}/crt1.c
 	sed ${SED_FIX_NOTE} ${.TARGET}
 
 crt1.o: crt1.s
@@ -30,7 +30,7 @@ crt1.o: crt1.s
 	${CC} ${ACFLAGS} -c -o ${.TARGET} crt1.s
 
 gcrt1.s: crt1.c
-	${CC} ${CFLAGS} -DGCRT -S -o ${.TARGET} ${.CURDIR}/crt1.c
+	${CC} ${CFLAGS} -mlong-calls -DGCRT -S -o ${.TARGET} ${.CURDIR}/crt1.c
 	sed ${SED_FIX_NOTE} ${.TARGET}
 
 gcrt1.o: gcrt1.s
Index: usr.bin/clang/clang/Makefile
===
--- usr.bin/clang/clang/Makefile	(revision 293584)
+++ usr.bin/clang/clang/Makefile	(working copy)
@@ -11,7 +11,11 @@ SRCS=	cc1_main.cpp \
 
 .if ${MK_SHARED_TOOLCHAIN} == "no"
 NO_SHARED?= yes
+
+.if ${MACHINE_CPUARCH} == "arm"
+CFLAGS+=-mlong-calls
 .endif
+.endif
 
 LINKS=	${BINDIR}/clang ${BINDIR}/clang++ \
 	${BINDIR}/clang ${BINDIR}/clang-cpp
___
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

[Ian Lepore]

On Thu, 2016-01-07 at 23:57 +0100, Dimitry Andric wrote:
> On 05 Jan 2016, at 19:53, Ian Lepore <i...@freebsd.org> wrote:
> > 
> > On Tue, 2016-01-05 at 11:35 -0700, Warner Losh wrote:
> ...
> > > 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.
> 
> FYI, I have added a -mno-movt option for this purpose upstream, and
> imported a newer snapshot into the clang380-import branch.  As of
> r293384, it now uses the new option spelling for modules, if your
> clang
> is 3.8.0 or higher.
> 
> -Dimitry
> 

I've updated to that and I'm still getting this error:

cc1_main.o: In function `ForcePassLinking':
[...]/src/usr.bin/clang/clang/../../../contrib/llvm/include/llvm/LinkAllPasses.h:194:
 undefined reference to `llvm::sys::RunningOnValgrind()'
c++: error: linker command failed with exit code 1 (use -v to see invocation)
--- clang.full ---
*** [clang.full] Error code 1

I can apparently make it go away just by commenting out the line it
complains about, so I'm forging ahead with that for now to see if I can
do more testing.

-- 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: 11.0-CURRENT Bug 205904 "unresolvable R_ARM_MOVW_ABS_NC relocation" vs. forced -fPIC use

[Ian Lepore]

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: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error?

[Ian Lepore]

On Fri, 2015-12-25 at 17:21 -0800, Mark Millard wrote:
> In my view "-mno-unaligned-access" is an even bigger hammer than I
> used. I find no clang statement about what its ABI consequences would
> be, unlike for what I did: What mix of more padding for alignment vs.
> more but smaller accesses? But as I remember I've seen "-mno
> -unaligned-access" in use in ports and the like so its consequences
> may be familiar material for some folks.
> 
> Absent any questions about ABI consequences "-mno-unaligned-access"
> does well mark the expected SCTLR bit[1] status, far better than what
> I did. Again: I was covering my ignorance while making any
> significant investigation/debugging as unlikely as I could.

After reading the docs more carefully, I think -mno-unaligned-access
isn't a bigger hammer, it's just a different tool that addresses a
different problem than the one you ran into, and it's one we need.  In
particular, it prevents alignment-required accesses to potentially
unaligned fields in a struct marked as 'packed', which is something we
rely on (it's why we mark some structs as packed).

-- 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: GCC withdraw

[Ian Lepore]

On Fri, 2013-08-30 at 07:39 -0600, Warner Losh wrote:
 I had a long, rambling reply to this that corrected many of the factual 
 errors made in it. But why bother. You have your world view, it doesn't match 
 what people are doing today and this mismatch is going to cause people pain 
 and suffering in the embedded world far beyond what you think. And you've 
 shown an extreme reluctance to accept that your world view isn't quite right, 
 and listen to people. This makes me sad, but I recognize a lost cause when I 
 see it.
 
 Do whatever the fuck you want, but it won't make your arguments right. And it 
 won't keep me from saying I told you so when your optimistic timelines don't 
 come to fruition, or the people processors you dismiss as being too weak to 
 run a full FreeBSD (despite the fact they are doing it today) complain about 
 the needless pain they are going through.
 
 Warner

Actually, I have to put a +1 on this.  I also had a long reply full of
reality-based refutations of various facts from this thread, and I
also just deleted it because clearly the discussion has become
pointless.

-- Ian


___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

Re: GCC withdraw

[Ian Lepore]

On Sat, 2013-08-24 at 23:44 +0100, David Chisnall wrote:
 On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
 
  And i found PR about clang and mplayer: ports/176272
  This PR contains log with build error log.
 
 Please file clang bugs at http://llvm.org/bugs/
 
 David
 

And THIS is a major reason why FreeBSD needs a compiler in base instead
of all tools being ports.  The last thing we need is to start responding
to every problem with this is not my problem, go file a report
upstream.  If we're already doing it for the compiler that's supposed
to be the new supported tool, how much worse will peoples' experience be
when we assert no ownership or responsibility for a toolchain at all?

-- Ian


___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

Re: patch to add AES intrinsics to gcc

[Ian Lepore]

On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote:
 On 23 Aug 2013, at 11:42, Julian Elischer jul...@freebsd.org wrote:
 
  no, I believe we have said that 10 would ship with clang by default. NO 
  mention was made about gcc being absent, and I am uncomfortable with taking 
  that step yet. Having gcc just present, will not hurt you..  even after it 
  is gone we will  need to support those who will be replacing clang with 
  newer versions of gcc in hteir own products.
 
 The plan is not to delete gcc from the tree, it is to disable building gcc by 
 default when clang is the system compiler.  If you are building products then 
 you are perfectly at liberty to set WITH_GCC=yes in your src.conf.
 
 Our gcc is from 2007.  It has no C11, no C++11 support.  It has bugs in its 
 atomic generation so you can't use it sensibly without lots of inline 
 assembly (which it doesn't support for newer architectures) for multithreaded 
 things.
 
 Our libstdc++ is ancient and doesn't work with modern C++ codebases.  Putting 
 them in the base system means that people will use them.  If anyone wants 
 them to remain, then speak now and this will be taken as your volunteering to:
 
 - Maintain our forks of both gcc and libstdc++
 - Handle every single PR that is filed by people using these
 
 If you are willing to do this, then that's great.  If not, then you are 
 asking other people to support ancient codebases that they are not using.
 
 David
 

I don't understand, you start by pointing out that gcc will still be in
the tree and usable, then you go on to point out that it it won't be
supported or maintained unless someone volunteers to do that, and you
seem to be doing your best to discourage anyone from volunteering.
Doesn't that sort of moot the point that the source isn't being deleted?

-- Ian


___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

Re: Fast sigblock (AKA rtld speedup)

[Ian Lepore]

On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote:
 David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800:
  and can not be freed until process is exited, the page is doubly
  mapped into in kernel and userland, accessing the shared data
  in kernel has zero overhead though.
 
 Don't forget that there are arches out there w/ VIVT caches which will
 probably eliminate most of the performance benifits if we have the same
 page mapped writable in two different virtual addresses..
 

Even worse than eliminate the benefits, since multiple mappings with one
writable disables caching on the whole page, there can be a big penalty
depending on what other data is nearby that suddenly becomes
uncacheable.  I was initially very interested in the work to read system
clocks without a syscall until I realized it was going to suffer from
the same problem.

-- Ian


___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

Re: Fast sigblock (AKA rtld speedup)

[Ian Lepore]

On Sun, 2013-01-13 at 17:06 +0200, Konstantin Belousov wrote:
 On Sun, Jan 13, 2013 at 07:50:14AM -0700, Ian Lepore wrote:
  On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote:
   David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800:
and can not be freed until process is exited, the page is doubly
mapped into in kernel and userland, accessing the shared data
in kernel has zero overhead though.
   
   Don't forget that there are arches out there w/ VIVT caches which will
   probably eliminate most of the performance benifits if we have the same
   page mapped writable in two different virtual addresses..
   
  
  Even worse than eliminate the benefits, since multiple mappings with one
  writable disables caching on the whole page, there can be a big penalty
  depending on what other data is nearby that suddenly becomes
  uncacheable.  I was initially very interested in the work to read system
  clocks without a syscall until I realized it was going to suffer from
  the same problem.
 
 Since only kernel writes to the shared page, it should be not a problem.
 At least there is a specific point where you can insert the neccessary
 cache flush commands.

With VIVT cache, all mappings of a page must be uncacheable no matter
which one is writable.  It applies even if all the mappings belong to
the kernel (this is why the wired writable pages in the buffer cache
kill executable performance with VIVT caches).

There's no way to keep a VIVT cache coherent when there are multiple
mappings, because of the virtual indexing: you write to a page, then do
a flush based on that page's virtual address, and there's no way find
cache lines which alias the same physical memory using different virtual
addresses to flush them too.

 Also, I suspect that even for arms, the writes are executed from the
 same core, which could simplify things even more.

The arm chips that are affected by this don't have multiple cores (at
least, I don't think there are any VIVT cache multi-core arms, it's
probably not even possible).

-- Ian


___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

Re: Fast sigblock (AKA rtld speedup)

[Ian Lepore]

On Sun, 2013-01-13 at 19:50 +0200, Konstantin Belousov wrote:
 On Sun, Jan 13, 2013 at 10:46:27AM -0700, Ian Lepore wrote:
  On Sun, 2013-01-13 at 17:06 +0200, Konstantin Belousov wrote:
   On Sun, Jan 13, 2013 at 07:50:14AM -0700, Ian Lepore wrote:
On Sat, 2013-01-12 at 15:04 -0800, John-Mark Gurney wrote:
 David Xu wrote this message on Tue, Jan 08, 2013 at 13:09 +0800:
  and can not be freed until process is exited, the page is doubly
  mapped into in kernel and userland, accessing the shared data
  in kernel has zero overhead though.
 
 Don't forget that there are arches out there w/ VIVT caches which will
 probably eliminate most of the performance benifits if we have the 
 same
 page mapped writable in two different virtual addresses..
 

Even worse than eliminate the benefits, since multiple mappings with one
writable disables caching on the whole page, there can be a big penalty
depending on what other data is nearby that suddenly becomes
uncacheable.  I was initially very interested in the work to read system
clocks without a syscall until I realized it was going to suffer from
the same problem.
   
   Since only kernel writes to the shared page, it should be not a problem.
   At least there is a specific point where you can insert the neccessary
   cache flush commands.
  
  With VIVT cache, all mappings of a page must be uncacheable no matter
  which one is writable.  It applies even if all the mappings belong to
  the kernel (this is why the wired writable pages in the buffer cache
  kill executable performance with VIVT caches).
  
  There's no way to keep a VIVT cache coherent when there are multiple
  mappings, because of the virtual indexing: you write to a page, then do
  a flush based on that page's virtual address, and there's no way find
  cache lines which alias the same physical memory using different virtual
  addresses to flush them too.
 No, you do know all the mapping addresses in this special case.
 
 The shared page is mapped at the fixed user address, and at some
 kernel address. You obviously need to flush both cache lines.
 
  
   Also, I suspect that even for arms, the writes are executed from the
   same core, which could simplify things even more.
  
  The arm chips that are affected by this don't have multiple cores (at
  least, I don't think there are any VIVT cache multi-core arms, it's
  probably not even possible).
  
  -- Ian
  

But as soon as you establish the second mapping, the code in pmap.c
automatically remaps all existing mappings as uncacheable.  It would be
some pretty big work to special-case that for a few mappings where the
kernel knows what it's doing.

-- ian


___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

Re: Clang as default compiler November 4th

[Ian Lepore]

On Wed, 2012-09-12 at 19:08 -0700, Steve Kargl wrote:
 In regards to my initial post in this thread, I was just trying
 to assess whether any benchmarks have been performed on FreeBSD
 for floating point generated by clang.  Other than the limited
 testing that I've done, it appears that the answer is 'no'.
 

We have src/tools/tests/testfloat and src/tools/regression/lib/msun.  I
know nothing about the former (just noticed it for the first time).  The
latter I think is a set of correctness tests rather than performance
tests.

-- Ian

___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org