Re: Removing obsolete GDB 6.1.1 for FreeBSD 13

[Warner Losh]

On Wed, Dec 2, 2020 at 10:44 AM Ed Maste  wrote:

> We currently have an obsolete version of GDB 6.1 installed as
> /usr/libexec/gdb, kept only for use by crashinfo(8), which extracts
> some basic information from a kernel core dump after a crash. If the
> gdb port is installed crashinfo will use that in preference to
> /usr/libexec/gdb. If neither exists it will not perform any analysis,
> reporting "Unable to find a kernel debugger."
>
> GDB 6.1.1 was released in June 2004 and is long obsolete. It does not
> support all of the architectures that FreeBSD does, and imposes
> limitations on the FreeBSD kernel build - the continued use of DWARF2.
>
> I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to
> switch the GDB knob to default to NO in the near future. If the
> crashinfo utility and related man pages do not already include
> references to installing the gdb port/package I will add those before
> making the change.
>
> In the fullness of time we may use LLDB to extract the same
> information, or provide other tooling to do so, but I do not want to
> block GDB 6.1.1's removal on this.
>
> Please let me know of any objections or comments.
>

I fully support this action. We kept gdb on board for 12 (and 11?) for
crashinfo as a transition to the new gdb port and to help smooth over bumps
from moving kgdb support into that port. jhb@ has done a great job in
getting kgdb moved into the port. I use the port exclusively these days for
all the kernel debugging I have to do from panics in our fleet (although I
have some minorly special needs so I use a special script to fit into our
buildenv vs deployed env). The current gdb in the base can't cope with
anything more complicated than 'hello world'. It's broken for threads. It's
broken for much of the code clang generates. It's useless for kernel dumps
(even tracebacks are unreliable in my experience). There's little to no
value that having gdb in the tree at this point.

I also agree that none of this should be gated on lldb. gdb in tree is so
out of date that we are much better off removing it, even if lldb isn't a
complete drop in replacement (I've not used it at all, so I can't say one
way or another).

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"

Re: Remove ftime() interceptor defs from compiler-rt/FreeBSD

[Warner Losh]

On Sat, Nov 21, 2020, 9:26 PM Kyle Evans  wrote:

> Hi,
>
> Can we remove the ftime() interceptor definitions that are FreeBSD
> specific in compiler-rt? See:
> https://people.freebsd.org/~kevans/intercept.diff -- the very act of
> including sys/timeb.h adds build noise from the warning about it being
> deprecated, when ftime() is apparently not even intercepted on
> FreeBSD:
>
> #define SANITIZER_INTERCEPT_FTIME \
>   (!SI_FREEBSD && !SI_NETBSD && !SI_OPENBSD && SI_POSIX)
>

Seems legit. Time is marked legacy in xopen. It was only a thing on V7.
BSD4 added the replacement gettimeofday(). I'm not seeing any reason to not
do this, but I've not looked into this in depth... This hasn't been an
important function in a long time.

Warner

Thanks,
>
> Kyle Evans
> ___
> 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"
>
___
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: head -r357401 broke my powerpc/powerpc64 builds: I build with sc present [the added "static" caused the failures]

[Warner Losh]

On Mon, Feb 3, 2020 at 3:33 AM Mark Millard  wrote:

> [Turns out to be the added "static".]
>
> On 2020-Feb-2, at 15:10, Mark Millard  wrote:
>
> > [I forgot to send some context.]
> >
> > On 2020-Feb-2, at 14:51, Mark Millard  wrote:
> >
> >> --- kernel.full ---
> >> ld: error: undefined symbol: dflt_font_8
> > referenced by ofw_syscons.c
> > ofw_syscons.o:(.toc+0x10)
> >> ld: error: undefined symbol: dflt_font_14
> > referenced by ofw_syscons.c
> > ofw_syscons.o:(.toc+0x18)
> >> ld: error: undefined symbol: dflt_font_16
> > referenced by ofw_syscons.c
> > ofw_syscons.o:(.toc+0x20)
> >>
> >> This is from loss of:
> >>
> >>
> >>
> >> font.h  optionalsc
> \
> >>compile-with"uudecode <
> /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x16.fnt && file2c 'u_char
> dflt_font_16[16*256] = {' '};' < ${SC_DFLT_FONT}-8x16 > font.h && uudecode
> < /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x14.fnt && file2c 'u_char
> dflt_font_14[14*256] = {' '};' < ${SC_DFLT_FONT}-8x14 >> font.h && uudecode
> < /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x8.fnt && file2c 'u_char
> dflt_font_8[8*256] = {' '};' < ${SC_DFLT_FONT}-8x8 >> font.h" \
> >>no-obj no-implicit-rule before-depend
>  \
> >>clean   "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16
> ${SC_DFLT_FONT}-8x8"
> >>
> >>
> >> in /head/sys/conf/files.powerpc .
> >>
> >>
> >> FYI for why I have sc present:
> >>
> >> Historically, I've had two PowerMac contexts, one of which
> >> worked with sc but not vt and another of which worked with
> >> vt but not sc.
> >>
> >> I build with both sc and vt present and change which is
> >> used as I move the media between machines.
> >
> > FYI: my powerpc* kernel config files have (using a powerpc64
> > example):
> >
> > include "GENERIC64"
> >
> > . . .
> >
> > nooptions   PS3 # Sony Playstation 3
>HACK!!! to allow sc
> >
> > . . .
> >
> > # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt
> historically mishandled during booting
> > device  sc
> > #device kbdmux  # HACK: already listed by vt
> > options SC_OFWFB# OFW frame buffer
> > options SC_DFLT_FONT# compile font in
> > makeoptions SC_DFLT_FONT=cp437
> >
> >
> > I'm exploring rebuilding from scratch, but it
> > may be that this change could use some form
> > of UPDATING note about how to deal with the
> > changes.
>
> The following enabled my powerpc* builds: I dropped
> "static " from each declaration that is generated.
>
> (In this form some whitespace might not be
> preserved below.)
>
> # svnlite diff /usr/src/sys/conf/files
> Index: /usr/src/sys/conf/files
> ===
> --- /usr/src/sys/conf/files (revision 357419)
> +++ /usr/src/sys/conf/files (working copy)
> @@ -35,7 +35,7 @@
> no-obj no-implicit-rule before-depend
> \
> clean   "feeder_rate_gen.h"
>  font.h optionalsc_dflt_font\
> -   compile-with"uudecode <
> ${SRCTOP}/share/syscons/fonts/${SC_DFLT_FONT}-8x16.fnt && file2c 'static
> u_char dflt_font_16[16*256] = {' '};' < ${SC_DFLT_FONT}-8x16 > font.h &&
> uudecode < ${SRCTOP}/share/syscons/fonts/${SC_DFLT_FONT}-8x14.fnt && file2c
> 'static u_char dflt_font_14[14*256] = {' '};' < ${SC_DFLT_FONT}-8x14 >>
> font.h && uudecode < ${SRCTOP}/share/syscons/fonts/${SC_DFLT_FONT}-8x8.fnt
> && file2c 'static u_char dflt_font_8[8*256] = {' '};' < ${SC_DFLT_FONT}-8x8
> >> font.h"
>\
> +   compile-with"uudecode <
> ${SRCTOP}/share/syscons/fonts/${SC_DFLT_FONT}-8x16.fnt && file2c 'u_char
> dflt_font_16[16*256] = {' '};' < ${SC_DFLT_FONT}-8x16 > font.h && uudecode
> < ${SRCTOP}/share/syscons/fonts/${SC_DFLT_FONT}-8x14.fnt && file2c 'u_char
> dflt_font_14[14*256] = {' '};' < ${SC_DFLT_FONT}-8x14 >> font.h && uudecode
> < ${SRCTOP}/share/syscons/fonts/${SC_DFLT_FONT}-8x8.fnt && file2c 'u_char
> dflt_font_8[8*256] = {' '};' < ${SC_DFLT_FONT}-8x8 >> font.h"
> \
> no-obj no-implicit-rule before-depend   \
> clean   "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16
> ${SC_DFLT_FONT}-8x8"
>  snd_fxdiv_gen.hoptional sound
>  \
>
>
> If the "static"s are strongly wanted, then the powerpc*
> families need to be reworked to allow for such.
>

Yea, ofw_syscons.c reaches over into these arrays. I've removed the static
for now. syscons is on the way out, so I don't want to waste too much time
on it.

warner


>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
>
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to 

Re: head -r357401 broke my powerpc/powerpc64 builds: I build with sc present

[Warner Losh]

I'll take a look... that's likely my fault for fixing the bogus duplication
that wasn't quite duplicated.

On Mon, Feb 3, 2020 at 12:10 AM Mark Millard  wrote:

> [I forgot to send some context.]
>
> On 2020-Feb-2, at 14:51, Mark Millard  wrote:
>
> > --- kernel.full ---
> > ld: error: undefined symbol: dflt_font_8
>  referenced by ofw_syscons.c
>   ofw_syscons.o:(.toc+0x10)
> > ld: error: undefined symbol: dflt_font_14
>  referenced by ofw_syscons.c
>   ofw_syscons.o:(.toc+0x18)
> > ld: error: undefined symbol: dflt_font_16
>  referenced by ofw_syscons.c
>   ofw_syscons.o:(.toc+0x20)
> >
> > This is from loss of:
> >
> >
> >
> > font.h  optionalsc
> \
> > compile-with"uudecode <
> /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x16.fnt && file2c 'u_char
> dflt_font_16[16*256] = {' '};' < ${SC_DFLT_FONT}-8x16 > font.h && uudecode
> < /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x14.fnt && file2c 'u_char
> dflt_font_14[14*256] = {' '};' < ${SC_DFLT_FONT}-8x14 >> font.h && uudecode
> < /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x8.fnt && file2c 'u_char
> dflt_font_8[8*256] = {' '};' < ${SC_DFLT_FONT}-8x8 >> font.h" \
> > no-obj no-implicit-rule before-depend
>  \
> > clean   "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16
> ${SC_DFLT_FONT}-8x8"
> >
> >
> > in /head/sys/conf/files.powerpc .
> >
> >
> > FYI for why I have sc present:
> >
> > Historically, I've had two PowerMac contexts, one of which
> > worked with sc but not vt and another of which worked with
> > vt but not sc.
> >
> > I build with both sc and vt present and change which is
> > used as I move the media between machines.
>
> FYI: my powerpc* kernel config files have (using a powerpc64
> example):
>
> include "GENERIC64"
>
> . . .
>
> nooptions   PS3 # Sony Playstation 3
>  HACK!!! to allow sc
>
> . . .
>
> # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt
> historically mishandled during booting
> device  sc
> #device kbdmux  # HACK: already listed by vt
> options SC_OFWFB# OFW frame buffer
> options SC_DFLT_FONT# compile font in
> makeoptions SC_DFLT_FONT=cp437
>
>
> I'm exploring rebuilding from scratch, but it
> may be that this change could use some form
> of UPDATING note about how to deal with the
> changes.
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
>
___
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: External GCC Update

[Warner Losh]

On Fri, Feb 22, 2019, 5:09 PM John Baldwin  wrote:

> On 2/22/19 11:45 AM, Rodney W. Grimes wrote:
> >> I was recently able to install base/binutils and base/gcc into an amd64
> VM
> >> and do a self-hosted build and install.  Some of the port patches have
> been
> >> committed from this, but I have some source patches before the final
> ports
> >> patches can be finished.
> >>
> >> The source patches are here:
> >> https://github.com/bsdjhb/freebsd/compare/master...base_gcc
> >
> > Phabricator?
>
> Eventually, wanted a first cut of the entire patchset in context to see if
> folks run screaming or not.
>


Thank you. Phabricator isn't good with larger patches. Git let's me see
things in a number of different views that are hard with the one size fits
all phab ui.

Warner

-- 
> John Baldwin
>
>
>
> ___
> 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"
>
___
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: Is libc C99 compliant?

[Warner Losh]

On Wed, Jan 30, 2019 at 11:33 PM Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

> When building gcc file gcc/config/freebsd.c contains
>
> #define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
>
> In targhook.c, one finds
>
> /* By default we assume that c99 functions are present at the runtime,
>but sincos is not.  */
> bool
> default_libc_has_function (enum function_class fn_class)
> {
>   if (fn_class == function_c94
>   || fn_class == function_c99_misc
>   || fn_class == function_c99_math_complex)
> return true;
>
>   return false;
> }
>
> bool
> no_c99_libc_has_function (enum function_class fn_class ATTRIBUTE_UNUSED)
> {
>   return false;
> }
>
> Shouldi/can TARGET_LIBC_HAS_FUNCTION be updated to at least
> default_libc_has_function?  More importantly now that libm
> contains sincos[fl], should FreeBSD gcc config file be updated
> to use
>
> bool
> bsd_libc_has_function (enum function_class fn_class)
> {
>   if (fn_class == function_c94
>   || fn_class == function_c99_misc
>   || fn_class == function_c99_math_complex
>   || fn_class == function_sincos)
> return true;
>
>   return false;
> }


On its surface, this seems sane to me. what does this control? And is this
for our ancient 4.2 or current gcc...

Warner


>
> --
> Steve
> ___
> 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"
>
___
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: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build

[Warner Losh]

On Mon, Oct 15, 2018 at 12:25 PM John Baldwin  wrote:

> On 10/15/18 11:06 AM, Warner Losh wrote:
> >
> >
> > On Mon, Oct 15, 2018, 10:20 AM John Baldwin  j...@freebsd.org>> wrote:
> >
> > On 10/12/18 6:51 AM, Mark Millard wrote:
> > > The following is from attempting to build devel/powerpc-gcc
> > > via poudriere-devel on the powerpc64 system after having
> > > bootstrapped via (in part) base/binutils and the .txz
> > > produced on the host (amd64).
> > >
> > > Looks like having both:
> > >
> > > /usr/bin/powerpc64-unknown-freebsd12.0-*
> > > and:
> > > /usr/local/bin/powerpc64-unknown-freebsd12.0-*
> > >
> > > in a powerpc64 environment confuses "phase: build-depends"
> > > in poudriere for the devel/powerpc64-gcc build:
> >
> > Ah, I could see that.  I had kept the longer binary names with the
> full tuple
> > since the original base/binutils had them, but I've considered
> stripping them
> > as we only really need /usr/bin/as, etc. for the base system.  I
> hadn't gotten
> > to the point of trying to build any ports with base/* as I'm still
> trying to
> > just do a buildworld (and running poudriere in a qemu image of
> mips64 would
> > be very unpleasant).  I think probably base/binutils just needs to
> drop the
> > names with a full tuple if possible.
> >
> >
> > Having symlinks to the long names plays nicer with autoconf, of at least
> has in the past. Our build system doesn't care, though...
>
> I think it only plays nicer for the port.  We've never had
> /usr/bin/x86_64-freebsd-ld
> linked to /usr/bin/ld in base, and base/binutils' role is to provide
> /usr/bin/as,
> /usr/bin/ld, etc.
>

The tools built by xdev did, though not that specific link... I do agree
that if we do this, it's only of marginal benefit.

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"

Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build

[Warner Losh]

On Mon, Oct 15, 2018, 10:20 AM John Baldwin  wrote:

> On 10/12/18 6:51 AM, Mark Millard wrote:
> > The following is from attempting to build devel/powerpc-gcc
> > via poudriere-devel on the powerpc64 system after having
> > bootstrapped via (in part) base/binutils and the .txz
> > produced on the host (amd64).
> >
> > Looks like having both:
> >
> > /usr/bin/powerpc64-unknown-freebsd12.0-*
> > and:
> > /usr/local/bin/powerpc64-unknown-freebsd12.0-*
> >
> > in a powerpc64 environment confuses "phase: build-depends"
> > in poudriere for the devel/powerpc64-gcc build:
>
> Ah, I could see that.  I had kept the longer binary names with the full
> tuple
> since the original base/binutils had them, but I've considered stripping
> them
> as we only really need /usr/bin/as, etc. for the base system.  I hadn't
> gotten
> to the point of trying to build any ports with base/* as I'm still trying
> to
> just do a buildworld (and running poudriere in a qemu image of mips64 would
> be very unpleasant).  I think probably base/binutils just needs to drop the
> names with a full tuple if possible.
>

Having symlinks to the long names plays nicer with autoconf, of at least
has in the past. Our build system doesn't care, though...

Warner

-- 
> John Baldwin
>
>
>
> ___
> 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"
>
___
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: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

[Warner Losh]

On Fri, Sep 21, 2018 at 9:59 PM Rebecca Cran  wrote:

> On 9/21/18 9:57 PM, Warner Losh wrote:
>
> > Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say?
> >
> > They look good for me, but the only way you get this error is if they
> > are wrong.
>
>
> bcran@cube:~/workspace/freebsd % make -V LINKER_TYPE
> bfd
>
> bcran@cube:~/workspace/freebsd % make -V LINKER_FEATURES
>  filter
>

That may be the issue... Does the patch I included help? I'm building now
on my stable system, but it's slow...

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"

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

[Warner Losh]

Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say?

They look good for me, but the only way you get this error is if they are
wrong.

Although from your typescript, I see:

===> lib/libc (cleandir)
make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26:
amd64 libc requires linker ifunc support

which tells me that we need to exclude all the non-build targets from this
check This will use the HOST linker rather than the TARGET linker.

So something like:

diff --git a/lib/libc/Makefile b/lib/libc/Makefile
index a1ce123c0f33..11575e1cabff 100644
--- a/lib/libc/Makefile
+++ b/lib/libc/Makefile
@@ -21,10 +21,12 @@ LIBC_ARCH=${MACHINE_ARCH}
 LIBC_ARCH=${MACHINE_CPUARCH}
 .endif

+.if build(all)
 .if (${LIBC_ARCH} == amd64 || ${LIBC_ARCH} == i386) && \
 defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc} == ""
 .error ${LIBC_ARCH} libc requires linker ifunc support
 .endif
+.endif

 # All library objects contain FreeBSD revision strings by default; they
may be
 # excluded as a space-saving measure.  To produce a library that does

may be needed, but the problem may be related to caching these values from
the host as well, even though we rebuild them...

Warner

On Fri, Sep 21, 2018 at 9:38 PM Rebecca Cran  wrote:

> On 9/21/18 9:35 PM, Warner Losh wrote:
> >
> > I meant to add, can you give a few lines before the error is spewed
> > here in email? My IRC computer died before I could see any answers
> > there...
> >
> > My 11.2-stable system has 6.0.1, so I can't test from there.
>
>
> I've uploaded the full 'buildworld' output to
> https://bluestop.org/files/typescript.txt .
>
>
> --
>
> Rebecca
>
>
___
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: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

[Warner Losh]

On Fri, Sep 21, 2018 at 9:34 PM Warner Losh  wrote:

>
>
> On Fri, Sep 21, 2018 at 9:30 PM Rebecca Cran  wrote:
>
>> On 9/21/18 9:09 PM, Warner Losh wrote:
>>
>> > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain <
>> > freebsd-toolchain@freebsd.org> wrote:
>> >
>> >> On 9/21/18 4:06 PM, Mark Johnston wrote:
>> >>> https://reviews.freebsd.org/D17279 for anyone else that would like to
>> >>> review.
>> >>
>> >> Is that possibly related to the error I'm getting trying to build
>> >> -CURRENT on 11.2?
>> >>
>> >>
>> >> make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26:
>> >> amd64 libc requires linker ifunc support
>> >>
>> > Yea, that should absolutely work. If it doesn't, that's a big big
>> problem.
>>
>>
>> I see, it was introduced earlier today in lib/libc/Makefile:
>>
>>
>> commit ef8030831eccec4e481a1766fc1c67f7cadadac9
>> Author: emaste 
>> Date:   Fri Sep 21 17:49:37 2018 +
>>
>> libc: require ifunc-capable linker for amd64/i386
>>
>> We expect to introduce optimized libc routines in the near future,
>> which requires use of a linker that supports ifuncs.
>>
>> Approved by:re (gjb, kib)
>> Sponsored by:   The FreeBSD Foundation
>>
>>
>> And /usr/bin/ld -v on my 11.2 system says:
>>
>>
>> GNU ld 2.17.50 [FreeBSD] 2007-07-03
>>
>
> What does ld.lld say?
>
> However, it shouldn't matter: we don't build libc until *AFTER* we build
> ld.lld, so this error is bogusly triggering. I suspect that it needs to be
> limited to only building targets, since tree traversal ones, as well as
> install targets don't have this dependency.
>

I meant to add, can you give a few lines before the error is spewed here in
email? My IRC computer died before I could see any answers there...

My 11.2-stable system has 6.0.1, so I can't test from there.

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"

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

[Warner Losh]

On Fri, Sep 21, 2018 at 9:30 PM Rebecca Cran  wrote:

> On 9/21/18 9:09 PM, Warner Losh wrote:
>
> > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain <
> > freebsd-toolchain@freebsd.org> wrote:
> >
> >> On 9/21/18 4:06 PM, Mark Johnston wrote:
> >>> https://reviews.freebsd.org/D17279 for anyone else that would like to
> >>> review.
> >>
> >> Is that possibly related to the error I'm getting trying to build
> >> -CURRENT on 11.2?
> >>
> >>
> >> make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26:
> >> amd64 libc requires linker ifunc support
> >>
> > Yea, that should absolutely work. If it doesn't, that's a big big
> problem.
>
>
> I see, it was introduced earlier today in lib/libc/Makefile:
>
>
> commit ef8030831eccec4e481a1766fc1c67f7cadadac9
> Author: emaste 
> Date:   Fri Sep 21 17:49:37 2018 +
>
> libc: require ifunc-capable linker for amd64/i386
>
> We expect to introduce optimized libc routines in the near future,
> which requires use of a linker that supports ifuncs.
>
> Approved by:re (gjb, kib)
> Sponsored by:   The FreeBSD Foundation
>
>
> And /usr/bin/ld -v on my 11.2 system says:
>
>
> GNU ld 2.17.50 [FreeBSD] 2007-07-03
>

What does ld.lld say?

However, it shouldn't matter: we don't build libc until *AFTER* we build
ld.lld, so this error is bogusly triggering. I suspect that it needs to be
limited to only building targets, since tree traversal ones, as well as
install targets don't have this dependency.

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"

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

[Warner Losh]

On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain <
freebsd-toolchain@freebsd.org> wrote:

> On 9/21/18 4:06 PM, Mark Johnston wrote:
> >
> > https://reviews.freebsd.org/D17279 for anyone else that would like to
> > review.
>
>
> Is that possibly related to the error I'm getting trying to build
> -CURRENT on 11.2?
>
>
> make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26:
> amd64 libc requires linker ifunc support
>

Yea, that should absolutely work. If it doesn't, that's a big big problem.

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"

Re: Broken arm support in clang now?

[Warner Losh]

On Thu, Aug 16, 2018 at 8:14 AM, Mark Millard  wrote:

> On 2018-Aug-16, at 6:38 AM, Ed Maste  wrote:
>
> > On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain
> >  wrote:
> >>
> >> Is the link command itself available? (The .../sys/*/kernel.full.meta
> >> likely has it if it is still around.)
> >
> > I tried a tinderbox build right now and saw the lld warnings from
> > linking zfs.ko.  It appears to be fallout from the change to build
> > clang and lld only once for tinderbox, because we're invoking ld from
> > the ${HOST_TARGET} path:
> >
> > /scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/
> freebsd11-amd64/tmp/usr/bin/ld
> > -m armelf_fbsd -Bshareable -znotext -d -warn-common --build-id=sha1
> > -o zfs.ko.full zfs.kld
> > /scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/
> freebsd11-amd64/tmp/usr/bin/ld:
> > warning: lld uses extended branch encoding, no object with
> > architecture supporting feature detected.
> > /scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/
> freebsd11-amd64/tmp/usr/bin/ld:
> > warning: lld may use movt/movw, no object with architecture supporting
> > feature detected.
>
> So ld.lld is not a valid cross linker for some arm variants? A
> architecture specific bootstrap one is needed?
>
> Is this because armelf_fbsd is not specific enough to
> identify the accurate target emulation? Is it because
> the .o's are not sufficient for that identification?
>
> Note: I got the questions from reading the output in:
>
> # ld.lld
> ld.lld: error: no input files
> ld.lld: error: target emulation unknown: -m or at least one .o file
> required
>
> So it appears that -m and/or .o's are used to identify targets.
> I'm not clear on the criteria when both are present.
>
> (ld.lld does not take -target as an argument.)


lld uses instructions and features introduced in armv7 unconditionally to
do its linking. The bug appears to be that clang invokes it unconditionally
in some cases.

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"

Re: Broken arm support in clang now?

[Warner Losh]

On Sat, Aug 11, 2018 at 1:01 PM, Mark Millard <
mark.mill...@nexustechnology.com> wrote:

> On 2018-Aug-11, at 11:09 AM, Dimitry Andric  wrote:
> >
> > On 11 Aug 2018, at 19:31, Warner Losh  wrote:
> >>
> >> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric  wrote:
> >> On 11 Aug 2018, at 16:55, Warner Losh  wrote:
> >>>
> >>> It looks like armv5 clang bogusly uses lld:
> >>>
> >>> From a 'make buildkernel' of the RT1310 kernel config:
> >>>
> >>> cc -target arm-gnueabi-freebsd12.0
> > ...
> >>> ld: warning: lld uses extended branch encoding, no object with
> architecture
> >>> supporting feature detected.
> >>> ld: warning: lld may use movt/movw, no object with architecture
> supporting
> >>> feature detected.
> > ...
>
> Did the build get either of the below notices? Both?
>
> make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined
> that CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
>

This one I have.


> make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that
> LD=ld matches the source tree.  Not bootstrapping a cross-linker.
>

This one I don't.

Warner


> ?
>
> (The example text was taken from an amd64 -> aarch64 cross build.)
>
> >> Host is amd64. Target is arm. No src.conf. Did a full buildworld
> TARGET=arm a few days ago. /usr/bin/ld is lld.
> >
> > Okay, so in the above "cc" command, can you somehow figure out which cc
> > executable it is using? And please add a -v to the "linking kernel.full"
> > command line, so it shows exactly which linker it runs?
> >
> > I have the idea that it is preferring your /usr/bin/ld over
> > ${WORLDTMP}/usr/bin/ld...
>
>
>
> ===
>
> Mark Millard
> Nexus Technology, Inc.
> 78 Northeastern Blvd., Unit #2
> Nashua  NH  03062
>
> 877-595-8116  x821
>
> mark.mill...@nexustechnology.com
>
>
___
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: Broken arm support in clang now?

[Warner Losh]

On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric  wrote:

> On 11 Aug 2018, at 16:55, Warner Losh  wrote:
> >
> > It looks like armv5 clang bogusly uses lld:
> >
> > From a 'make buildkernel' of the RT1310 kernel config:
> >
> > cc -target arm-gnueabi-freebsd12.0
> > --sysroot=/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp
> > -B/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp/usr/bin -c -O -pipe
> > -g -nostdinc  -I. -I/usr/home/imp/git/head/sys
> > -I/usr/home/imp/git/head/sys/contrib/ck/include
> > -I/usr/home/imp/git/head/sys/contrib/libfdt
> > -I/usr/home/imp/git/head/sys/gnu/dts/include -D_KERNEL
> > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -march=armv5te
> > -funwind-tables  -ffreestanding -fwrapv -gdwarf-2 -Wall -Wredundant-decls
> > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> > -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
> > -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
> > -Wno-error-tautological-compare -Wno-error-empty-body
> > -Wno-error-parentheses-equality -Wno-error-unused-function
> > -Wno-error-pointer-sign -Wno-error-shift-negative-value
> > -Wno-address-of-packed-member  -mfpu=none  -std=iso9899:1999 -Werror
> vers.c
> > linking kernel.full
> > ld: warning: lld uses extended branch encoding, no object with
> architecture
> > supporting feature detected.
> > ld: warning: lld may use movt/movw, no object with architecture
> supporting
> > feature detected.
> > text data  bss   dechex   filename
> >  3448944   176776   655360   4281080   0x4152f8   kernel.full
> >
> > Any clues on how I can track this down?
>
> What does /usr/bin/ld -v output?  As far as I can see, MK_LLD_BOOTSTRAP
> and MK_LLD_IS_LD are only enabled by default for aarch64 and amd64.  So
> do you have any of those settings in your src.conf or environment?
>

Host is amd64. Target is arm. No src.conf. Did a full buildworld TARGET=arm
a few days ago. /usr/bin/ld is lld.

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"

Broken arm support in clang now?

[Warner Losh]

It looks like armv5 clang bogusly uses lld:

>From a 'make buildkernel' of the RT1310 kernel config:

cc -target arm-gnueabi-freebsd12.0
--sysroot=/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp
-B/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp/usr/bin -c -O -pipe
-g -nostdinc  -I. -I/usr/home/imp/git/head/sys
-I/usr/home/imp/git/head/sys/contrib/ck/include
-I/usr/home/imp/git/head/sys/contrib/libfdt
-I/usr/home/imp/git/head/sys/gnu/dts/include -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -march=armv5te
-funwind-tables  -ffreestanding -fwrapv -gdwarf-2 -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Wno-error-shift-negative-value
-Wno-address-of-packed-member  -mfpu=none  -std=iso9899:1999 -Werror  vers.c
linking kernel.full
ld: warning: lld uses extended branch encoding, no object with architecture
supporting feature detected.
ld: warning: lld may use movt/movw, no object with architecture supporting
feature detected.
 text data  bss   dechex   filename
  3448944   176776   655360   4281080   0x4152f8   kernel.full

Any clues on how I can track this down?

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"

Re: Migrating arm(v7) to LLD_BOOTSTRAP

[Warner Losh]

On Tue, Jan 16, 2018 at 4:45 PM, Ed Maste  wrote:

> With the update to Clang/LLVM/lld 6.0.0 I believe lld is nearly ready
> to be used as the system linker for armv7, and I plan to enable
> LLD_BOOTSTRAP by default after a couple of WIP patches land and after
> a little more testing. This may happen a week or two from now. This
> should have little impact on port builds, because /usr/bin/ld will
> still be GNU ld.bfd (although there may be some unexpected fallout).
>
> I expect to enable LLD_IS_LD by default a little later, and
> /usr/bin/ld will then be lld. This is the same path we're taking with
> amd64.
>
> lld currently does not support architectures prior to armv7, and fails
> with some combination of these errors when I try to use it for
> arm{,v5,v6,eb}:
>
> ld: error: lld uses blx instruction, no object with architecture
> supporting feature detected.
> ld: error: lld uses extended branch encoding, no object with
> architecture supporting feature detected.
> ld: error: lld may use movt/movw, no object with architecture
> supporting feature detected.
>
> I expect this will be addressed in a future version of lld.
>

At least some of that is due to the gap size that's defined for all of ARM.
With a smaller gap size, the trampolines will work better on older ARM
gear

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"

Re: Head build unsafe for /etc today

[Warner Losh]

On Thu, Nov 2, 2017 at 8:41 PM, Bryan Drewery  wrote:

>
>
> > On Nov 2, 2017, at 19:23, Steve Kargl 
> wrote:
> >
> >> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
> >>
> >>
>  On Nov 2, 2017, at 18:49, Steve Kargl  edu> wrote:
> 
>  On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
> 
>  On Nov 2, 2017, at 15:44, Mark Millard  wrote:
> 
> >> Author: bdrewery
> >> Date: Thu Nov  2 22:23:00 2017
> >> New Revision: 325347
> >> URL:
> >> https://svnweb.freebsd.org/changeset/base/325347
> >>
> >>
> >> Log:
> >> Something is very wrong
> 
> 
>  Unfortunately I only test with META_MODE these days which implies
> -DNO_CLEAN.
> >>>
> >>> You're making changes to the build infrastructure and you're
> >>> not properly testing it before committing?  This is beyond
> >>> pointyhat material.
> >>
> >> I ran 2 universes, dozens of buildworlds and buildkernels, dozens of
> installworld and installkernel, several xdev and native-xtools, several
> full DIRDEPS_BUILD builds and bootstraps, ran subdir builds, ran subdir
> cleans, tested several targets together, ran various special case tests for
> submakes, played around with a ton of MAKEOBJDIRPREFIX cases, handled and
> tested symlinked objdirs special, ran it through my work repro a few times,
> did special testing in rescue/, and had a volunteer test release.  In the
> process  I found a bmake bug, GPL_DTC build bug and several others I don’t
> recall from the bus.
> >>
> >> What I missed was the “clean” buildworld because I forgot it even
> exists. I’ve wanted to remove it for a year. I also forgot to test buildenv.
> >>
> >
> > If you did all the above under META_MODE, then no you did not
> > buildworld and buildkernel and all the other stuff you claim.
>
> Are you accusing me of lying?
>
>
> > If your first step isn't  'cd /usr/obj ; rm -rf *' or equivalent
> > in whatever jail you use, then you're not properly testing
> > your changes to the build
>
> I did that probably 100 times. And that isn’t even “the proper test”. Both
> clean and incremental are needed which I did. zfs snapshots help a lot
> there. I just never ran “_cleanobj” which does a full tree walk of clean.
> But I ran make clean in some subdirs many times.
>
> > infrastructure.  As you have demonstrated,
> > Makefile, Makefile.inc1, and the *.mk files are sufficiently
> > complicated that proper testing
>
> > should be done, and proper
> > testing means one doesn't takes shortcuts.
>
> I took 0 shortcuts. As I said I *forgot* that case, among hundreds of
> cases.
> You’re welcome to do this work if you want. I guarantee you would not have
> tested even half of what I tested.
>
> Hey can you fix universe to only build clang once please? I’ve been
> working up to that but I think you’re best to do it.


Given the hundreds of commits to the build system and its complexity, I'm
in awe this doesn't happen more often. Heck, I've done an order of
magnitude fewer commits to the build system and broken it more often than
you have, and that's when it was a much simpler beast than it is today.

Steve's just being overly grumpy imho.  Accidents happen despite one's best
efforts. This is -current after all...

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"

Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more

[Warner Losh]

On Sun, Sep 10, 2017 at 3:18 PM, Mark Millard <mar...@dsl-only.net> wrote:

> On 2017-Sep-10, at 1:17 PM, Warner Losh  wrote:
>
> > On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard <mar...@dsl-only.net>
> wrote:
> > When I attempted to use the result of:
> >
> > # cp -aRx /usr/obj/DESTDIRs/clang-cortexA53-installworld/boot/boot1.efi
> /mnt/EFI/BOOT/
> >
> > the pine64+ boot sequence got over and over
> > a sequence like:
> >
> > U-Boot 2017.07 (Sep 06 2017 - 07:49:12 +) Allwinner Technology
> >
> > CPU:   Allwinner A64 (SUN50I)
> > Model: Pine64+
> > DRAM:  2 GiB
> > MMC:   SUNXI SD/MMC: 0
> > *** Warning - bad CRC, using default environment
> >
> > In:serial
> > Out:   serial
> > . . .
> > >> FreeBSD EFI boot block
> >Loader path: /boot/loader.efi
> >
> >Initializing modules: ZFS UFS
> >Load Path:
> > "Synchronous Abort" handler, esr 0x9604
> > ELR: bdf90b30
> > LR:  bdf8fb6c
> > x0 :  x1 : 
> > x2 : bdffc000 x3 : 4000
> > x4 : b9f34d40 x5 : 
> > x6 : 0015 x7 : 
> > x8 : bdfa59b8 x9 : 001c
> > x10: 0002 x11: 
> > x12:  x13: 
> > x14:  x15: 
> > x16:  x17: 
> > x18: b9f39df8 x19: 
> > x20:  x21: 0002
> > x22: b8f34c98 x23: b8f34c88
> > x24: b8f34ca0 x25: 07d0
> > x26: b8f34c90 x27: b8f2f198
> > x28:  x29: b9f34de0
> >
> > Resetting CPU ...
> >
> > resetting ...
> >
> > It would be super helpful if you could bisect the change that caused
> this.
>
> I'm doing some other experiments first but I'll
> probably take a stab at it if things seem stable
> enough. Pine64+ has multiple problems currently.
> (It regressed some time back.)
>
> Unfortunately I do not have a known way to reproduce
> the older boot1.efi file fully. I'll have to explore
> that part to have a known-good low bound. If I'm
> lucky the first try from the general time frame will
> happen to work.
>
> Do to other issues I'm jumping from pre-INO64 to modern
> without having tracked in the middle.
>
>
> I will note that the older boot1.efi (as bootaa64.efi)
> output is different (no "Load Path:"):
>
> >> FreeBSD EFI boot block
>Loader path: /boot/loader.efi
>
>Initializing modules: ZFS UFS
>Probing 3 block devices.* done
> ZFS found no pools
> UFS found 1 partition
> Consoles: EFI console
> Command line arguments: loader.efi
> Image base: 0xb6dbb008
> EFI version: 2.05
> EFI Firmware: Das U-boot (rev 0.00)
>
> The failing one has garbage (invisible)
> text after "Load Path:".


My first guess, and it's just a shot in the dark, is that the UEFI subset
that u-boot implements doesn't implement the device path to text protocols,
so we're jumping into the middle of cloud cuckoo land and/or printing stack
trash.

This is new functionality designed to help track WTF we booted from.

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"

Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more

[Warner Losh]

On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard  wrote:

> When I attempted to use the result of:
>
> # cp -aRx /usr/obj/DESTDIRs/clang-cortexA53-installworld/boot/boot1.efi
> /mnt/EFI/BOOT/
>
> the pine64+ boot sequence got over and over
> a sequence like:
>
> U-Boot 2017.07 (Sep 06 2017 - 07:49:12 +) Allwinner Technology
>
> CPU:   Allwinner A64 (SUN50I)
> Model: Pine64+
> DRAM:  2 GiB
> MMC:   SUNXI SD/MMC: 0
> *** Warning - bad CRC, using default environment
>
> In:serial
> Out:   serial
> . . .
> >> FreeBSD EFI boot block
>Loader path: /boot/loader.efi
>
>Initializing modules: ZFS UFS
>Load Path:
> "Synchronous Abort" handler, esr 0x9604
> ELR: bdf90b30
> LR:  bdf8fb6c
> x0 :  x1 : 
> x2 : bdffc000 x3 : 4000
> x4 : b9f34d40 x5 : 
> x6 : 0015 x7 : 
> x8 : bdfa59b8 x9 : 001c
> x10: 0002 x11: 
> x12:  x13: 
> x14:  x15: 
> x16:  x17: 
> x18: b9f39df8 x19: 
> x20:  x21: 0002
> x22: b8f34c98 x23: b8f34c88
> x24: b8f34ca0 x25: 07d0
> x26: b8f34c90 x27: b8f2f198
> x28:  x29: b9f34de0
>
> Resetting CPU ...
>
> resetting ...
>

It would be super helpful if you could bisect the change that caused this.

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"

Re: FCP-100: armv7 plan

[Warner Losh]

On Sat, Sep 9, 2017 at 2:34 PM, Ian Lepore <i...@freebsd.org> wrote:

> On Sat, 2017-09-09 at 21:25 +0200, Jan Beich wrote:
> > Warner Losh <i...@bsdimp.com> writes:
> >
> > >
> > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich <jbe...@vfemail.net>
> > > wrote:
> > >
> > > >
> > > > Warner Losh <i...@bsdimp.com> 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.
>

Ah, yes. We should do that. We need that for other reasons as well. It
shouldn't be too hard, though I don't know where we get the AT_HWCAP
from to start with.


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


Totally agreed, even if it means breaking compatibility with the past.

And as important as these issues are, they are orthogonal to armv7 :)

Warner

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

[Warner Losh]

On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich <jbe...@freebsd.org> wrote:

> Warner Losh <i...@bsdimp.com> writes:
>
> > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich <jbe...@vfemail.net> wrote:
> >
> >> Warner Losh <i...@bsdimp.com> 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?


I mean we don't enumerate the list of all the processor supported things.
We default to compiling for a fairly middle of the road processor, but you
can strip that back all the way to i486, or hyper optimize for the latest
core-2 duo.

However, armv6 vs armv7 can affect the ABI in subtle ways that's it's best
to avoid by declaring the two different. One may be able to run armv6
binaries on an armv7 CPUs still, but we're not specifically guaranteeing it.

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


No, I don't mean that at all.  I mean we don't care if it is enabled or
not. It doesn't affect the ABI. The kernel knows about the extensions and
saves the context when it's in use, just like the x86 kernel saves MMX, etc
context when it's in use.

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
>

Right. that's based on the default target. gcc/clang can enable or disable
it (and a dozen other things) depending on what options you give. We don't
care. We'll run all binaries. It's up to the system integrator to mix/match
the options so they get optimal performance for their platform.

Just like on x86. If you compile for MMX and run it on 486 w/o run-time
detection, you'll get a reserved instruction fault. Same philosophy here.
We don't dictate policy for the binaries, just like on x86. However, most
of them have run-time detection to be nicer to the users than a core dump,
and most do the best thing for that CPU if they really care about
performance, but those applications that don't can just do whatever and be
fine.

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"

Re: svn commit: r322824 - in head: lib/clang share/mk usr.bin/clang

[Warner Losh]

On Fri, Aug 25, 2017 at 12:27 PM, Ed Maste  wrote:

> On 25 August 2017 at 14:07, Ryan Libby  wrote:
> > On Wed, Aug 23, 2017 at 4:30 PM, John Baldwin  wrote:
> >> Author: jhb
> >> Date: Wed Aug 23 23:30:25 2017
> >> New Revision: 322824
> >> URL: https://svnweb.freebsd.org/changeset/base/322824
> >>
> >> Log:
> >>   Improve the coverage of debug symbols for MK_DEBUG_FILES.
> >>
> ...
> > This causes llvm to emit hundreds of new warnings [1] for
> > "DWARF2 only supports one section per compilation unit"
> >
> > Are these expected?  Are they a concern?  Should we silence them?
> > Is this an upstream llvm bug [2]?
>
> I'm not sure they were "expected" but I guess are an unsurprising
> consequence of building more things with debug. In any case they're
> not a concern.
>
> It is an llvm bug (the warning really ought not be emitted for empty
> sections), but upstream is probably not too concerned as (most? all)
> other platforms are not using dwarf2.
>
> The right answer for us is likely to just stop defaulting to dwarf2
> (and specifying it via CFLAGS for kernel if necessary).
>

What's the status of kicking gdb out of the tree? If we kick it out, we can
stop doing dwarf2 and move to something more modern. Last time this issue
came up, that was the decision, pending a few issues with the gdb port
which I think John Baldwin is getting close to reaching closure on.

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"

Re: -r321371 amd64 -> powerpc64 cross build: lldb.full link fails with: c++: error: linker command failed with exit code 1, -B/usr/local/powerpc64-freebsd/bin/ in use

[Warner Losh]

On Mon, Jul 24, 2017 at 1:33 AM, Mark Millard  wrote:

> [I forgot that linking lldb historically failed on armv6
> (cortex-a7) based on the historical system binutils.]
>
> On 2017-Jul-23, at 8:51 PM, Mark Millard  wrote:
>
> > [Using WITH_LLDB= had no problem for amd64 -> TARGET_ARCH=aarch64
> > buildworld buildkernel .]
> >
> > On 2017-Jul-23, at 3:44 PM, Mark Millard  wrote:
> >
> >> [WITH_LLD= WITHOUT_LLDB= did a buildworld buildkernel
> >> just fine for TARGET_ARCH=powerpc64 .]
> >>
> >> On 2017-Jul-23, at 2:46 PM, Mark Millard  wrote:
> >>
> >>> [Shawn Webb's logfile shows an error similar to what I
> >>> report: lldb_private::AppleObjCRuntime::GetFoundationVersion()
> >>> is a problem. But his report shows other errors as well, ones
> >>> that I did not get.]
> >>>
> >>> On 2017-Jul-23, at 1:04 PM, Mark Millard 
> wrote:
> >>>
>  [The lldb problem is a:
> 
>  lldb_private::AppleObjCRuntime::GetFoundationVersion()
> 
>  reference via Cocoa.o in liblldb.a . See below.
>  Sorry that sometimes I'm having to go back and
>  later find and report more details because of
>  other things going on here. But this likely
>  will continue for some of my preliminary
>  reports.]
> 
>  On 2017-Jul-23, at 5:00 AM, Dimitry Andric  wrote:
> 
> > On 23 Jul 2017, at 11:17, Mark Millard  wrote:
> >>
> >> [Linking lldb.full via 2.28 of /usr/local/powerpc64-freebsd/bin/ld
> >> also fails with "exit code 1" (using WIHTOUT_LLD so it gets that
> >> far). I'll continue via WITHOUT_LLDB.]
> > ...
> >>
> >> Here is the lldb.full failure text:
> >>
> >> --- all_subdir_usr.bin ---
> >> --- all_subdir_usr.bin/clang/lldb ---
> >> c++: error: linker command failed with exit code 1 (use -v to see
> invocation)
> >
> > Unfortunately the actual linker errors were above these lines, so you
> > will have to look them up in the full build log (search for
> "undefined
> > symbol"), or post that somewhere off-list.
> >
> > I'm suspecting you get the same type of error Shawn's been getting
> while
> > linking lldb.  Apparently in some scenarios more object files are
> needed
> > than the minimum set I put in liblldb's Makefile.
> 
>  --- lldb.full ---
>  /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/
> usr/src/lib/clang/liblldb/liblldb.a(Cocoa.o): In function
> `lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&,
> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)':
>  /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/
> ObjC/Cocoa.cpp:(.text._ZN12lldb_private10formatters23NSNumberS
> ummaryProviderERNS_11ValueObjectERNS_6StreamERKNS_18TypeSummaryOptionsE+0x398):
> undefined reference to `lldb_private::AppleObjCRuntime::
> GetFoundationVersion()'
> >>>
> >>> The first error in Shawn Webb's logfile looks like what I report:
> >>>
> >>> error: undefined symbol: lldb_private::AppleObjCRuntime::
> GetFoundationVersion()
> >>>
> >>> via Cocoa.o in liblldb.a . See below:
> >>>
> >>> ===> usr.sbin/ancontrol (all)
> >>> /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol:
> lldb_private::AppleObjCRuntime::GetFoundationVersion()
> >> referenced by /usr/src/contrib/llvm/tools/
> lldb/source/Plugins/Language/ObjC/Cocoa.cpp
> >>Cocoa.o:(lldb_private::formatters::
> NSNumberSummaryProvider(lldb_private::ValueObject&,
> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)) in
> archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a
> >>>
> >>> After that his log showed:
> >>>
> >>> /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol:
> lldb::SBTrace::SBTrace()
> >> referenced by /usr/src/contrib/llvm/tools/
> lldb/source/API/SBProcess.cpp
> >>
> >> SBProcess.o:(lldb::SBProcess::StartTrace(lldb::SBTraceOptions&,
> lldb::SBError&)) in archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a
> >>> /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol:
> lldb::SBTrace::SetSP(std::__1::shared_ptr const&)
> >> referenced by /usr/src/contrib/llvm/tools/
> lldb/source/API/SBProcess.cpp
> >>
> >> SBProcess.o:(lldb::SBProcess::StartTrace(lldb::SBTraceOptions&,
> lldb::SBError&)) in archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a
> >>> /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol:
> lldb::SBTrace::SetTraceUID(unsigned long)
> >> referenced by /usr/src/contrib/llvm/tools/
> lldb/source/API/SBProcess.cpp
> >>
> >> SBProcess.o:(lldb::SBProcess::StartTrace(lldb::SBTraceOptions&,
> lldb::SBError&)) in archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a
> >>> c++: error: linker command failed with exit code 1 (use -v to see
> invocation)
> >>> --- lldb.full ---
> >>> *** [lldb.full] Error code 1
> >>>
> >>> make[5]: 

Re: Time to enable partial relro

[Warner Losh]

> On Aug 26, 2016, at 9:20 AM, Pedro Giffuni <p...@freebsd.org> wrote:
> 
> 
> 
> On 08/26/16 10:08, Warner Losh wrote:
>> On Fri, Aug 26, 2016 at 9:06 AM, Pedro Giffuni <p...@freebsd.org> wrote:
>>> 
>>> 
>>> On 08/26/16 10:01, Warner Losh wrote:
>>>> 
>>>> On Fri, Aug 26, 2016 at 8:36 AM, Ed Maste <ema...@freebsd.org> wrote:
>>>>> 
>>>>> On 26 August 2016 at 10:18, Warner Losh <i...@bsdimp.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> So what's the summary of why we'd want to do that? What benefit does it
>>>>>> bring?
>>>>>> Sure, other folks do it, but why?
>>>>> 
>>>>> 
>>>>> It's a relatively low cost technique to mitigate certain
>>>>> vulnerabilities. rtld needs to write to some sections during load but
>>>>> they don't need to be writeable after starting the program. relro
>>>>> reorders the output sections so that they are grouped together, and
>>>>> rtld remaps them read-only on start. This is often called "partial
>>>>> relro." I don't know of any real downside to enabling it, other than
>>>>> it could possibly break some strangely built third party software.
>>>>> It's been enabled on other platforms for quite some time though and I
>>>>> doubt we'd run into new issues.
>>>>> 
>>>>> It doesn't bring a huge benefit by itself though; the PLT is still
>>>>> writeable. Adding "-z now" to the linker invocation produces "full
>>>>> relro" which makes the PLT read-only too. It has a negative impact on
>>>>> process start-up time though.
>>>> 
>>>> 
>>>> Sounds like this has implications for all the RTLD on all our
>>>> architectures. Has this been tested across all of them?
>>>> 
>>> 
>>> It affects anything ELF yes, but AFAICT the change is platform independent.
>> 
>> That's a different answer than 'it's been tested on all platforms and
>> it's fine.'
>> 
> 
> It's the best answer I have.

I’d politely suggest that we solicit help to get a better answer.

> I will test running buildworld on i386. If you can kindly test on other 
> platforms, it would be very welcome.

I might be able to do armv6, but I have no time to do mips. The mailing lists 
for them might get results faster since I’m kinda swamped. And since the 
powerpc guys are around and active, it wouldn’t hurt to send it there too.

> In any case I will not commit anything unless there is complete
> consensus, which is why I asked in this list in the first place :).

Yea. This should be easy enough to test to make sure there’s no weird gotchas.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Time to enable partial relro

[Warner Losh]

> On Aug 26, 2016, at 9:14 AM, Pedro Giffuni <p...@freebsd.org> wrote:
> 
> Hello;
> 
> On 08/26/16 10:06, Warner Losh wrote:
>> On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni <p...@freebsd.org> wrote:
>>> 
>>> 
>>> On 08/26/16 05:56, Konstantin Belousov wrote:
>>>> 
>>>> On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote:
>>>>> 
>>>>> Hello;
>>>>> 
>>>>> GNU RELRO support was committed in r230784 (2012-01-30) but we never
>>>>> enabled it by default.
>>>>> 
>>>>> There was some discussion about it on
>>>>> https://reviews.freebsd.org/D3001
>>>>> 
>>>>> By now, all Linux distributions, NetBSD and DragonFly support it and
>>>>> it is the default for most systems in binutils 2.27.
>>>>> 
>>>>> This doesn't affect performance, I ran it through an exp-run last
>>>>> year, no other OS has had issues etc ... seems safe and can be
>>>>> disabled if needed when linking.
>>>> 
>>>> Exp-run does not test anything interesting about relro. If all testing
>>>> that was done is basically just an exp-run, then there was no useful
>>>> runtime testing done.
>>>> 
>>> 
>>> The exp-run does cover Java and other VM-type thingies that bootstrap.
>>> For upstream binutils this is now the default (at least for linux,
>>> they never ask us if we want to follow). So the change has been tested
>>> extensively but perhaps not on cases that are relevant to us.
>>> 
>>> Note that the "fix" for any port is ultimately trivial:
>>> LDFLAGS+= "-z norelro"
>>> 
>>>>> 
>>>>> I think it's time to enable it be default in our base binutils. If
>>>>> there are no objections, I will just commit the attached patch over
>>>>> the weekend.
>>>> 
>>>> 
>>>> There are objections, the change must be runtime tested on large and
>>>> representative set of real-world applications before turning the knob.
>>>> 
>>> 
>>> You are not giving any hint on what would be a "representative set of
>>> real-world applications". Given that you committed the initial support your
>>> objection stands very high and is a blocker. :(
>>> 
>>> As I see it committing it now would give ample time to test this in current
>>> before it hits any release. If you want more extensive testing merging it in
>>> -stable right after the 11-Release is guaranteed to help
>>> weed out any remaining update ports may need.
>> 
>> I'd say a minimum is 'buildworld' + a test boot on at least Intel (i386 and
>> amd64), armv6 and mips (both 32-bit and 64-bit) before we proceed. How
>> many of those have we done?
>> 
> 
> I have been running it my desktop (amd64) for a year now. I can test i386 in 
> a VM but I doubt it will affect anything. The issue, and it's probably kib's 
> worry are some rarely used but important ports. Stuff like erlang, or 
> virtualbox maybe, but as I wrote, the fix (if needed)
> is trivial by adding a flag to the link command.
> 
> FWIW, but it is largely irrelevant to us, RELRO is the default on
> OpenBSD and there is no way out of it there.

What I’m worried about is that our run time linker may get the RELRO stuff 
wrong and that’s a very platform specific thing and needs to be validated. I 
also share Kib’s worry about different ports being broken, but that’s a 
different issue. Recent compilers have broken our run time linker on mips, for 
example, because they generate new / different relocations than those before. 
It’s easy enough to test to make sure that we’re good on at least the fairly 
active platforms (i386, amd64, armv6, mips and mips64) to make sure that 
nothing bad happens. The others can be tested in due time (though the powerpc 
ones likely can be tested easily enough by the powerpc guys since they are 
quite active).

I get very nervous when I see “should work” or “should be platform independent” 
for such a low-level thing.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Time to enable partial relro

[Warner Losh]

On Fri, Aug 26, 2016 at 9:06 AM, Pedro Giffuni <p...@freebsd.org> wrote:
>
>
> On 08/26/16 10:01, Warner Losh wrote:
>>
>> On Fri, Aug 26, 2016 at 8:36 AM, Ed Maste <ema...@freebsd.org> wrote:
>>>
>>> On 26 August 2016 at 10:18, Warner Losh <i...@bsdimp.com> wrote:
>>>>
>>>>
>>>> So what's the summary of why we'd want to do that? What benefit does it
>>>> bring?
>>>> Sure, other folks do it, but why?
>>>
>>>
>>> It's a relatively low cost technique to mitigate certain
>>> vulnerabilities. rtld needs to write to some sections during load but
>>> they don't need to be writeable after starting the program. relro
>>> reorders the output sections so that they are grouped together, and
>>> rtld remaps them read-only on start. This is often called "partial
>>> relro." I don't know of any real downside to enabling it, other than
>>> it could possibly break some strangely built third party software.
>>> It's been enabled on other platforms for quite some time though and I
>>> doubt we'd run into new issues.
>>>
>>> It doesn't bring a huge benefit by itself though; the PLT is still
>>> writeable. Adding "-z now" to the linker invocation produces "full
>>> relro" which makes the PLT read-only too. It has a negative impact on
>>> process start-up time though.
>>
>>
>> Sounds like this has implications for all the RTLD on all our
>> architectures. Has this been tested across all of them?
>>
>
> It affects anything ELF yes, but AFAICT the change is platform independent.

That's a different answer than 'it's been tested on all platforms and
it's fine.'

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"

Re: Time to enable partial relro

[Warner Losh]

On Fri, Aug 26, 2016 at 8:36 AM, Ed Maste <ema...@freebsd.org> wrote:
> On 26 August 2016 at 10:18, Warner Losh <i...@bsdimp.com> wrote:
>>
>> So what's the summary of why we'd want to do that? What benefit does it 
>> bring?
>> Sure, other folks do it, but why?
>
> It's a relatively low cost technique to mitigate certain
> vulnerabilities. rtld needs to write to some sections during load but
> they don't need to be writeable after starting the program. relro
> reorders the output sections so that they are grouped together, and
> rtld remaps them read-only on start. This is often called "partial
> relro." I don't know of any real downside to enabling it, other than
> it could possibly break some strangely built third party software.
> It's been enabled on other platforms for quite some time though and I
> doubt we'd run into new issues.
>
> It doesn't bring a huge benefit by itself though; the PLT is still
> writeable. Adding "-z now" to the linker invocation produces "full
> relro" which makes the PLT read-only too. It has a negative impact on
> process start-up time though.

Sounds like this has implications for all the RTLD on all our
architectures. Has this been tested across all of them?

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"

Re: Time to enable partial relro

[Warner Losh]

On Thu, Aug 25, 2016 at 4:50 PM, Pedro Giffuni  wrote:
> Hello;
>
> GNU RELRO support was committed in r230784 (2012-01-30) but we never enabled
> it by default.

So what's the summary of why we'd want to do that? What benefit does it bring?
Sure, other folks do it, but why?

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"

Re: Update on using LLVM's lld linker in the FreeBSD base system

[Warner Losh]

>> Generally, I like it though. My concerns are mostly with ports and gcc plans.
>> Though it isn't coupled to gcc, I'd suggest that we want to have a joint plan
>> for both before we get out the axes. Note this is purely a timing argument,
>> not whether to get them out, just when :)
>
> Yes, fully agree. I want to have lld available as soon as is feasible,
> but have no intention of trying to remove old GNU ld or GCC 4.2 until
> a viable path forward exists for all architectures.

Agreed. We don't have to have a plan for removal before moving forward
on lld.

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"

Re: 11.0-CURRENT: lang/gcc, lang/gcc5, lang/gcc6-devel, lang/llvm38, etc. do not build on/for armv6 (now implicitly hard float)

[Warner Losh]

On Wed, May 25, 2016 at 10:12 AM, Mark Millard  wrote:
> I'm  not sure that Gerald or Brooks were CC'd on a report made to the arm 
> list about armv6 builds of gcc and llvm being broken now because of hard 
> float now being implicit:
> (the first report listed below has more detail directly visible for gcc 
> examples)
>
> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013931.html
> and:
> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013930.html
> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013932.html
> https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013933.html
>
> The first (013931.html) shows that xgcc for configure:3686 for contest.c ends 
> up with the likes of:
>
> /usr/local/bin/ld: error: a.out uses VFP register arguments,
> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o does not
> /usr/local/bin/ld: failed to merge target specific data of file
> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o
> /usr/local/bin/ld: error: a.out uses VFP register arguments,
> /tmp//cchNL2QG.o does not
> /usr/local/bin/ld: failed to merge target specific data of file 
> /tmp//cchNL2QG.o
> /usr/local/bin/ld: error: a.out uses VFP register arguments,
> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o does not
> /usr/local/bin/ld: failed to merge target specific data of file
> /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o
> collect2: error: ld returned 1 exit status
>
> and points to gcc/config.gcc only having TARGET_FREEBSD_ARM_HARD_FLOAT=1 for 
> arm*hf-*-freebsd* . But now armv6*-*-freebsd* is also hard float for 
> 11.0-CURRENT.

armv6*-*-freebsd is only hard float ABI for FreeBSD 11.

> Of course until everyone updates to modern enough armv6 context a mix of 
> softfloat and hardfloat will be around.

Are you saying that we need to get these changes to the ports in place
to support hard float? Are you saying we need to support a mix better
(which is unlikely to happen, btw, without a passionate champion)? Is
there some other point I'm missing?

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"

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

[Warner Losh]

On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric <d...@freebsd.org> wrote:

> On 01 Apr 2016, at 00:44, Warner Losh <i...@bsdimp.com> wrote:
> >
> >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery <bdrew...@freebsd.org>
> wrote:
> >> I didn't realize the ports compiler was defaulting /usr/local/include
> >> into the search path now.  It does not have /usr/local/lib in the
> >> default library path as far as I can tell.  It's also broken for its
> >> -rpath (noted in its pkg-message).  So having a default
> >> /usr/local/include path seems odd.
> >
> > It has for a while now. It’s one of the maddening inconsistencies that
> abound in this
> > area. I took a poll a while ago and there seemed to be widespread
> support for adding
> > it to the base compiler.
>
> This was the main reason /usr/local/include was *not* included in the
> base compiler, otherwise it would unpredictably pick up headers in
> /usr/local/include during builds.  You can never know which conflicting
> headers a certain user has installed in /usr/local/include... :)


That's why it shouldn't be *FIRST*, not why it shouldn't be there
at all.

>> Adding -isystem /usr/include to fix this is probably possible but
> >> there's a risk someone will remove it as redundant.  In this case I wish
> >> /usr/include was first but I'm not sure what impact that would have on
> >> consumers expecting /usr/local/include (and /usr/local/lib) overrides to
> >> work, though they would need to pass a -L /usr/local/lib anyhow and
> >> would likely be passing -I /usr/local/lib too.
> >
> > /usr/include should be first. But it isn’t. That’s another inconsistency
> that was found
> > when we looked at /usr/local stuff. Someone recently added
> /usr/local/bin to the path,
> > if I recall correctly.
>
> Isn't that a bit of a bikeshed?  I guess some people would just as well
> prefer /usr/local/include to be first, just like some people prefer
> /usr/local/bin before /usr/bin in their PATH.
>

Sigh. No. /usr/local is moving into many different things in the base and
ports. We should
do it in a consistent way. What we have now is not consistent and somewhat
brittle.


> In any case, if such paths are added to external compilers, we better
> make sure almost everything in buildworld uses -nostdinc, and specifying
> exactly the include directories we need, and no others.  Cumbersome, but
> maybe for a good cause.


That's the non-brittle solution here. An over-reliance on defaults makes it
difficult to ensure other compilers will work, especially ones we don't
tightly control the defaults for.

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"

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

[Warner Losh]

> On Mar 31, 2016, at 4:34 PM, Bryan Drewery  wrote:
> I didn't realize the ports compiler was defaulting /usr/local/include
> into the search path now.  It does not have /usr/local/lib in the
> default library path as far as I can tell.  It's also broken for its
> -rpath (noted in its pkg-message).  So having a default
> /usr/local/include path seems odd.

It has for a while now. It’s one of the maddening inconsistencies that abound 
in this
area. I took a poll a while ago and there seemed to be widespread support for 
adding
it to the base compiler.

> Adding -isystem /usr/include to fix this is probably possible but
> there's a risk someone will remove it as redundant.  In this case I wish
> /usr/include was first but I'm not sure what impact that would have on
> consumers expecting /usr/local/include (and /usr/local/lib) overrides to
> work, though they would need to pass a -L /usr/local/lib anyhow and
> would likely be passing -I /usr/local/lib too.

/usr/include should be first. But it isn’t. That’s another inconsistency that 
was found
when we looked at /usr/local stuff. Someone recently added /usr/local/bin to 
the path,
if I recall correctly.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CXXSTD=c++11

[Warner Losh]

> On Mar 24, 2016, at 4:36 PM, Bryan Drewery  wrote:
> 
> Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
> now?  We do this when using an external GCC since it doesn't default to
> the c++11 standard quite yet.  As far as I understand, we require c++11
> to build clang/libc++.
> 
> It seems to be the problem at
> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-October/001757.html
> which I've fixed in an upcoming commit to properly pass -std=c++11 to
> the lib32 build in CXXFLAGS.

Wouldn’t that break the spark and mips builds if we did it always? They are the
last stragglers to not have a working, fully vetted clang in the tree.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CPUTYPE=armv7-a with CPUTYPE=soft (as an example)?

[Warner Losh]

On Mar 23, 2016 9:57 PM, "Mark Millard"  wrote:
>
> Between:
>
> > Q: But what if I need to build a system with soft float ABI under 11?
> >
> > You can still do that. CPUTYPE=soft has been created for this scenario,
as well as to generate libraries for WITH_LIBSOFT. It's anticipated that
this will live for the entire FreeBSD 11 branch, but go away in FreeBSD 12.
>
> and:
>
> > share/mk/bsd.cpu.mk :
> >
> > . elif ${MACHINE_CPUARCH} == "arm"
> > .  if ${CPUTYPE} == "xscale"
> > #XXX: gcc doesn't seem to like -mcpu=xscale, and dies while rebuilding
itself
> > #_CPUCFLAGS = -mcpu=xscale
> > _CPUCFLAGS = -march=armv5te -D__XSCALE__
> > . elif ${CPUTYPE} == "armv6"
> > _CPUCFLAGS = -march=${CPUTYPE} -DARM_ARCH_6=1
> > . elif ${CPUTYPE} == "cortexa"
> > _CPUCFLAGS = -march=armv7 -DARM_ARCH_6=1 -mfpu=vfp
> > . elif ${CPUTYPE:Marmv[4567]*} != ""
> > # Handle all the armvX types that FreeBSD runs:
> > #   armv4, armv4t, armv5, armv5te, armv6, armv6t2, armv7, armv7-a,
armv7ve
> > # they require -march=. All the others require -mcpu=.
> > _CPUCFLAGS = -march=${CPUTYPE}
> > . else
> > # Common values for FreeBSD
> > # arm:
> > #   arm920t, arm926ej-s, marvell-pj4, fa526, fa626,
> > #   fa606te, fa626te, fa726te
> > # armv6:
> > #   arm1176jzf-s, generic-armv7-a, cortex-a5, cortex-a7, cortex-a8,
> > #   cortex-a9, cortex-a12, cortex-a15, cortex-a17, cortex-a53,
cortex-a57,
> > #   cortex-a72, exynos-m1
> > _CPUCFLAGS = -mcpu=${CPUTYPE}
> > . endif
>
> how will one do a armv7-a (CPUTYPE=armv7-a) soft-float ABI (CPUTYPE=soft)
system build if one cares to? (armv7-a is just a specific example of the
general issue. But someone might target a RPI2B with armv7-a specified and
also wanting the soft float ABI for some reason.)
>
> (The question is generic for me for now, I'm not out to do so at this
point or any time soon, may be never.)

Armv7-a-soft is what I planned, but haven't implemented. Today you get it
with just armv7-a.

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"

Re: How to insist on only clang, for world/kernel?

[Warner Losh]

Then you may be able to do make buildworld CC=clang (or whatever clang is
compiled as.
No guarantee, sine I've not played with 9.x in a while.

Warner


On Fri, Mar 11, 2016 at 8:20 AM, Chris H <bsd-li...@bsdforge.com> wrote:

> On Thu, 10 Mar 2016 21:49:01 -0700 Warner Losh <i...@bsdimp.com> wrote
>
> > make buildworld WITH_CLANG=t WITH_CLANG_BOOTSTRAP=t WITHOUT_GCC=y
> > WITHOUT_GCC_BOOTSTRAP=t WITH_CLANG_IS_CC=t
> > make buildkernel
> >
> > But that's mostly default these days, so really most people get what you
> > want by doing
> >
> > make buildworld buildkernel
> >
> > Warner
> Thanks for the quick reply, Warner!
> This is on RELENG_9, so I *don't* get that by default. ;)
> But true. Everything else I run in on -CURRENT, and indeed gets
> the options you indicate above out-of-the-box.
>
> Thanks again, Warner.
> >
> > On Thu, Mar 10, 2016 at 9:23 PM, Chris H <bsd-li...@bsdforge.com> wrote:
> >
> > > Greetings,
> > >  A recent build/install world/kernel on a fresh 9-STABLE.
> > > I was surprised to see that, while clang was also built,
> > > gcc was used to perform the build for at least world.
> > > I performed some research to definitively determine the
> > > magic incantation for at least src.conf(5). However, I
> > > found too many possibilities to be sure. So I'm here
> > > to beg for the answer.
> > >
> > > The most likely candidates I have so far
> > >
> > > FAVORITE_COMPILER=clang
> > > MAKE_COMPILER_TYPE=clang
> > > WITH_CLANG=true
> > > CC=clang
> > > CXX=clang++
> > > CPP=clang-cpp
> > >
> > > Thanks you.
> > >
>
> --Chris
>
> --
>
>
>
___
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: How to insist on only clang, for world/kernel?

[Warner Losh]

make buildworld WITH_CLANG=t WITH_CLANG_BOOTSTRAP=t WITHOUT_GCC=y
WITHOUT_GCC_BOOTSTRAP=t WITH_CLANG_IS_CC=t
make buildkernel

But that's mostly default these days, so really most people get what you
want by doing

make buildworld buildkernel

Warner

On Thu, Mar 10, 2016 at 9:23 PM, Chris H  wrote:

> Greetings,
>  A recent build/install world/kernel on a fresh 9-STABLE.
> I was surprised to see that, while clang was also built,
> gcc was used to perform the build for at least world.
> I performed some research to definitively determine the
> magic incantation for at least src.conf(5). However, I
> found too many possibilities to be sure. So I'm here
> to beg for the answer.
>
> The most likely candidates I have so far
>
> FAVORITE_COMPILER=clang
> MAKE_COMPILER_TYPE=clang
> WITH_CLANG=true
> CC=clang
> CXX=clang++
> CPP=clang-cpp
>
> Thanks you.
>
> --Chris
>
> --
>
>
> ___
> 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"
>
___
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: /usr/src/Makefile.inc1 vs. buildworld finding include files: a problem for some contexts?

[Warner Losh]

On Sun, Feb 14, 2016 at 12:21 PM, Mark Millard  wrote:

> Is buildworld supposed to use /usr/include's area for finding files by
> default? (I'm not talking of ${WORLDTMP}/usr/include but of just
> /usr/include.)
>

Yes, but only though the end of the bootstrap phase.


> It does use /usr/include's area for some contexts: self-hosted builds
> without a special XCC full path (e.g., an implicit TARGET_ARCH=powerpc on a
> powerpc host using gcc 4.2.1 without an explicit XCC assignment that also
> directs it to gcc 4.2.1 via a full path).
>
> /usr/src/Makefile.inc1 has the following sort of logic:
>
> > .if ${XCC:N${CCACHE_BIN}:M/*}
> . . .
> > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc
> > XCFLAGS+=   -isystem ${WORLDTMP}/usr/include -L${WORLDTMP}/usr/lib
> > XCXXFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 -std=gnu++11
> -L${WORLDTMP}/../lib/libc++
> . . .
> > .else
> . . .
> > .endif
> > XCFLAGS+=   --sysroot=${WORLDTMP} ${BFLAGS}
> > XCXXFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS}
> > .else
> > .if defined(CROSS_BINUTILS_PREFIX) && exists(${CROSS_BINUTILS_PREFIX})
> > BFLAGS+=-B${CROSS_BINUTILS_PREFIX}
> > XCFLAGS+=   ${BFLAGS}
> > XCXXFLAGS+= ${BFLAGS}
> > .endif
> > .endif # ${XCC:M/*}
>
> For contexts without the -isystem and/or --sysroot in XCFLAGS . . .
>
> Is it appropriate to submit bug reports for buildworld getting include
> files from /usr/include instead of from ${WORLDTMP} or from /usr/src areas?
>

If it is during the build everything phase, yes it is a build bug. If it is
during the bootstrap phase, then yes, it is expected we use the host, but
there's some incompatibility in bootstrapping we need to fix.


> This tends to be noticed when something like the following. . .
>
> > # svnlite update -r295453 /usr/src
> > # env __MAKE_CONF=/root/src.configs/make.conf
> SRC_ENV_CONF=/root/src.configs/src.conf.powerpc-gcc421.powerpc-host
> MAKEOBJDIRPREFIX=/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld
> buildkernel
>
> ends up with compile errors from using some older /usr/include header
> files that are no longer sufficient to allow compilation.
>
> I recently had a couple of examples where the cc command in the script
> output file for the failing compiles showed no -I , no -isystem , no
> --sysroot , nothing that would have allowed it to even potentially avoid
> /usr/include (old file) use. The Makefile*'s involved had no
> CFLAGS+=SOMETHING_DIRECTING_INCLUDE_SEARCH .
>
> (Some types of header changes might not stop a build but might make the
> build result wrong without much explicit notification. I'd prefer to avoid
> such as well.)
>
> I expect that there are analogous points/questions for finding libraries.
>

Specific examples would be most welcome.

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"

Re: make buildworld failed with error "relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini'"

[Warner Losh]

> On Jan 21, 2016, at 2:41 PM, Mark Millard  wrote:
> 
> On Thu Jan 21 13:11:03 UTC 2016 Andrew Turner andrew at fubar.geek.nz wrote"
> 
>> I've disabled setting -mlong-calls on the clang libraries for now,
>> however I expect we will need to enable it again when clang 3.8.0 is
>> imported. As such I would recommend anyone wishing to run buildworld on
>> arm to update before this is imported.
> 
> 
> It seems that folks that later progress from 10.x-??? (or before) to 
> 11.0-RELELASE at some point for arm elf-hosted buildworld activity will face 
> the issue without having the opportunity to build a -mlong-calls enabled 
> context with a smaller clang first:
> 
> BEAGLEBONE
> CUBOX-HUMMINGBOARD
> GUMSTIX
> RPI-B
> PANDABOARD
> WANDBOARD
> 
> So does the "all but clang libraries" -mlong-calls use need to be MFC'd? Even 
> this may require updating from older 10.x's to a 10.y that has those 
> -mlong-calls in place before going to 11.0-RELEASE (or later).
> 
> A similar point will be an issue for switching from such a 10.x (or before) 
> to 11.0-CURRENT once clang 3.8.0 has been imported: it may require a middle 
> stage of switching to a then-older 11.0-CURRENT first (such as -r294499).

Personally, I think we should make the dependent on the compiler version when 
we bring them back / before we MFC things.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

[Warner Losh]

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"

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?

[Warner Losh]

Thanks, it sounds like I fixed a bug, but there’s more.

What were the specific port so I can test it here?

And to be clear, this is a buildworld on the RPi 2 using the cross-built world 
with CPUTYPE=armv7a or some such, right?

Warner

> On Dec 25, 2015, at 9:32 PM, Mark Millard <mar...@dsl-only.net> wrote:
> 
> [I am again breaking off another section of older material.]
> 
> Mixed news I'm afraid.
> 
> The specific couple of ports that I attempted did build, the same ones that 
> originally got the Bus Error in ar using (indirectly) _fseeko and memset that 
> I reported. So I expect that you fixed one error.
> 
> But when I tried to buildworld, clang++ 3.7 processing 
> usr/src/lib/clang/libllvmtablegen/ materials quickly got a Bus Error at 
> nearly the same type of instruction (it has a "!" below that the earlier one 
> did not), but with r4 holding the misaligned address this time:
> 
>> --- _bootstrap-tools-lib/clang/libllvmsupport ---
>> --- APFloat.o ---
>> clang++: error: unable to execute command: Bus error (core dumped)
>> . . .
>> # gdb clang++ usr/src/lib/clang/libllvmtablegen/clang++.core
>> . . .
>> Core was generated by `clang++'.
>> Program terminated with signal 10, Bus error.
>> #0  0x00c3bb9c in 
>> clang::DependentTemplateSpecializationType::DependentTemplateSpecializationType
>>  ()
>> [New Thread 22a18000 (LWP 100128/)]
>> (gdb) x/40i 0x00c3bb60
>> . . .
>> 0xc3bb9c 
>> <_ZN5clang35DependentTemplateSpecializationTypeC2ENS_21ElaboratedTypeKeywordEPNS_19NestedNameSpecifierEPKNS_14IdentifierInfoEjPKNS_16TemplateArgumentENS_8QualTypeE+356>:
>>vst1.64   {d16-d17}, [r4]!
>> . . .
>> (gdb) info all-registers
>> r0 0xbfbf81a8-1077968472
>> r1 0x22f07e14586186260
>> r2 0xc416bc  12850876
>> r3 0x2   2
>> r4 0x22f07dfc586186236
>> . . .
> 
> 
> Thus it appears that there is more code around that likely generates pointers 
> not aligned so to allow the code generation that is in use for what is 
> pointed to.
> 
> At this point I have no clue if the issue is just inside clang itself vs. if 
> it is in something that clang is layered on top of. Nor if there is just one 
> bad thing or many.
> 
> Note: I had not yet tried buildworld/buildkernel for the context of the "-f" 
> option that I was experimenting with earlier. So I do not have a direct 
> compare and contrast at this point.
> 
> 
> 
> Older material:
> 
> On 2015-Dec-25, at 5:21 PM, Mark Millard <mar...@dsl-only.net> wrote:
> 
>> On 2015-Dec-25, at 3:42 PM, Warner Losh <i...@bsdimp.com> wrote:
>> 
>> 
>>> On Dec 25, 2015, at 3:14 PM, Mark Millard <mar...@dsl-only.net> wrote:
>>> 
>>> [I'm going to break much of the earlier "original material" text to tail of 
>>> the message.]
>>> 
>>>> On 2015-Dec-25, at 11:53 AM, Warner Losh <i...@bsdimp.com> wrote:
>>>> 
>>>> So what happens if we actually fix the underlying bug?
>>>> 
>>>> I see two ways of doing this. In findfp.c, we allocate an array of FILE * 
>>>> today like:
>>>>g = (struct glue *)malloc(sizeof(*g) + ALIGNBYTES + n * sizeof(FILE));
>>>> but that assumes that FILE just has normal pointer alignment requirements. 
>>>> However,
>>>> due to the mbstate having int64_t alignment requirements, this is wrong. 
>>>> Maybe we
>>>> need to do something like
>>>>g = (struct glue *)malloc(sizeof(*g) + max(sizeof(int64_t),ALIGNBYTES) 
>>>> + n * sizeof(FILE));
>>>> which wouldn’t change anything on LP64 systems, but would result in proper 
>>>> alignment
>>>> for ILP32 systems. We’d have to fix the loop that uses ALIGN afterwards to 
>>>> use
>>>> roundup. Instead, we’d need to round up to the neared 8-byte aligned 
>>>> offset (or technically,
>>>> the max of ALIGNBYTES and 8, but that’s always 8 on today’s systems. If we 
>>>> do this,
>>>> we can make sure that each file is 8-byte aligned or better. We may need 
>>>> to round up
>>>> sizeof(FILE) to a multiple of 8 as well. I believe that since it has the 
>>>> 8-byte alignment
>>>> for a member, its size must be a multiple of 8, but I’ve not chased that 
>>>> belief to ground.
>>>> If not, we may need another decorator (__aligned(8), I think, spelled with 
>>>> the ugly
>>>> max expression above). T

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?

[Warner Losh]

So what happens if we actually fix the underlying bug?

I see two ways of doing this. In findfp.c, we allocate an array of FILE * today 
like:
g = (struct glue *)malloc(sizeof(*g) + ALIGNBYTES + n * sizeof(FILE));
but that assumes that FILE just has normal pointer alignment requirements. 
However,
due to the mbstate having int64_t alignment requirements, this is wrong. Maybe 
we
need to do something like
g = (struct glue *)malloc(sizeof(*g) + max(sizeof(int64_t),ALIGNBYTES) 
+ n * sizeof(FILE));
which wouldn’t change anything on LP64 systems, but would result in proper 
alignment
for ILP32 systems. We’d have to fix the loop that uses ALIGN afterwards to use
roundup. Instead, we’d need to round up to the neared 8-byte aligned offset (or 
technically,
the max of ALIGNBYTES and 8, but that’s always 8 on today’s systems. If we do 
this,
we can make sure that each file is 8-byte aligned or better. We may need to 
round up
sizeof(FILE) to a multiple of 8 as well. I believe that since it has the 8-byte 
alignment
for a member, its size must be a multiple of 8, but I’ve not chased that belief 
to ground.
If not, we may need another decorator (__aligned(8), I think, spelled with the 
ugly
max expression above). That way, the contract we’re making with the compiler 
will
always be true. ALIGN BYTES is 4 on Arm anyway, so that bit is clearly wrong.

This wouldn’t be an ABI change, since you can only get a valid FILE * from 
fopen (and
friends), plus stdin, stdout, and stderr. Those addresses aren’t hard coded 
into binaries,
so even if we have to tweak the last three and deal with some ‘fake’ FILE abuse 
in libc
(which I don’t think suffers from this issue, btw, given the alignment 
requirements that would
naturally follow from something on the stack), we’d still be ahead. At least 
for all CONFORMING
implementations[*]...

TL;DR: Why not make FILE * always 8-byte aligned? The compiler options are a 
band-aide.

Warner

[*] There’s at least on popular package that has a copy of the FILE structure 
in one of its
.h files and uses that to do unnatural optimization things, but even that’s 
cool, I think,
since it never allocates a new one.

> On Dec 25, 2015, at 7:24 AM, Mark Millard  wrote:
> 
> [Good News Summary: Rebuilding buildworld/buildkernel for rpi2 11.0-CURRENT 
> 292413 from amd64 based on adding -fmax-type-align=4 has so far removed the 
> crashes during the toolchain activity: no more misaligned accesses in libc's 
> _fseeko or elsewhere.]
> 
> On 2015-Dec-25, at 12:31 AM, Mark Millard  wrote:
> 
>> On 2015-Dec-24, at 10:39 PM, Mark Millard  wrote:
>> 
>>> [I do not know if this partial crash analysis related to on-arm 
>>> clang-associated activity is good enough and appropriate to submit or not.]
>>> 
>>> The /usr/local/arm-gnueabi-freebsd/bin/ar on the rpi2b involved below came 
>>> from pkg install activity instead of port building. Used as-is.
>>> 
>>> When I just tried my first from-rpi2b builds (ports for a rpi2b), 
>>> /usr/local/arm-gnueabi-freebsd/bin/ar crashed. I believe that the following 
>>> suggests an alignment error for the type of instructions that memset for 
>>> 128 bytes was translated to (sizeof(mbstate_t)) in the code used by 
>>> /usr/local/arm-gnueabi-freebsd/bin/ar. (But I do not know how to check 
>>> SCTLR bit[1] to be directly sure that alignment was being enforced.)
>>> 
>>> The crash was a Bus error in /usr/local/arm-gnueabi-freebsd/bin/ar :
>>> 
 libtool: link: /usr/local/arm-gnueabi-freebsd/bin/ar cru 
 .libs/libgnuintl.a  bindtextdom.o dcgettext.o dgettext.o gettext.o 
 finddomain.o hash-string.o loadmsgcat.o localealias.o textdomain.o 
 l10nflist.o explodename.o dcigettext.o dcngettext.o dngettext.o ngettext.o 
 pluralx.o plural-exp.o localcharset.o threadlib.o lock.o relocatable.o 
 langprefs.o localename.o log.o printf.o setlocale.o version.o xsize.o 
 osdep.o intl-compat.o
 Bus error (core dumped)
 *** [libgnuintl.la] Error code 138
>>> 
>>> It failed in _fseeko doing a memset that turned into uses of "vst1.64   
>>> {d16-d17}, [r0]" instructions, for an address in register r0 that ended in 
>>> 0xa4, so was not aligned to 8 byte boundaries. From what I read such "VSTn 
>>> (multiple n-element structures)" that have .64 require 8 byte alignment. 
>>> The evidence of the code and register value follow.
>>> 
 # gdb /usr/local/arm-gnueabi-freebsd/bin/ar 
 /usr/obj/portswork/usr/ports/devel/gettext-tools/work/gettext-0.19.6/gettext-tools/intl/ar.core
 . . .
 #0  0x2033adcc in _fseeko (fp=0x20651dcc, offset=, 
 whence=, ltest=) at 
 /usr/src/lib/libc/stdio/fseek.c:299
 299memset(>_mbstate, 0, sizeof(mbstate_t));
 . . .
 (gdb) x/24i 0x2033adb0
 0x2033adb0 <_fseeko+836>:  vmov.i32q8, #0  ; 0x
 0x2033adb4 <_fseeko+840>:  movwr1, #65503  ; 0xffdf
 0x2033adb8 <_fseeko+844>:  

Re: clang confuses kgdb on static symbols

[Warner Losh]

> On Oct 20, 2015, at 3:07 PM, Ed Maste  wrote:
> 
> On 20 October 2015 at 16:30, Konstantin Belousov  wrote:
>> 
>> Wouldn't this cause another outburst of 'works by default' discussion
>> from some other place ?
> 
> Ok, I'll hold off on this until we make progress on the gdb retirement plan.

Have the issues with ctfconvert been fixed that caused us to go
to dwarf2 by default?

Warner




signature.asc
Description: Message signed with OpenPGP using GPGMail

[Differential] [Accepted] D3175: ar: add -U (unique) option to disable -D (deterministic) mode

[imp (Warner Losh)]

imp accepted this revision.
imp added a reviewer: imp.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D3175

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, brooks, bapt, imp
Cc: freebsd-toolchain-list
___
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

[Differential] [Commented On] D1932: Remove the non-standard CC alias for c++

[imp (Warner Losh)]

imp added a comment.

CC has been an alias for the default C++ compiler the entire life FreeBSD has 
had a C++ compiler.

Sure, it isn't based on any standards but it is a very de-facto standard that 
many ports rely on.
FreeBSD isn't the only system to do this. Sun did this for years, as did SGI, 
and many other folks
that had a C++ compiler based on cfront. IIRC CC was a shell script front end 
for cfront in at least
the cfront 2.0 and 3.0 time frame. Many ISV's compilersr picked up on this 
de-facto standard and
have been providing the link for a long time.


REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D1932

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: dim, emaste, theraven
Cc: imp, freebsd-toolchain
___
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

[Differential] [Requested Changes To] D1932: Remove the non-standard CC alias for c++

[imp (Warner Losh)]

imp requested changes to this revision.
imp added a reviewer: imp.
imp added a comment.
This revision now requires changes to proceed.

So it is icky likely isn't a good enough reason.

Do a ports run w/o it causing any problems and prove me wrong...


REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D1932

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: dim, emaste, theraven, imp
Cc: imp, freebsd-toolchain
___
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: External toolchain build failing due to missing --sysroot

[Warner Losh]

 On Mar 20, 2015, at 2:10 PM, Craig Rodrigues rodr...@freebsd.org wrote:
 
 Warner,
 
 I can't get the external toolchain build of CURRENT to work,
 because --sysroot seems to be missing in some places.

I don’t believe that this has actually never worked, or if it did appear
to work, it was only by accident. We have no ability to generate a
proper sysroot in the tree today, though we do come close at points.
Sean Bruno has been reporting issues with libgcc and external
toolchains for months, and I’ve not had the time to track those
issues to ground.

 See:
 
 https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001452.html
 
 gnn@ said you might know where this can be fixed.
 Any idea of a patch that can fix this?

No. I don’t. While I handle many of the build issues, I haven’t
been looking at this one and it is likely beyond the time I have
available at the moment.

Also, the URL resolves to file not found for the logs.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: External toolchain build failing due to missing --sysroot

[Warner Losh]

 On May 18, 2015, at 2:02 PM, Craig Rodrigues rodr...@freebsd.org wrote:
 
 On Mon, May 18, 2015 at 12:30 PM, Warner Losh i...@bsdimp.com wrote:
 
  On Mar 20, 2015, at 2:10 PM, Craig Rodrigues rodr...@freebsd.org wrote:
 
  Warner,
 
  I can't get the external toolchain build of CURRENT to work,
  because --sysroot seems to be missing in some places.
 
 I don’t believe that this has actually never worked, or if it did appear
 to work, it was only by accident. We have no ability to generate a
 proper sysroot in the tree today, though we do come close at points.
 Sean Bruno has been reporting issues with libgcc and external
 toolchains for months, and I’ve not had the time to track those
 issues to ground.
 
 It seems to work now.  See:
 https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-April/001660.html

It is quite fragile though. It looks like you are using it in one of the
configurations that work (hence my accidental comment). But working
in some configurations is better than it has been in the past...

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

[Differential] [Accepted] D2576: Update crunch bootstrapping test

[imp (Warner Losh)]

imp accepted this revision.
imp added a comment.
This revision has a positive review.

matches my memory, but I didn't verify the R numbers as correct. I assume Ed 
did, so I'm good with this in...


REVISION DETAIL
  https://reviews.freebsd.org/D2576

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, imp
Cc: freebsd-toolchain
___
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

[Differential] [Accepted] D2408: Add ELF Tool Chain's c++filt to the build

[imp (Warner Losh)]

imp added a subscriber: imp.
imp accepted this revision.
imp added a reviewer: imp.
imp added a comment.

I came to troll you for TOLO - YOLO, but brooks beat me to it...


REVISION DETAIL
  https://reviews.freebsd.org/D2408

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, brooks, imp
Cc: imp, freebsd-toolchain
___
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

[Differential] [Updated] D2305: Fix bootstraping of crunchide

[imp (Warner Losh)]

imp added a comment.

I think that we've stumbled on more stuff we can just kill :)

INLINE COMMENTS
  Makefile.inc1:1469 I'd be inclined to promote it.
  Makefile.inc1:1470 Can you tell me where in the tree we define RELEASEDIR? Is 
it still even a thing?
  
  Makefile.inc1:1475 I'd love to know why this is needed.
  
  (1) It is tiny, so building on 386 is fine, and the next line catches it.
  (2) Cross building, the next line would catch it.
  
  Makefile.inc1:1476 Not withstanding my silly nitpicking above, I think this 
whole thing can be removed.
  RELEASEDIR isn't defined anywhere
  grep -r kgzip shows this is the only place that we build it or reference it 
in the tree
  Therefore, since the witch weights the same as a duck, it is deadwood and can 
be burned.

REVISION DETAIL
  https://reviews.freebsd.org/D2305

To: rodrigc, emaste, imp
Cc: freebsd-toolchain
___
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

[Differential] [Commented On] D2305: Fix bootstraping of crunchide

[imp (Warner Losh)]

imp added inline comments.

INLINE COMMENTS
  Makefile.inc1:1476 kgzip is actually old, detritus, so I removed it in D2313.

REVISION DETAIL
  https://reviews.freebsd.org/D2305

To: rodrigc, imp, emaste
Cc: freebsd-toolchain
___
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

[Differential] [Commented On] D2305: Fix bootstraping of crunchide

[imp (Warner Losh)]

imp added inline comments.

INLINE COMMENTS
  Makefile.inc1:1470 RELEASEDIR is detritus, so I removed it in D2313. It 
hasn't been a thing since FreeBSD 9's rewrite of the release process.

REVISION DETAIL
  https://reviews.freebsd.org/D2305

To: rodrigc, imp, emaste
Cc: freebsd-toolchain
___
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: Failed to build rescue with gcc 4.9

[Warner Losh]

 On Apr 3, 2015, at 10:58 AM, Craig Rodrigues rodr...@freebsd.org wrote:
 
 On Thu, Apr 2, 2015 at 8:27 AM, Craig Rodrigues rodr...@freebsd.org wrote:
 
 
 Actually, I am building on a 10.1-RELEASE box.
 
 I was able to get this successful build:
 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/38/console
 
 by applying this  patch (the ${TARGET_ARCH} != ${MACHINE_ARCH} checks
 seemed wrong to me):
 
 Index: Makefile.inc1
 ===
 --- Makefile.inc1   (revision 280979)
 +++ Makefile.inc1   (working copy)
 @@ -1457,12 +1457,9 @@
 # we get done with the earlier stages. It is the last set of tools needed
 # to begin building the target binaries.
 #
 -.if ${TARGET_ARCH} != ${MACHINE_ARCH}
 .if ${TARGET_ARCH} == amd64 || ${TARGET_ARCH} == i386
 _btxld=usr.sbin/btxld
 .endif
 -.endif
 -.if ${TARGET_ARCH} != ${MACHINE_ARCH}
 .if ${MK_RESCUE} != no || defined(RELEASEDIR)
 _crunchide=usr.sbin/crunch/crunchide
 .endif
 @@ -1469,7 +1466,6 @@
 .if ${TARGET_ARCH} == i386  defined(RELEASEDIR)
 _kgzip=usr.sbin/kgzip
 .endif
 -.endif
 
 # If we're given an XAS, don't build binutils.
 .if ${XAS:M/*} == 
 
 
 
 I backed out this patch from my tree, and rebuilt everything
 in my 10.1-RELEASE VM from the latest CURRENT sources.  At this
 point, I ran into the same problem building rescue which I reported in
 https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001545.html
 
 I put the patch back in my tree, and recompiled everything, and the
 problem went away.
 
 To reliably build the tree, I think this patch should go in, so that these
 tools are properly bootstrapped during the build.

That shows that something in the list is needed. Likely only crunchhide.

It doesn’t tell us why we need it, or when we started needing it, or what
other conditions we might need it. This information is critical to document
so we know when we can stop doing it in the future. I’m extremely reluctant
to commit this until we know these details.

Sorry for being a bit of a pain about this, but these lists are something that
I’ll be maintaining long into the future and we’ve had issues in the past
where people would just hack something in and not document, then lovingly
copy it over and over w/o understanding :(

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Failed to build rescue with gcc 4.9

[Warner Losh]

 On Apr 2, 2015, at 8:27 AM, Craig Rodrigues rodr...@freebsd.org wrote:
 
 On Sat, Mar 28, 2015 at 2:34 PM, Craig Rodrigues rodr...@freebsd.org
 wrote:
 
 Hi,
 
 The build host VM that I used was FreeBSD 10.1-RELEASE, amd64.
 
 I took this patch for libc++ and applied it to my tree:
 
 http://reviews.llvm.org/D8461
 
 I used this script to build with gcc 4.9:
 
 
 https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh
 
 Building rescue failed.  You can see the full build log here:
 
 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/26/console
 
 The relevant section seems to be this:
 
 --- rescue ---
 /usr/local/bin/x86_64-portbld-freebsd10.0-gcc -isystem
 
 /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include
 
 -L/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/lib
 
 --sysroot=/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp
 -B/usr/local/x86_64-freebsd/bin/ -static -o rescue rescue.o cat.lo
 chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo
 expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo
 mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo
 sh.lo sleep.lo stty.lo sync.lo test.lo rcp.lo csh.lo badsect.lo
 camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo
 dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo
 gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo
 kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo
 mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo
 mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo
 ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo
 rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo
 umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo bsdlabel.lo
 fdisk.lo dhclient.lo head.lo mt.lo nc.lo sed.lo tail.lo tee.lo
 gzip.lo bzip2.lo less.lo xz.lo tar.lo vi.lo id.lo zdb.lo chroot.lo
 chown.lo
 
 /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/exec.o
 
 /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/getusershell.o
 
 /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/login_class.o
 
 /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/popen.o
 
 /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/rcmdsh.o
 
 /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/sysctl.o
 
 /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/system.o
 -lcrypt -ledit -ljail -lkvm -ll -ltermcapw -lutil -lxo -lalias -lcam
 -lncursesw -ldevstat -lipsec -llzma -lavl -lzpool -lzfs_core -lzfs
 -lnvpair -lpthread -luutil -lumem -lgeom -lbsdxml -lkiconv -lmt
 -lsbuf -lufs -lz -lbz2 -larchive -lcrypto -lmd -lm cat.lo: file not
 recognized: File truncated collect2: error: ld returned 1 exit
 status *** [rescue] Error code 1
 
 make[5]: stopped in
 
 /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue
 1 error
 
 
 I double checked.  cat.lo is not a truncated file.
 # ls -l cat.lo ; file cat.lo
 -rw-r--r--  1 jenkins  wheel  13112 Mar 28 21:17 cat.lo
 cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), stripped
 
 Any ideas?
 --
 Craig
 
 
 
 On Tue, Mar 31, 2015 at 1:41 PM, Dimitry Andric d...@freebsd.org wrote:
 
 
 I'm suspecting this might have something to do with crunchide, or least,
 the copy of crunchide that is run for this:
 
 --- cat.lo ---
 /usr/local/x86_64-freebsd/bin/ld -dc -r -o cat.lo cat_stub.o
 /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue//builds/FreeBSD_HEAD_external_toolchain_gcc/bin/cat/cat.o
 crunchide -k _crunched_cat_stub cat.lo
 
 If I look at my own build logs, it seems to pick the crunchide
 executable in /usr/bin, and Makefile.inc1 does *not* build it during the
 cross-tools stage if ${TARGET_ARCH} is the same as ${MACHINE_ARCH}:
 
 .if ${TARGET_ARCH} != ${MACHINE_ARCH}
 .if ${MK_RESCUE} != no || defined(RELEASEDIR)
 _crunchide= usr.sbin/crunch/crunchide
 .endif
 
 However, this does not explain why my /usr/bin/crunchide seems to not
 screw up cat.lo, while yours does.  As far as I can see, we're both
 building this on a stable/10 amd64 box...
 
 Maybe, as a hack, you can force cross-tools to build crunchide, by
 patching Makefile.inc1 to ignore the arch check, and see what that
 results in?
 
 
 Actually, I am 

Re: Shorter report: powerpc64-xtoolchain-gcc use fails from powerpc (non-64)

[Warner Losh]

 On Apr 1, 2015, at 4:37 PM, Mark Millard mar...@dsl-only.net wrote:
 
 
 On 2015-Apr-1, at 02:49 PM, Warner Losh imp at bsdimp.com wrote:
 
 
 On Apr 1, 2015, at 2:44 PM, Mark Millard mar...@dsl-only.net wrote:
 
 Attempting to use CROSS_TOOLCHAIN=powerpc64-gcc on powerpc (non-64) 
 11.0-CURRENT with TARGET_ARCH=powerpc64 gets:
 
 --- crti.o ---
 gcc -O2 -pipe   -I/usr/srcC/lib/csu/powerpc64/../common  
 -I/usr/srcC/lib/csu/powerpc64/../../libc/include  -mlongcall -std=gnu99  
 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
 -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
 -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
 -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls 
 -Wold-style-definition -Wno-pointer-sign-c 
 /usr/srcC/lib/csu/powerpc64/crti.S
 ...
 /usr/srcC/lib/csu/powerpc64/crti.S: Assembler messages:
 /usr/srcC/lib/csu/powerpc64/crti.S:35: Error: junk at end of line, first 
 unrecognized character is `@'
 /usr/srcC/lib/csu/powerpc64/crti.S:51: Error: junk at end of line, first 
 unrecognized character is `@'
 *** [crti.o] Error code 1
 
 
 
 
 Read below only for analysis.
 
 
 
 First I'll deal with the error messages. Then I'll deal with the gcc.
 
 The lines of crti.S in question are:
 
.quad   .L._init,.TOC.@tocbase,0
 ...
.quad   .L._fini,.TOC.@tocbase,0
 
 The error messages are because __powerpc64__ is not defined when 
 machine/asm.h is included so the wrong definition is used for _ENTRY(…):
 
 The gcc port needs to be fixed, with changes fed upstream.
 
 The head/lib/csu/powerpc64/Makefile generated gcc as the command (see 
 above). That in turn ended up as using: /usr/bin/gcc , which is the FreeBSD 
 4.2.1 system gcc.
 
 So no port was involved. That may be the (or a) problem: ${XCC} was not being 
 used.

That’s an interesting hole. It should be.

 #ifdef __powerpc64__
 ...
 #define _ENTRY(name) \
 .section .text; \
 .p2align 2; \
 .globl  name; \
 .section .opd,aw; \
 .p2align 3; \
 name: \
 .quad   DOT_LABEL(name),.TOC.@tocbase,0; \
 .previous; \
 .p2align 4; \
 TYPE_ENTRY(name) \
 DOT_LABEL(name):
 ...
 #else /* !__powerpc64__ */
 #define _ENTRY(name) \
 .text; \
 .p2align 4; \
 .globl  name; \
 .type   name,@function; \
 name:
 #define _END(name)
 #endif /* __powerpc64__ */
 
 The (powerpc64 specific) Makefile may need to force a 64-bit usage (-m64 
 ?), presuming that such is supported from the 32 bit environment.
 
 Generally, we’ve not added those kinds of flags to the command line. There’s 
 many subtle issues in the tree trying to do that…
 
 Warner
 
 From a powerpc (non-64) 11.0-CURRENT boot is the following supposed to work 
 by producing a powerpc64 appropriate result (no CROSS_TOOLCHAIN for this 
 question)?
 
 make buildworld buildkernel KERNCONF=GENERIC64 TARGET=powerpc 
 TARGET_ARCH=powerpc64

This should work, modulo broken compilers.

 The standard v4.2.1 /usr/bin/gcc in a powerpc context (non-64) for that make 
 command would produce files for TARGET_ARCH=powerpc unless the command lines 
 specified otherwise.

Ah, so it is a ‘cross build’ situation...

 Notably the build environment is picking powerpc64 specific paths when 
 appropriate, such as:
 
 lib/csu/powerpc64/Makefile
 
 so that specific Makefile is not likely to be used when powerpc64 handling is 
 inappropriate, even executed from from a powerpc (non-64) context. A 
 different path (and so a distinct Makefile) would be used for 
 KERNCONF=GENERIC TARGET_ARCH=powerpc .

The hack in that Makefile likely needs to be revisited.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Kernel compilation failures with gcc 4.9

[Warner Losh]

 On Mar 31, 2015, at 4:53 PM, Rui Paulo rpa...@me.com wrote:
 
 On Mar 31, 2015, at 14:04, Craig Rodrigues rodr...@freebsd.org wrote:
 
 Hi,
 
 I put this in make.conf:
 
 NO_WERROR=yes
 WERROR=
 WITHOUT_BOOT=yes
 WITHOUT_RESCUE=yes
 
 and used this script to build:
 https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh
 
 I managed to build a lot of stuff, but then got build failures
 in the aesni part of the kernel build.
 
 See the full build log here:
 https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/30/console
 
 I think this is the error:
 
 In file included from
 /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/mm_malloc.h:27:0,
from
 /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/xmmintrin.h:34,
from
 /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/emmintrin.h:31,
from
 /usr/local/lib/gcc/x86_64-portbld-freebsd10.0/4.9.1/include/wmmintrin.h:31,
from
 /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/modules/aesni/../../crypto/aesni/aesni_ghash.c:74:
 /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/stdlib.h:93:7:
 error: conflicting types for 'free' void  free(void *);
 
  ^
 In file included from
 /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/crypto/aesni/aesni.h:33:0,
from
 /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/modules/aesni/../../crypto/aesni/aesni_ghash.c:69:
 /builds/FreeBSD_HEAD_external_toolchain_gcc/sys/sys/malloc.h:177:6: note:
 previous declaration of 'free' was here
 void free(void *addr, struct malloc_type *type);
 
 It shouldn't be using the stdlib when it's built with -ffreestanding or 
 -nostdlib.  Can you make sure?

The AES stuff breaks the rules, and this is a consequence of it :( That stuff 
should be fixed.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Fails to build sys/i386/boot2 with gcc 4.9

[Warner Losh]

 On Mar 29, 2015, at 6:37 PM, Garrett Cooper yaneurab...@gmail.com wrote:
 
 
 On Mar 29, 2015, at 15:56, Warner Losh i...@bsdimp.com wrote:
 
 On Mar 29, 2015, at 2:29 PM, Craig Rodrigues rodr...@freebsd.org wrote:
 
 On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh i...@bsdimp.com wrote:
 
 If we built a UFS1-only boot2, that would fit in the 7.5k we have left
 to play with. We could then build a UFS2-only boot2 that would easily
 fit in the like 32k limit that UFS2 has.
 
 The only reason we went to supporting both was to have something
 universal. Since it requires a reformat to go from UFS1 - UFS2 we
 wanted the transition to be as smooth as possible so you didn’t have
 to add boot blocks into the mix.
 
 Now the only people that use UFS1 are people with really old systems
 that are never going to upgrade, or people building new systems with
 UFS1 because they are space constrained (for whatever reasons that
 we’re not going to debate here: they are still real).
 
 In the past 5 years, I have worked on some embedded systems where UFS1 was 
 chosen because of very low memory and disk space requirements.
 So those systems are real and out there.
 
 Just out of curiousity, what is it about newer compilers that cause
 the size of boot2 to increase so much?
 
 Could we do some silly things like removing/reducing the use of printf()
 to save some more bytes, in order to buy us more time, before having
 to rewrite everything? :)
 
 Removing printf isn’t going to save us. It usually compiles to 80-120 bytes.
 
 I think the only sane way forward is boot2.ufs1 an boot2.ufs2 plus maybe
 some safety belts in the boot block splatter programs to prevent
 brickification.
 
 Since the proposal to split up the code by filesystems is on the table, would 
 it make sense to do something similar for zfs?
 Thanks!

zfs isn’t in boot2 by default, just ufs1 and ufs2, so I on’t understand the 
question.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Fails to build sys/i386/boot2 with gcc 4.9

[Warner Losh]

 On Mar 29, 2015, at 2:27 AM, Roman Divacky rdiva...@freebsd.org wrote:
 
 I used this script to build with gcc 4.9:
 
 https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh
 
 Buildling sys/i386/boot2 failed:
 ...
 output: fmt=bin size=21ef text=200 data=1fef org=0 entry=0
 -1007 bytes available
 *** Error code 1
 
 Oof, this is going to be hard to fix.  For some reason, boot2 is one of
 those programs that keeps getting worse (i.e. larger) with *each* new
 compiler version, be it gcc or clang!
 
 The last few times when we imported a new clang version, we had to jump
 through several hoops, and attempted to shrink the code again with
 various cleanups.  Even then, we don't have a lot of headroom.
 
 If it is now also becoming a problem with gcc 4.9, we should really
 start looking for a more permanent solution, e.g.:
 * Getting rid of the 7680 byte limit (seems to be impossible?)
 * Rewrite most of (or all of) boot2 in assembly
 
 We can also get rid of UFS1 support... That shrinks the code a lot.

No we can’t. And that’s kinda the useless decision to make if you look
at where the 8k limit comes from.

UFS1 imposes the 8k limit. UFS2 has no such limit, but there’s some
issues with some old installs listing 8k as the size to fit into the disklabel
reserves of the time.

If we built a UFS1-only boot2, that would fit in the 7.5k we have left
to play with. We could then build a UFS2-only boot2 that would easily
fit in the like 32k limit that UFS2 has.

The only reason we went to supporting both was to have something
universal. Since it requires a reformat to go from UFS1 - UFS2 we
wanted the transition to be as smooth as possible so you didn’t have
to add boot blocks into the mix.

Now the only people that use UFS1 are people with really old systems
that are never going to upgrade, or people building new systems with
UFS1 because they are space constrained (for whatever reasons that
we’re not going to debate here: they are still real).

All typical installs are UFS2.

As such, with a bit of automation in our boot block writing, and we should
be in good shape.

So no, we can’t get rid of UFS1 support and have all our problems be
solved. However, we likely can solve most of the issues by moving away
from a single image.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Fails to build sys/i386/boot2 with gcc 4.9

[Warner Losh]

 On Mar 29, 2015, at 2:29 PM, Craig Rodrigues rodr...@freebsd.org wrote:
 
 On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh i...@bsdimp.com wrote:
 
 If we built a UFS1-only boot2, that would fit in the 7.5k we have left
 to play with. We could then build a UFS2-only boot2 that would easily
 fit in the like 32k limit that UFS2 has.
 
 The only reason we went to supporting both was to have something
 universal. Since it requires a reformat to go from UFS1 - UFS2 we
 wanted the transition to be as smooth as possible so you didn’t have
 to add boot blocks into the mix.
 
 Now the only people that use UFS1 are people with really old systems
 that are never going to upgrade, or people building new systems with
 UFS1 because they are space constrained (for whatever reasons that
 we’re not going to debate here: they are still real).
 
 In the past 5 years, I have worked on some embedded systems where UFS1 was 
 chosen because of very low memory and disk space requirements.
 So those systems are real and out there.
 
 Just out of curiousity, what is it about newer compilers that cause
 the size of boot2 to increase so much?
 
 Could we do some silly things like removing/reducing the use of printf()
 to save some more bytes, in order to buy us more time, before having
 to rewrite everything? :)

Removing printf isn’t going to save us. It usually compiles to 80-120 bytes.

I think the only sane way forward is boot2.ufs1 an boot2.ufs2 plus maybe
some safety belts in the boot block splatter programs to prevent
brickification.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

[Differential] [Accepted] D2156: Switch to ELF toolchain readelf

[imp (Warner Losh)]

imp accepted this revision.
imp added a comment.
This revision is now accepted and ready to land.

Looks good

REVISION DETAIL
  https://reviews.freebsd.org/D2156

To: emaste, imp
Cc: freebsd-toolchain
___
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: Failed to build with external toolchain

[Warner Losh]

 On Mar 24, 2015, at 9:18 PM, Craig Rodrigues rodr...@freebsd.org wrote:
 
 On Sat, Mar 7, 2015 at 3:48 PM, Dimitry Andric d...@freebsd.org wrote:
 
 On 07 Mar 2015, at 21:12, Craig Rodrigues rodr...@freebsd.org wrote:
 I ran the build again and this time I am getting errors about undefined
 symbol utimensat():
 
 
 https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/14/console
 
 Any ideas?
 
 It's linking against the wrong libc, the one from the FreeBSD-10 host
 system, which does not have utimensat():
 
 --- cp ---
 /usr/local/bin/x86_64-portbld-freebsd10.0-gcc -isystem
 /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include
 -L/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/lib
 -O2 -pipe   -DVM_AND_BUFFER_CACHE_SYNCHRONIZED -D_ACL_PRIVATE -std=gnu99
 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W
 -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
 -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
 -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
 -Wredundant-decls -Wold-style-definition -Wno-pointer-sign-o cp cp.o
 utils.o
 [...]
 utils.o: In function `setfile':
 utils.c:(.text+0x83): undefined reference to `utimensat'
 utils.c:(.text+0x1ce): undefined reference to `utimensat'
 utils.c:(.text+0x38c): undefined reference to `utimensat'
 collect2: error: ld returned 1 exit status
 
 There should probably be a --sysroot flag in there, pointing to the
 ${WORLDTMP} built during the earlier stages.
 
 For some reason, this flag is not added for gcc, in Makefile.inc1.  No
 idea why that was done.
 
 -Dimitry
 
 I eliminated the problem with this patch:
 
 Index: Makefile.inc1
 ===
 --- Makefile.inc1   (revision 280353)
 +++ Makefile.inc1   (working copy)
 @@ -381,9 +381,9 @@
 TARGET_ABI?=   unknown
 TARGET_TRIPLE?=
 ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd11.0
 XCFLAGS+=  -target ${TARGET_TRIPLE}
 +.endif
 XCFLAGS+=  --sysroot=${WORLDTMP} ${BFLAGS}
 XCXXFLAGS+=--sysroot=${WORLDTMP} ${BFLAGS}
 -.endif
 .else
 .if defined(CROSS_BINUTILS_PREFIX)  exists(${CROSS_BINUTILS_PREFIX})
 BFLAGS+=   -B${CROSS_BINUTILS_PREFIX}
 
 
 This sets --sysroot when doing CROSS_TOOLCHAIN for both clang *or* gcc.
 Right now,  --sysroot is only set for clang.
 
 I did a make universe and make buildworld
 CROSS_TOOLCHAIN_PREFIX=/usr/bin/
 
 Is it OK if I commit it?

No. The in-tree gcc doesn’t grok —sysroot.

We assume that version gcc 4.2.1 is special and our in-tree compiler elsewhere,
so please add a check for that and just go ahead and duplicate those two lines.

Eg

+.else if ${COMPILER_VERSION}  40201
+XCFLAGS+=  --sysroot=${WORLDTMP} ${BFLAGS}
+XCXXFLAGS+=--sysroot=${WORLDTMP} ${BFLAGS}
.endif

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists

[Warner Losh]

 On Mar 16, 2015, at 7:02 PM, Dimitry Andric d...@freebsd.org wrote:
 
 On 16 Mar 2015, at 09:02, Mark Millard mar...@dsl-only.net wrote:
 
 I found why gcc 4.2.1's cc1plus was getting -std=c++11 for the 
 CROSS_TOOLCHAIN=powerpc64-gcc compiles that involve WITH_CLANG= . 
 (WITHOUT_CLANG= does not get the unrecognized notices.) There is a global 
 assignment to CXXFLAGS for all compilers whenever clang.build.mk is in use 
 (showing my experimental change...):
 
 # svnlite diff /usr/srcC/lib/clang/clang.build.mk
 Index: /usr/srcC/lib/clang/clang.build.mk
 ===
 --- /usr/srcC/lib/clang/clang.build.mk   (revision 279514)
 +++ /usr/srcC/lib/clang/clang.build.mk   (working copy)
 @@ -34,8 +34,8 @@
 CFLAGS+= -DLLVM_DEFAULT_TARGET_TRIPLE=\${TARGET_TRIPLE}\ \
  -DLLVM_HOST_TRIPLE=\${BUILD_TRIPLE}\ \
  -DDEFAULT_SYSROOT=\${TOOLS_PREFIX}\
 -CXXFLAGS+=  -std=c++11 -fno-exceptions -fno-rtti
 -CXXFLAGS.clang+= -stdlib=libc++
 +CXXFLAGS+=  -fno-exceptions -fno-rtti
 +CXXFLAGS.clang+= -std=c++11 -stdlib=libc++
 
 .PATH:   ${LLVM_SRCS}/${SRCDIR}
 
 It may be that the -fno-exceptions -fno-rtti are also suspect for being 
 not limited to clang contexts.
 
 This is incorrect.  Clang needs -std=c++11, otherwise it cannot compile.
 
 I suspect you also need WITHOUT_CLANG_BOOTSTRAP (and WITHOUT_GCC_BOOTSTRAP, 
 probably).

From earlier debugging, I’m pretty sure that the wrong g++ is being used in the 
CROSS_TOOLCHAIN case. I’m in Japan right now on travel, so I haven’t been able 
to track it down. WITHOUT_GCC_BOOTSTRAP should be implied in that case, but if 
not, that might explain why...

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists

[Warner Losh]

Thanks Mark. :(

Is cc1plus the g++ compiler that is installed on your bootstrapped system, or 
is it the one that the powerpc64-gcc toolchain built? cc1plus -v will help 
determine that. You may have to find it on your system (there’s likely 2) and 
pass it the -std=c++11 option to see which of them fail. We may have a leak / 
problem with mkdep that your unique setup is revealing.

Warner



 On Mar 13, 2015, at 5:42 AM, Mark Millard mar...@dsl-only.net wrote:
 
 Warner L. wrote about my attempt to use rpc64-xtoolchain-gcc/powerpc64-gcc in 
 a powerpc (non-64) context that has no clang built:
 
 Trying WITH_CLANG=t ...
 
 So I did...
 
 make WITH_CLANG=t CROSS_TOOLCHAIN=powerpc64-gcc toolchain 
 KERNCONF=GENERICvtsc TARGET=powerpc TARGET_ARCH=powerpc
 
 This results in a different failure (cc1plus not understanding the -std=c++11 
 option that it ends up being given):
 
 --
 stage 1.2: bootstrap tools
 --
 ...
 mkdep -f .depend -a
 -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include 
 -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include 
 -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. 
 -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
  -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
 -D__STDC_CONSTANT_MACROS 
 -DLLVM_DEFAULT_TARGET_TRIPLE=\powerpc-unknown-freebsd11.0\ 
 -DLLVM_HOST_TRIPLE=\powerpc-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ 
 -I/usr/obj/usr/src/tmp/legacy/usr/include  -std=c++11  
 /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp
 ... OMITTING MANY .cpp's ... 
 /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_ostream.cpp
 cc1plus: error: unrecognized command line option -std=c++11
 cc1plus: error: unrecognized command line option -std=c++11
 cc1plus: error: unrecognized command line option -std=c++11
 ...
 
 ===
 Mark Millard
 markmi at dsl-only.net
 
 On 2015-Mar-12, at 01:24 PM, Warner Losh imp at bsdimp.com wrote:
 
 Sorry to top post, but try adding WITH_CLANG=t
 
 Warner
 
 On Mar 13, 2015, at 4:18 AM, Mark Millard mar...@dsl-only.net wrote:
 
 Basic context:
 
 $ freebsd-version -ku; uname -a
 11.0-CURRENT
 11.0-CURRENT
 FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon Mar  9 
 22:24:27 PDT 2015 
 root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG  powerpc
 $ svnlite info
 Path: .
 Working Copy Root Path: /usr/ports
 URL: https://svn0.us-west.freebsd.org/ports/head
 Relative URL: ^/head
 Repository Root: https://svn0.us-west.freebsd.org/ports
 Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
 Revision: 380683
 Node Kind: directory
 Schedule: normal
 Last Changed Author: demon
 Last Changed Rev: 380683
 Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015)
 
 I bootstrapped into 11.0-CURRENT from 10.1-STABLE but misunderstood UPDATING 
 for the combination of starting from 10.1 on powerpc/powerpc64 and ended up 
 without clang for both powerpc and powerpc64 before I figure that out.
 
 While powerpc64-gcc (and so powerpc64-xtoolchain-gcc) fails to build when 
 portmaster'd on powerpc64 it does build on powerpc.
 
 So I portmaster'd powerpc64-xtoolchain-gcc in the powerpc (non-64) 
 11.0-CURRENT context to attempt a cross compile back to powerpc...
 
 
 
 The problem:
 (Or is the below attempt a form of abuse of powerpc64-xtoolchain-gcc?)
 (Remember: no clang exists beforehand.)
 
 For...
 
 make CROSS_TOOLCHAIN=powerpc64-gcc toolchain KERNCONF=GENERICvtsc 
 TARGET=powerpc TARGET_ARCH=powerpc
 
 or
 
 make CROSS_TOOLCHAIN=powerpc64-gcc buildworld buildkernel 
 KERNCONF=GENERICvtsc TARGET=powerpc TARGET_ARCH=powerpc
 
 Either way the result fails to complete by attempting to use clang-tblgen 
 when it does not exist (yet?):
 
 ...
 --
 stage 1.2: bootstrap tools
 --
 ...
 === lib/clang/libllvmx86instprinter (buildincludes)
 === lib/clang/libllvmx86utils (buildincludes)
 === lib/clang/include (buildincludes)
 clang-tblgen -gen-arm-neon  -d arm_neon.d -o arm_neon.h  
 /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/include/clang/Basic/arm_neon.td
 make[6]: exec(clang-tblgen) failed (No such file or directory)
 *** Error code 1
 
 Stop.
 make[6]: stopped in /usr/src/lib/clang/include
 *** Error code 1
 
 Stop.
 make[5]: stopped in /usr/src/lib/clang
 *** Error code 1
 
 Stop.
 make[4]: stopped in /usr/src/lib
 *** Error code 1
 
 Stop.
 make[3]: stopped in /usr/src/lib
 *** Error code 1
 
 Stop.
 make[2]: stopped in /usr/src
 *** Error code 1
 
 Stop.
 make[1]: stopped in /usr/src
 *** Error code 1
 
 Stop.
 make: stopped in /usr/src
 
 
 
 Even if overall this style of bootstrap should not work it seems odd to me 
 that clang

Re: powerpc/powerpc64 11.0-CURRENT not building clang by default: src.opt.mk not equivalent to 10.1-STABLE bsd.own.mk on the issue

[Warner Losh]

 On Mar 12, 2015, at 6:36 PM, Mark Millard mar...@dsl-only.net wrote:
 
 Basic context for the observation (powerpc64 example):
 
 # freebsd-version -ku; uname -a
 11.0-CURRENT
 11.0-CURRENT
 FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 
 19:23:14 PDT 2015 
 root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG  
 powerpc
 
 
 As COMPILER_FEATURES context first I note that bsd.compiler.mk uses the 
 rule...
 
 .if ${COMPILER_TYPE} == clang || \
(${COMPILER_TYPE} == gcc  ${COMPILER_VERSION} = 40800)
 COMPILER_FEATURES=  c++11
 .else
 COMPILER_FEATURES=
 .endif
 
 So powerpc/powerpc64 ends up with COMPILER_FEATURES being empty unless 
 COMPILER_TYPE has been forced to be clang or ${CC} already is clang based.
 
 But src.opts.mk will never indicate to build clang when 
 !${COMPILER_FEATURES:Mc++11} : that logic has priority over things like 
 ${__T:Mpowerpc*} tests…

Clang can only be built by a new gcc or clang. Old gcc can’t build it, so if 
you don’t have a new gcc, you can’t build clang. The default compiler was gcc 
on 10.1. There likely should be an UPDATING entry to make this clear.

Warner


 .include bsd.compiler.mk
 .if !${COMPILER_FEATURES:Mc++11}
 # If the compiler is not C++11 capable, disable clang and use gcc instead.
 __DEFAULT_YES_OPTIONS+=GCC GCC_BOOTSTRAP GNUCXX
 __DEFAULT_NO_OPTIONS+=CLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC
 .elif ${__T} == amd64 || ${__T} == i386
 # On x86, clang is enabled, and will be installed as the default cc.
 __DEFAULT_YES_OPTIONS+=CLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC
 __DEFAULT_NO_OPTIONS+=GCC GCC_BOOTSTRAP GNUCXX
 .elif ${__TT} == arm  ${__T:Marm*eb*} == 
 # On little-endian arm, clang is enabled, and it is installed as the default
 # cc, but since gcc is unable to build the full clang, disable it by default.
 __DEFAULT_YES_OPTIONS+=CLANG CLANG_BOOTSTRAP CLANG_IS_CC
 __DEFAULT_NO_OPTIONS+=CLANG_FULL GCC GCC_BOOTSTRAP GNUCXX
 .elif ${__T:Mpowerpc*}
 # On powerpc, clang is enabled, but gcc is installed as the default cc.
 __DEFAULT_YES_OPTIONS+=CLANG CLANG_FULL GCC GCC_BOOTSTRAP GNUCXX
 __DEFAULT_NO_OPTIONS+=CLANG_BOOTSTRAP CLANG_IS_CC
 .else
 # Everything else disables clang, and uses gcc instead.
 __DEFAULT_YES_OPTIONS+=GCC GCC_BOOTSTRAP GNUCXX
 __DEFAULT_NO_OPTIONS+=CLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC
 .endif
 
 
 
 By contrast the old bsd.own.mk logic from 10.1-STABLE did not depend on 
 testing !${COMPILER_FEATURES:Mc++11} (or analogous) before deciding for 
 powerpc/powerpc64...
 
 # Clang is only for x86, powerpc and little-endian arm right now, by default.
 .if ${__T} == amd64 || ${__T} == i386 || ${__T:Mpowerpc*}
 __DEFAULT_YES_OPTIONS+=CLANG CLANG_FULL
 .elif ${__T} == arm || ${__T} == armv6
 __DEFAULT_YES_OPTIONS+=CLANG
 # GCC is unable to build the full clang on arm, disable it by default.
 __DEFAULT_NO_OPTIONS+=CLANG_FULL
 .else
 __DEFAULT_NO_OPTIONS+=CLANG CLANG_FULL
 .endif
 # Clang the default system compiler only on little-endian arm and x86.
 .if ${__T} == amd64 || ${__T} == arm || ${__T} == armv6 || \
${__T} == i386
 __DEFAULT_YES_OPTIONS+=CLANG_IS_CC
 # The pc98 bootloader requires gcc to build and so we must leave gcc enabled
 # for pc98 for now.
 .if ${__TT} == pc98
 __DEFAULT_NO_OPTIONS+=GNUCXX
 __DEFAULT_YES_OPTIONS+=GCC
 .else
 __DEFAULT_NO_OPTIONS+=GCC GNUCXX
 .endif
 .else
 # If clang is not cc, then build gcc by default
 __DEFAULT_NO_OPTIONS+=CLANG_IS_CC
 __DEFAULT_YES_OPTIONS+=GCC
 # And if g++ is c++, build the rest of the GNU C++ stack
 .if defined(WITHOUT_CXX)
 __DEFAULT_NO_OPTIONS+=GNUCXX
 .else
 __DEFAULT_YES_OPTIONS+=GNUCXX
 .endif
 .endif
 
 
 ===
 Mark Millard
 markmi at dsl-only.net
 
 ___
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail

[Differential] [Accepted] D2003: Do not strip crunched binary; it will be done by install

[imp (Warner Losh)]

imp accepted this revision.
imp added a comment.
This revision is now accepted and ready to land.

Looks good to me.

REVISION DETAIL
  https://reviews.freebsd.org/D2003

To: emaste, andrew, imp
Cc: freebsd-toolchain
___
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

[Differential] [Accepted] D1819: libdwarf: Handle .rel relocations

[imp (Warner Losh)]

imp accepted this revision.
imp added a reviewer: imp.

REVISION DETAIL
  https://reviews.freebsd.org/D1819

To: emaste, br, rpaulo, gnn, imp
Cc: rpaulo, freebsd-toolchain
___
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: Resurrecting clang external toolchain support in Makefile.inc

[Warner Losh]

 On Feb 11, 2015, at 5:02 PM, Peter Grehan gre...@freebsd.org wrote:
 
 Hi Bapt,
 
 In my opinion we should track down the last traces of XFLAGS and turn them 
 into
 proper XCFLAGS and XCXXFLAGS, the intent was to get rid of XFLAGS because the
 name was confusing.
 
 so instead of adding XFLAGS to XC*FLAGS, the XFLAGS should juste be converted
 into XC*FLAGS directly in my opinion.
 
 How about the appended ? It moves the sysroot definition into the non-GCC 
 XC/XCXXFLAGS defs, and renames XFLAGS to BFLAGS. This should be identical to 
 pre r273755 behaviour.
 
 later,
 
 Peter.
 
 --- Makefile.inc1 (revision 278542)
 +++ Makefile.inc1 (working copy)
 @@ -348,16 +348,15 @@
   SIZE=${XSIZE}
 
 .if ${XCC:M/*}
 -XFLAGS=  --sysroot=${WORLDTMP}
 .if defined(CROSS_BINUTILS_PREFIX)
 # In the case of xdev-build tools, CROSS_BINUTILS_PREFIX won't be a
 # directory, but the compiler will look in the right place for it's
 # tools so we don't need to tell it where to look.
 .if exists(${CROSS_BINUTILS_PREFIX})
 -XFLAGS+= -B${CROSS_BINUTILS_PREFIX}
 +BFLAGS+= -B${CROSS_BINUTILS_PREFIX}
 .endif
 .else
 -XFLAGS+= -B${WORLDTMP}/usr/bin
 +BFLAGS+= -B${WORLDTMP}/usr/bin
 .endif
 .if ${TARGET} == arm
 .if ${TARGET_ARCH:M*hf*} != 
 @@ -374,6 +373,8 @@
 TARGET_ABI?=  unknown
 TARGET_TRIPLE?=   ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd11.0
 XCFLAGS+= -target ${TARGET_TRIPLE}
 +XCFLAGS+=--sysroot=${WORLDTMP} ${BFLAGS}
 +XCXXFLAGS+=  --sysroot=${WORLDTMP} ${BFLAGS}
 .endif
 .endif

I like this patch better than the one I have. I’m not 100% sure the ‘else’ 
clause will work, but it is certainly better than we have today.

Warner

___
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: Resurrecting clang external toolchain support in Makefile.inc

[Warner Losh]

 On Feb 11, 2015, at 7:14 PM, Peter Grehan gre...@freebsd.org wrote:
 
 Hi Warner,
 
 I like this patch better than the one I have. I’m not 100% sure the
 ‘else’ clause will work
 
 The else for CROSS_BINUTILS_PREFIX ? If so, yes, that appears to work: I'm 
 building with in-tree binutils.
 
 Ok for this to be committed ?

Yes. I’m happy.

Warner

___
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: Resurrecting clang external toolchain support in Makefile.inc

[Warner Losh]

 On Feb 10, 2015, at 7:32 PM, Peter Grehan gre...@freebsd.org wrote:
 
 Hi toolchain folk,
 
 I've recently tried using the base system clang as an external toolchain i.e.
 
   make CROSS_COMPILER_PREFIX=/usr/bin/ buildworld
 
 .. and found that this no longer works after r273755 which split XFLAGS into 
 XC/XCXXFLAGS. This appears to be because the XFLAGS definitions that define 
 --sysroot and -B options aren't being passed through to clang, resulting in 
 using header files from the host system.
 
 My quick hack was
 
 --- Makefile.inc1 (revision 278542)
 +++ Makefile.inc1 (working copy)
 @@ -374,6 +374,8 @@
 TARGET_ABI?=  unknown
 TARGET_TRIPLE?=   ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd11.0
 XCFLAGS+= -target ${TARGET_TRIPLE}
 +XCFLAGS+=${XFLAGS}
 +XCXXFLAGS+=  ${XFLAGS}
 .endif
 .endif
 
 However, this doesn't look to be the right way to fix this.
 
 Any opinions on a proper fix ?

I have a similar “fix” in my tree as well, but hadn’t pushed it because I 
wasn’t quite sure the right way either.

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

[Differential] [Accepted] D1722: Add -s option to config

[imp (Warner Losh)]

imp accepted this revision.
imp added a comment.
This revision is now accepted and ready to land.

Looks good to me.

REVISION DETAIL
  https://reviews.freebsd.org/D1722

To: rodrigc, brooks, imp
Cc: freebsd-toolchain
___
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

[Differential] [Accepted] D1682: Preserve hard symbolic links when modifying source file

[imp (Warner Losh)]

imp accepted this revision.
imp added a reviewer: imp.

REVISION DETAIL
  https://reviews.freebsd.org/D1682

To: emaste, rpaulo, imp
Cc: freebsd-toolchain
___
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

[Differential] [Accepted] D1543: crunchide: Correct 64-bit section header offset

[imp (Warner Losh)]

imp accepted this revision.
imp added a reviewer: imp.
This revision is now accepted and ready to land.

REVISION DETAIL
  https://reviews.freebsd.org/D1543

To: emaste, pfg, imp
Cc: freebsd-toolchain
___
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

[Differential] [Accepted] D1468: Fix the ARM build of compiler-rt

[imp (Warner Losh)]

imp accepted this revision.
imp added a reviewer: imp.
This revision is now accepted and ready to land.

BRANCH
  /head

REVISION DETAIL
  https://reviews.freebsd.org/D1468

To: andrew, loos, sbruno, rpaulo, ian, dim, imp
Cc: freebsd-toolchain
___
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: RFT: Please help testing the llvm/clang 3.5.0 import

[Warner Losh]

This is excellent news Dimitry!

 On Dec 16, 2014, at 12:36 PM, Dimitry Andric d...@freebsd.org wrote:
 
 On 28 Nov 2014, at 22:03, Dimitry Andric d...@freebsd.org wrote:
 
 We're working on updating llvm, clang and lldb to 3.5.0 in head.  This
 is quite a big update again, and any help with testing is appreciated.
 
 To try this out, ensure you have good backups or snapshots, then build
 world and kernel from the projects/clang350-import branch [1].  Please
 use a Subversion mirror [2], if you are able to.
 
 Here are some updates about the status of the 3.5.0 import.
 
 * i386 and amd64 have been tested through make universe, and everything
  should compile and run.
 * Little-endian ARM builds should now compile and run, thanks to Andrew
  Turner for putting in lots of work.
 * Big-endian ARM is apparently supposed to work, but I'm not sure if
  Andrew managed to test it on real hardware.

I know Andrew doesn’t have the right arm gear to do this test, and emulation
environments that run FreeBSD have had poor big-endian support for arm.

 * PowerPC64 should mostly work, thanks to Justin Hibbits.
 * PowerPC32 might start working soon; it really needs some backporting
  of fixes to clang 3.4.1, which is now in head, so there is an easier
  upgrade path for PowerPC users.
 * Sparc64 still does not work, and I don't see any quick solutions to it
  for now.  It should probably stay with gcc.
 * Mips will only have a chance with the upcoming clang 3.6.0, but that
  is way too late for this import.  It will probably require external
  toolchain support to get it working.

For native builds yes. For cross builds, clang 3.6 can be built on an
x86 host.

 * Another ports exp-run was done [3], after fixing the problem with
  lang/gcc, which lead to many skipped dependent ports.
 * The second exp-run had much better results: the failure with the
  highest number of dependencies is devel/mingw32-gcc, but this seems
  to be due to a problem with makeinfo, not clang.  The next highest on
  the list is java/openjdk6, for which ports r374780 [4] was very
  recently committed.

Will users of our stable branch have code similar to the code that caused
problems? One warning flag about your upgrade to the stable branch
would be if there’s a significant number of user-written programs that
suddenly become uncompilable with the new clang using the environment
that they have today. We know of some items that are issues, so careful
attention here is needed. Unless we go proactively looking for these,
there’s a good chance we won’t find them until users hit them and start
to complain (by which point it is likely too late). Could you post a summary
of the issues that ports have hit and the fixes necessary? We may need
to have that in the release notes and/or UPDATING file to help prepare
our users for the bumps and give them solutions over them.

 I would really like to merge this branch to head in about a week,
 pending portmgr approvall; I don't expect the base system (outside of
 llvm/clang) to need any further updates.

I think there’s good reason to do this, but we should chat about the
build issues below before doing it. They are minor, but an important
detail. I’ll see if I can find a few minutes to pull the branch and send
patches.

 Lastly, to clear things up about the requirements for this branch (and
 thus for head, in a while); to build it, you need to have:
 * A C++11 capable host compiler, e.g. clang = 3.3 or later, or gcc
 = 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome)
 * A C++11 standard library, e.g. libc++, or libstdc++ from gcc = 4.8.
 
 So from any earlier standard 10.x or 11.x installation, you should be
 good, unless you explicitly disabled clang or libc++.  In that case,
 you must build and install both of those first.

This is true only on i386, amd64, and arm hosts. Given that some people
do try to do weird things, tightening up how you present this will get the
word out a little better.

 On a 9.x installation, you will have clang by default, but not libc++,
 so libc++ should be built and installed first, before attempting to
 build the clang350-import branch.

Can you make sure that the UPDATING entry you are writing for this
contains explicit instructions.

 On 8.x an earlier, you need to upgrade to at least 9.x first, follow
 the previous instruction.

We should remove building on 8 support then, unless there external
toolchain stuff is up to the task (e.g. build gcc 4.9, libstc++, etc).

 As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while
 (roughly a month), but this will cause upgrades from 9.x to 10.x to
 start requiring the build of libc++, as described above.  I don't think
 we can merge clang 3.5.x to 9.x, unless clang becomes the default
 compiler there (but that is very unlikely).

Let’s see how it goes, and what the upgrade issues wind up being
before doing this merge back. New “major” compilers on stable branches
traditionally haven’t been done, but if clang is 

Re: RFT: Please help testing the llvm/clang 3.5.0 import

[Warner Losh]

 On Dec 18, 2014, at 12:01 PM, Dimitry Andric d...@freebsd.org wrote:
 
 On 18 Dec 2014, at 15:47, Warner Losh i...@bsdimp.com wrote:
 ...
 * Mips will only have a chance with the upcoming clang 3.6.0, but that
 is way too late for this import.  It will probably require external
 toolchain support to get it working.
 
 For native builds yes. For cross builds, clang 3.6 can be built on an
 x86 host.
 
 Yes, and it could even be one of the ports, if that is easier to use.
 
 
 * Another ports exp-run was done [3], after fixing the problem with
 lang/gcc, which lead to many skipped dependent ports.
 * The second exp-run had much better results: the failure with the
 highest number of dependencies is devel/mingw32-gcc, but this seems
 to be due to a problem with makeinfo, not clang.  The next highest on
 the list is java/openjdk6, for which ports r374780 [4] was very
 recently committed.
 
 Will users of our stable branch have code similar to the code that caused
 problems?
 
 I'm not sure which code you are referring to here, the openjdk6 code?
 The code itself is basically fine, but for reasons unknown to me, the
 port is compiled with -Werror (which is not the case for the other
 openjdk ports, apparently).  Since clang 3.5.0 adds a few new warnings
 for shaky C++ constructions, these appear during the openjdk6 build, but
 they are easily suppressed, if upstream does not fix them, or does not
 care to fix them.

I meant “similar code to what’s causing problems” with the build run in their
code they build on FreeBSD. If it is a few new warnings for obscure things,
we can advice to the release notes about what to avoid and how to mitigate
things.

 I already sent Jung-uk an alternative fix for openjkd6, similar to the
 one used for www/squid, where warnings are suppressed based on the
 COMPILER_VERSION variable provided the ports infrastructure.  In my
 opinion it would still be easier to just to turn off -Werror for any
 third-party code, if we don't feel like modifying it (with all the risks
 involved).

Yea, we can sort out the code in src and ports. I’m more worried about
what to tell our users that may be compiling their own code that we don’t
control. If these new warnings are ubiquitous, then that could be a problem
for adoption (since many shops mandate -Werror as much as possible, and
to comply with that mandate would require additional resources when trying
to upgrade). If there are a few, then we could just document them and move on.

 One warning flag about your upgrade to the stable branch
 would be if there’s a significant number of user-written programs that
 suddenly become uncompilable with the new clang using the environment
 that they have today. We know of some items that are issues, so careful
 attention here is needed. Unless we go proactively looking for these,
 there’s a good chance we won’t find them until users hit them and start
 to complain (by which point it is likely too late). Could you post a summary
 of the issues that ports have hit and the fixes necessary? We may need
 to have that in the release notes and/or UPDATING file to help prepare
 our users for the bumps and give them solutions over them.
 
 The base system is already completely free of warnings, as far as I know
 of, so no action is needed there.  For ports, the number of failures
 introduced by new warnings are quite small, as far as I can see, and
 mostly for ports that are compiled with -Werror.

Yea, I wasn’t too worried about this aspect of things.

 The most encountered new warnings are, off the top of my head:
 
 -Wabsolute-value
 
 This warns in two cases, for both C and C++:
 * When the code is trying to take the absolute value of an unsigned
  quantity, which is effectively a no-op, and almost never what was
  intended.  The code should be fixed, if at all possible.
 * When the code is trying to take the absolute value, but the called
  abs() variant is of the wrong type, which may lead to truncation.
  If the warning is turned off, better make sure any truncation does
  not lead to unwanted side-effects.
 
 -Wtautological-undefined-compare and
 -Wundefined-bool-conversion
 
 These warn when C++ code is trying to compare 'this' against NULL, while
 'this' should never be NULL in well-defined C++ code.  However, there is
 some legacy (pre C++11) code out there, which actively abuses this
 feature, which was less strictly defined in previous C++ versions.
 
 Squid does this, and apparently openjdk too.  The warning can be turned
 off for C++98 and earlier, but compiling the code in C++11 mode might
 result in unexpected behavior, for example the unreachable parts of the
 program could be optimized away.

This is the kind of information I was talking about. Do we have a process
to make sure this gets into the release notes?

 I would really like to merge this branch to head in about a week,
 pending portmgr approvall; I don't expect the base system (outside of
 llvm/clang) to need any further updates.
 
 I

armeb build of clang350-import

[Warner Losh]

Thought I’d try to build armeb on clang350-import branch on my ad64 host, and 
found it failed to build because of a dependency on a machine include that 
doesn’t exist yet.

% make buildworld TARGET=arm TARGET_ARCH=armeb -DWITHOUT_GCC{,_BOOTSTRAP} 
-DWITH_CLANG{,_BOOTSTRAP}
...
=== gnu/lib/libgcc (obj,depend,all,install)
(cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make -f 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
 
MFILE=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
 
GCCDIR=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
 tm.h)
TARGET_CPU_DEFAULT=  HEADERS=options.h dbxelf.h elfos-undef.h elfos.h 
freebsd-native.h freebsd-spec.h freebsd.h arm/elf.h arm/aout.h arm/bpabi.h 
arm/freebsd.h arm/arm.h defaults.h  DEFINES=  /bin/sh 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh
 tm.h
echo '#define EXTRA_MODES_FILE arm/arm-modes.def'  tm.h
(cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make -f 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
 
MFILE=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
 
GCCDIR=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
 tconfig.h)
TARGET_CPU_DEFAULT=  HEADERS=auto-host.h ansidecl.h  
DEFINES=USED_FOR_TARGET  /bin/sh 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/mkconfig.sh
 tconfig.h
(cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make -f 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
 
MFILE=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
 
GCCDIR=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
 options.h)
LC_ALL=C awk -f 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/opt-gather.awk
 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/c.opt
 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/common.opt
 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/config/arm/arm.opt
  optionlist
LC_ALL=C awk -f 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk
  -f 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk
   optionlist  options.h
(cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make -f 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
 
MFILE=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
 
GCCDIR=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
 unwind.h)
ln -sf 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/config/arm/unwind-arm.h
 unwind.h
(cd /usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc; make -f 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
 
MFILE=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools/Makefile
 
GCCDIR=/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
 gthr-default.h)
ln -sf 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/gthr-posix.h
 gthr-default.h
cc  -c -O -pipe   -DTARGET_ARM_EABI -DIN_GCC -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED  -DHAVE_GTHR_DEFAULT  
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcclibs/include
  
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/config
 
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
 -I.  
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools
 -Dinhibit_libc -fno-inline -std=gnu99   -fheinous-gnu-extensions 
-Qunused-arguments -fvisibility=hidden -DHIDE_EXPORTS -fPIC -fexceptions 
-D__GLIBC__=3 -DElfW=__ElfN -o unwind-arm.o 
/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/config/arm/unwind-arm.c
cc  -c -O -pipe   -DTARGET_ARM_EABI -DIN_GCC -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED  -DHAVE_GTHR_DEFAULT  
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcclibs/include
  
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc/config
 
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../../contrib/gcc
 -I.  
-I/usr/home/imp/FreeBSD/clang-350/clang350-import/gnu/lib/libgcc/../../usr.bin/cc/cc_tools
 

Re: Migration to dynamic libs for llvm and clang

[Warner Losh]

 On Dec 16, 2014, at 9:32 AM, Dimitry Andric d...@freebsd.org wrote:
 
 On 16 Dec 2014, at 17:15, David Chisnall thera...@freebsd.org wrote:
 
 On 16 Dec 2014, at 16:04, Dimitry Andric d...@freebsd.org wrote:
 This is precisely why the libs should go into /usr/lib/private, so as to
 avoid collisions with any upstream libraries installed by e.g. ports (or
 when you manually run make install after building).
 
 That's still potentially an issue if we add local tools that use libclang 
 APIs (which we may well do).
 
 I'm not sure we want to go the 'libbsdfoo.so' route again, as Baptiste
 tried this before, and seems to have reversed it again. :)
 
 Upstream doesn't call it libclang (that's the name of the library with a 
 stable C ABI, which is why I'd like us not to confuse it with something with 
 a library with an unstable C++ API).  They do produce a libLLVM.so from the 
 LLVM builds and work is underway to have shared library builds for clang.
 
 libLLVM.so could potentially be in /usr/lib in 11 if we have a packaged base 
 system, as it would allow us to have different .so versions installed if 
 things demanded them.  The point releases guarantee backwards ABI 
 compatibility, so we can still upgrade to them if required.
 
 Unfortunately we already imported quite a lot of ABI-breaking bug fixes.
 I would prefer only our own tools to be linked against the FreeBSD
 version of libllvm.so/libwhatever.so.

:(

 That said, I agree with the general idea, but one of the first things
 we should decide is whether this will be optional or not.  Having to
 maintain yet another WITH_CLANG_FOO option is burdensome...
 
 I agree.  I'd quite like to see performance numbers for the compiler.  I 
 think I saw about a 10% overhead for buildworld last time I tried, but that 
 was a couple of years ago.
 
 There is already a WITH_SHARED_TOOLCHAIN option, that defaults to off,
 but I have had it on since approximately the time Kostik added it.  I
 might just have gotten used to the overhead, if any…

The 10% figure has been relatively constant over the lifetime of shared
libraries in FreeBSD. This is the average hit of using shared libraries
and everybody accepts that. I doubt time has changed this much at all.

 I would like to do a bit of testing with that, but my TODO list is
 rather full at this point, working on the 3.5.0 import. :)

We should defer testing until after that import :)

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Migration to dynamic libs for llvm and clang

[Warner Losh]

 On Dec 16, 2014, at 10:44 AM, Ed Maste ema...@freebsd.org wrote:
 
 Fair enough, I'd definitely like to see fewer build-time knobs over
 time, not more.

Until we stop using build-time knobs to control what’s in the final image
as a poor man’s packaging scheme, I expect the number of knobs to
continue to grow.

In this case, however, it should be covered under the existing knobs
though (or we should eliminate the knob :).

Warner




signature.asc
Description: Message signed with OpenPGP using GPGMail

[Differential] [Accepted] D1327: Do not strip all when stripping an explicit symbol

[imp (Warner Losh)]

imp added a subscriber: imp.
imp accepted this revision.
imp added a reviewer: imp.
imp added a comment.
This revision is now accepted and ready to land.

Looks good to me.

REVISION DETAIL
  https://reviews.freebsd.org/D1327

To: emaste, imp
Cc: imp, freebsd-toolchain
___
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: Building clang in buildworld as part of the bootstrap process -- is it really necessary?

[Warner Losh]

On Sep 6, 2014, at 5:32 AM, Dimitry Andric d...@freebsd.org wrote:

 On 06 Sep 2014, at 05:16, Warner Losh i...@bsdimp.com wrote:
 
 On Sep 5, 2014, at 8:21 PM, Garrett Cooper yaneurab...@gmail.com wrote:
 
  One of the questions that came up from a co-worker is why do I
 need to build clang in buildworld if I already installed it from
 ports? I could see some valid reasons for doing this (one needs a
 cross-compiler, one might need specific options that might not be set
 in the ports version), but for native builds I would tend to agree
 with this logic.
 
 For one, the base version of clang has a number of patches which haven't
 yet been sent upstream (and might never be).  I see the port already has
 a few of them, but certainly not all.
 
 That said, the ultimate goal is obviously to be able to build world with
 a stock version of an external compiler, be it clang or gcc.  There is
 still quite a lot to be done to make that possible.

Yes. Some use cases work, others don’t.

 
 With gcc it was wasteful building the compiler each
 buildworld, but with clang it seems annoying continuing on this path
 because the compile takes a long time to complete.
 
 The clang built during buildworld is used to bootstrap. So it is required 
 sometimes. Usually when there’s a binary compatibility issue, which is rare 
 but does happen.
 
 We already do something similar with BOOTSTRAPPING, where we attempt to
 detect which build tools on the host system are too old, and build them
 accordingly.  I think something like this might also be possible for the
 toolchain components, for example by using the __FreeBSD_cc_version
 built-in define (which is also in our gcc, but it doesn't seem to be
 used very often).  Or some other system entirely.

We’ve avoided playing the “optimize the build” game for buildworld. while we do 
make some exceptions for minor, ancillary tools, we always assume a full build 
will always work, and that’s the only way the project supports people.

 It is also installed as cc.
 
 That's actually another copy, the one built during the later stages.  It
 might not even run on the host system. :)

True. My point in mentioning this is that you don’t get cc unless you build 
clang or gcc in base.

 
 The ports clang may or may not build the world. However, if you want to say 
 “I know what I’m doing” you can set WITHOUT_CLANG_BOOTSTRAP and 
 WITHOUT_GCC_BOOTSTRAP to tell the build to do no building of bootstrap tools 
 and to use the host’s instead. This usually works, but may fail from time to 
 time with port-built compilers.
 
 If you don’t want buildworld to build any compiler, you can add 
 WITHOUT_CLANG=t and WITHOUT_GCC=t. This will create the system without any 
 compilers. You’ll need to set CC to /usr/local/bin/clang35 or whatever as 
 well. There may be other settings you need as well.
 
  Alternatively, would anyone be opposed to adding some logic to
 automatically bypass the bootstrap compiler, i.e. add some logic to
 Makefile.inc1 that would skip compiling clang/gcc if and only if the
 target triplet and version met some required values?
 
 There’s enough violent opposition to this that it will never happen. 
 buildworld is supposed to always be safe. Don’t mess with that. It isn’t 
 designed to be fast.
 
 Yup, though in most cases, it should be sufficient to do an incremental
 buildworld instead of a full one.  This would also prevent rebuilding
 any part of llvm and/or clang, as long as no changes occur in them.

buildwolrd -DNO_CLEAN already does that...

 For example, the only recent change to clang was in one of the ARM
 target's .td files (to fix a problem with movw being sometimes emitted
 on ARMv6).  In this case, only a bunch of .inc files will be regenerated
 and some of the files under lib/clang/libllvmarm* will be rebuilt, but
 certainly not the entire llvm and clang codebase.
 
 I would really like for incremental buildworld to become more robust. :)

I would too. However, every time clang gets upgraded, it clang seems to break 
the no_clean case :( There are also other offenders, but we’ve not had smooth 
sailing in the upgrade with NO_CLEAN stuff for a long time, hence my caution.

jbuild shoed a lot of promise. We need to get that done if we want to get away 
from all this crazy.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Building clang in buildworld as part of the bootstrap process -- is it really necessary?

[Warner Losh]

On Sep 5, 2014, at 8:21 PM, Garrett Cooper yaneurab...@gmail.com wrote:

 Hi all,
One of the questions that came up from a co-worker is why do I
 need to build clang in buildworld if I already installed it from
 ports? I could see some valid reasons for doing this (one needs a
 cross-compiler, one might need specific options that might not be set
 in the ports version), but for native builds I would tend to agree
 with this logic. With gcc it was wasteful building the compiler each
 buildworld, but with clang it seems annoying continuing on this path
 because the compile takes a long time to complete.

The clang built during buildworld is used to bootstrap. So it is required 
sometimes. Usually when there’s a binary compatibility issue, which is rare but 
does happen. It is also installed as cc.

The ports clang may or may not build the world. However, if you want to say “I 
know what I’m doing” you can set WITHOUT_CLANG_BOOTSTRAP and 
WITHOUT_GCC_BOOTSTRAP to tell the build to do no building of bootstrap tools 
and to use the host’s instead. This usually works, but may fail from time to 
time with port-built compilers.

If you don’t want buildworld to build any compiler, you can add WITHOUT_CLANG=t 
and WITHOUT_GCC=t. This will create the system without any compilers. You’ll 
need to set CC to /usr/local/bin/clang35 or whatever as well. There may be 
other settings you need as well.

Alternatively, would anyone be opposed to adding some logic to
 automatically bypass the bootstrap compiler, i.e. add some logic to
 Makefile.inc1 that would skip compiling clang/gcc if and only if the
 target triplet and version met some required values?

There’s enough violent opposition to this that it will never happen. buildworld 
is supposed to always be safe. Don’t mess with that. It isn’t designed to be 
fast. If you want fast, you can tell it to be fast with different options, but 
it will never be fast by default because we guessed that we think it might be 
safe. don’t mess with buildworld. There might be support for a go-fast 
catch-all flag that sets a bunch of other flags to make things go fast, but 
once you get down that rabbit hole you’ll find one man’s optimization is 
another woman’s intolerable omission.

tl;dr: NO.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: More dangerous UB handling of clang (compared to gcc)

[Warner Losh]

On Mar 1, 2014, at 4:18 PM, Ahmed Charles achar...@outlook.com wrote:

 
 Subject: Re: More dangerous UB handling of clang (compared to gcc)
 From: bsd...@gmail.com
 Date: Fri, 28 Feb 2014 08:38:38 -0700
 To: amd...@amdmi3.ru
 CC: freebsd-toolchain@FreeBSD.org
 
 
 On Feb 28, 2014, at 8:06 AM, Dmitry Marakasov amd...@amdmi3.ru wrote:
 
 Hi!
 
 Another issue I wanted to mention: compared to gcc, clang handles
 some undefined behaviour cases more dangerously. It has the full
 right to do so as it's UB, however we may want to take extra steps
 to find and fix these cases.
 
 Except this is a flat out bug….
 
 Example:
 
 --- ub.cc begins here ---
 #include iostream
 
 int func1() {
 std::cerr  func1()\n;
 /* no return */
 }
 
 void func2() {
 std::cerr  NEVER CALLED\n;
 }
 
 int main() {
 func1();
 return 0;
 }
 --- ub.cc ends here ---
 
 ---
 % g++46 -o ub ub.cc  ./ub
 func1()
 % g++46 -O2 -o ub ub.cc  ./ub
 func1()
 % clang++ -o ub ub.cc  ./ub
 ub.cc:6:1: warning: control reaches end of non-void function
 [-Wreturn-type]
 }
 ^
 1 warning generated.
 func1()
 Illegal instruction
 % clang++ -O2 -o ub ub.cc  ./ub
 ub.cc:6:1: warning: control reaches end of non-void function
 [-Wreturn-type]
 }
 ^
 1 warning generated.
 func1()
 NEVER CALLED
 Segmentation fault
 ---
 
 As you can see, while with gcc the function returns even if it has no
 return statement, with clang it either crashes or calls the following
 function. This may lead to new crashes and security problems after
 switching to clang (most likely in ports code of course).
 
 This is a flat out bug. When control reaches the end of a function, it must 
 return, even if there’s no return statement. The value returned from func1() 
 is, of course, undefined, but this is well defined behavior in the standard…
 
 I’d be very interested to see chapter and verse on this one...
 
 n3690: 6.6.3[stmt.return]/p2
 
 Flowing off the end of a function is equivalent to a return with no value; 
 this results in undefined behavior in a value-returning function.
 
 C++ and C are distinctly different in this regard.

Seems like the ‘jump into the next function’ as a result of the core dump you 
put in being optimized away is a breathtakingly stupid, but allowed, undefined 
behavior. I mean, as stupid as forking rogue when #pragma is encountered. 
Better for that forced core dump to not be optimized away, or there be a return 
statement.

Hence my belief that the resolution is bogus.

 I wonder of we could make use of -Werror=return-type which makes the
 warning issued by clang here fatal, what do you think? If adding it to
 default CFLAGS/CXXFLAGS is not an option, we may at least have an
 extra `strict' pkg-fallout builder.
 
 Related clang bug: http://llvm.org/bugs/show_bug.cgi?id=18296 (resoleved
 as INVALID).
 
 I believe this resolution is, in fact, bogus. Sure, insert ud2, but also put 
 a f’ing return in there.
 
 I know in C11,this id definitely the case:
 
 6.9.1:
 12 If the } that terminates a function is reached, and the value of the 
 function call is used by
 the caller, the behavior is undefined.
 
 But the C++ standard is somewhat opaque on the topic, but none of the 56 
 instances of ‘undefined results’ in the standard appeared to apply.
 
 I'm also positively sure that I've encountered another problematic
 UB case with another warning, but I don't remember which. Real
 list of useful Werror's may be quite big.
 
 Yea, this is a big deal. Sure, people shouldn’t do this, but this kind of 
 undefined behavior is well outside the bounds of traditional compilers.
 
 Warner
 
 
 ___
 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 
   
 ___
 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

___
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: More dangerous UB handling of clang (compared to gcc)

[Warner Losh]

On Feb 28, 2014, at 8:06 AM, Dmitry Marakasov amd...@amdmi3.ru wrote:

 Hi!
 
 Another issue I wanted to mention: compared to gcc, clang handles
 some undefined behaviour cases more dangerously. It has the full
 right to do so as it's UB, however we may want to take extra steps
 to find and fix these cases.

Except this is a flat out bug….

 Example:
 
 --- ub.cc begins here ---
 #include iostream
 
 int func1() {
   std::cerr  func1()\n;
   /* no return */
 }
 
 void func2() {
   std::cerr  NEVER CALLED\n;
 }
 
 int main() {
   func1();
   return 0;
 }
 --- ub.cc ends here ---
 
 ---
 % g++46 -o ub ub.cc  ./ub
 func1()
 % g++46 -O2 -o ub ub.cc  ./ub
 func1()
 % clang++ -o ub ub.cc  ./ub
 ub.cc:6:1: warning: control reaches end of non-void function
 [-Wreturn-type]
 }
 ^
 1 warning generated.
 func1()
 Illegal instruction
 % clang++ -O2 -o ub ub.cc  ./ub
 ub.cc:6:1: warning: control reaches end of non-void function
 [-Wreturn-type]
 }
 ^
 1 warning generated.
 func1()
 NEVER CALLED
 Segmentation fault
 ---
 
 As you can see, while with gcc the function returns even if it has no
 return statement, with clang it either crashes or calls the following
 function. This may lead to new crashes and security problems after
 switching to clang (most likely in ports code of course).

This is a flat out bug. When control reaches the end of a function, it must 
return, even if there’s no return statement. The value returned from func1() 
is, of course, undefined, but this is well defined behavior in the standard…

I’d be very interested to see chapter and verse on this one...

 I wonder of we could make use of -Werror=return-type which makes the
 warning issued by clang here fatal, what do you think? If adding it to
 default CFLAGS/CXXFLAGS is not an option, we may at least have an
 extra `strict' pkg-fallout builder.
 
 Related clang bug: http://llvm.org/bugs/show_bug.cgi?id=18296 (resoleved
 as INVALID).

I believe this resolution is, in fact, bogus. Sure, insert ud2, but also put a 
f’ing return in there.

I know in C11,this id definitely the case:

6.9.1:
12 If the } that terminates a function is reached, and the value of the 
function call is used by
the caller, the behavior is undefined.

But the C++ standard is somewhat opaque on the topic, but none of the 56 
instances of ‘undefined results’ in the standard appeared to apply.

 I'm also positively sure that I've encountered another problematic
 UB case with another warning, but I don't remember which. Real
 list of useful Werror's may be quite big.

Yea, this is a big deal. Sure, people shouldn’t do this, but this kind of 
undefined behavior is well outside the bounds of traditional compilers.

Warner


___
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: Apple's GCC 42 enhancements (was Re: [CFT] Experimental gcc update).

[Warner Losh]

On Nov 24, 2013, at 5:54 AM, David Chisnall wrote:

 On 23 Nov 2013, at 22:11, Pedro Giffuni p...@freebsd.org wrote:
 
 I have particular interest in -fwritable-strings
 and the block support, mostly with the idea of making our gcc
 somewhat more compatible to clang.
 
 I would absolutely love to see our GCC have blocks support.  It would be very 
 nice to be able to use blocks in libc.  
 
 I have some macros that allow code to call blocks even when compiled with a 
 compiler that doesn't support them, but having native blocks support would be 
 fantastic.  It's worth noting that Apple's libc includes a few _b variants of 
 standard library functions:
 
 scandir_b
 err_set_exit_b
 fts_open_b
 glob_b
 atexit_b
 bsearch_b
 heapsort_b
 mergesort_b
 psort_b
 qsort_b
 
 These all do the same as their non-_b-suffixed equivalents, but take a block 
 as an argument instead of a function pointer.  Adding them has been on my 
 todo list for a while, and this would give me a strong incentive to do so...

Cool! Any chance clang supports this Apple extension? :)

Warner

___
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

make xdev broken

[Warner Losh]

In 9.2 stable on amd64, make xdev is broken.

sudo make xdev XDEV=i386 XDEV_ARCH=i386

terminates with

In file included from 
/imp/svn/stable/9/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp:17:
/imp/svn/stable/9/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/AST/Attr.h:
 In static member function 'static bool clang::MSInheritanceAttr::classof(const 
clang::Attr*)':
/imp/svn/stable/9/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/AST/Attr.h:148:
 error: 'LAST_MS_INHERITABLE' is not a member of 'clang::attr'

what's up with that? Any ideas on how to fix this?

Warner

___
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: make xdev broken

[Warner Losh]

On Nov 17, 2013, at 2:45 PM, Dimitry Andric wrote:

 On 17 Nov 2013, at 20:37, Warner Losh i...@bsdimp.com wrote:
 In 9.2 stable on amd64, make xdev is broken.
 
 sudo make xdev XDEV=i386 XDEV_ARCH=i386
 
 terminates with
 
 In file included from 
 /imp/svn/stable/9/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp:17:
 /imp/svn/stable/9/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/AST/Attr.h:
  In static member function 'static bool 
 clang::MSInheritanceAttr::classof(const clang::Attr*)':
 /imp/svn/stable/9/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/AST/Attr.h:148:
  error: 'LAST_MS_INHERITABLE' is not a member of 'clang::attr'
 
 what's up with that? Any ideas on how to fix this?
 
 Was it ever supposed to work?  As far as I can see in Makefile.inc1, it
 is only supposed to build binutils and gcc, but nothing clang-related.

But it builds clang stuff! Even though it isn't building clang. I added 
WITHOUT_CLANG=t...

 In any case, to build clang, you also need to build tblgen and
 clang-tblgen as bootstrap tools, otherwise you might end up with
 incorrectly generated .inc files.  This is most likely the cause of the
 errors you list above.

That makes sense.

 If the only purpose of xdev is to build binutils and gcc, the easiest
 solution is probably to exclude the clang libraries from the
 _xi-libraries target, for example by setting WITHOUT_CLANG to a
 non-empty value.

Yes. I realized that. I should fix this by adding that to the makefile.

It isn't clear to me if xdev should evolve clang support or not. It was done 
the way it was to be as compatible as possible with normal cross development... 
I'm honestly not sure how to do that with clang.. The clang guys just blew off 
(or were ignorant of) xdev, so it isn't surprising it doesn't work. Annoying, 
but not surprising.

Warner

___
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: Best autoconf recipe to use for modern FreeBSD

[Warner Losh]

On Sep 12, 2013, at 7:32 PM, Murray Stokely wrote:

 Some application software I use seems to prefer ancient gcc release or
 gcc46 from ports rather than clang.
 
 Is there a recommended autoconf recipe for third party software to use the
 right compilers across FreeBSD versions?

I thought the compiler was passed with the CC variable to gnu configure...  Or 
are you asking for something else?

Warner
___
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: Best autoconf recipe to use for modern FreeBSD

[Warner Losh]

You might want to ask over in the ports...  Since the ports system has a good 
mechanism for specifying a good compiler to use.

I'm not sure that your approach will actually work, since it is a bit too 
fuzzy, but I'm sure others who know better will fill this in...

Warner

On Sep 12, 2013, at 8:10 PM, Murray Stokely wrote:

 Well one can do that, yes, but by default any configure script is going to 
 look for g++ first, find an ancient g++4.2 installed in /usr/bin/g++ and use 
 that unless the user specifically sets CC.  I'm a bit fuzzy on the timeline 
 of FreeBSD's transition to clang over the last few years and so was hoping 
 for a autoconf recipe that prefers the appropriate compiler (e.g. did we have 
 clang on FreeBSD 7?) when the user doesn't manually specify CC.
 
 Given the preference for gcc in configure I guess I could just use something 
 as simple as :
 
 if uname=FreeBSD
   # override configure preference for gcc since FreeBSD ships an ancient one.
   AC_PROG_CC(clang llvm-gcc gcc)
   AC_PROG_CXX(clang++ llvm-g++ g++)
 else
   AC_PROG_CC
   AC_PROG_CXX
 fi
 
 ? 
 
  - Murray
 
 
 
 On Thu, Sep 12, 2013 at 6:56 PM, Warner Losh i...@bsdimp.com wrote:
 
 On Sep 12, 2013, at 7:32 PM, Murray Stokely wrote:
 
  Some application software I use seems to prefer ancient gcc release or
  gcc46 from ports rather than clang.
 
  Is there a recommended autoconf recipe for third party software to use the
  right compilers across FreeBSD versions?
 
 I thought the compiler was passed with the CC variable to gnu configure...  
 Or are you asking for something else?
 
 Warner
 

___
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

[Warner Losh]

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


___
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

[Warner Losh]

On Aug 27, 2013, at 8:46 AM, Nathan Whitehorn wrote:
 On 08/25/13 18:41, Gerald Pfeifer wrote:
 On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote:
 I object. Many ports that compiles perfectly on gcc 4.2.1 can't be 
 compiled with lang/gcc. I checked this once and the number of ports 
 that require strictly gcc 4.2.1 was bigger for me then number of 
 ports that can't be compiled with clang but fill fine on lang/gcc.
 
 I'll gonna recheck whether lang/gcc42 is sufficient for them. But I 
 have that bad feeling...
 If there are ports that use USE_GCC=any and do not build with
 lang/gcc, these should have USE_GCC=4.2 -- without a '+'! --
 not USE_GCC=any.
 
 It'll be great if you can fix any such port.
 
 It would be particularly nice if we had a port with FreeBSD's many
 patches to 4.2. lang/gcc42 (and 46 and lang/gcc) do not build on
 powerpc64, for example, while our in-tree GCC does.

I think it would be more than nice to have. I'd argue that these issues need 
to be addressed before we can claim to have a full external-supported toolchain 
story that's integrated and well tested and covers the needs of all our users.

Warner

___
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

[Warner Losh]

On Aug 29, 2013, at 8:57 AM, John Baldwin wrote:

 On Saturday, August 24, 2013 7:19:22 am David Chisnall wrote:
 On 24 Aug 2013, at 11:30, Sam Fourman Jr. sfour...@gmail.com wrote:
 
 So I vote, let's not give ourselves the burden of lugging dead weight in
 base
 for another 5 years. (in 2017 do we still want to be worrying about gcc in
 base?)
 
 Perhaps more to the point, in 2017 do we want to be responsible for
 maintaining a fork of a 2007 release of gcc and libstdc++?
 
 This is a red herring and I'd wish you'd stop bringing it up constantly.
 GCC has not needed constant care and feeding in the 7.x/8.x/9.x branches
 and it won't need it in 10.x either.  I have not seen any convincing
 argument as to why leaving GCC in the base for 10.x impedes anything.
 Because clang isn't sufficient for so many non-x86 platforms we can't
 really start using clang-specific features yet anyway.

Agreed. Gcc is still an absolute requirement on all non-x86 platforms 
(including arm) due to the issues with clang. Some of these issues are bugs in 
specific things (arm) that keep coming up (and keep getting fixed), while 
others are more severe (sparc64 has no clang support, and no way to generate a 
self-hosting system in the absence of a bootstrap gcc in the base, even with 
the external toolchain support).

gcc will absolutely be in the base for 10. That's the long-standing agreement 
that we've had, and breaking it now at the 11th hour is going to totally screw 
up !x86 platforms and really piss off a lot of developers for no good reason. 
The time is long since past to change this plan.

This is the plan of record, and we need to stick to it:

10: clang default, where possible, gcc in base otherwise
11: clang default, full external toolchain support, including 
self-hosting

So the time for voting and carping has long since past.

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

[Warner Losh]

On Aug 29, 2013, at 11:02 AM, David Chisnall wrote:

 On 29 Aug 2013, at 15:57, John Baldwin j...@freebsd.org wrote:
 
  I have not seen any convincing
 argument as to why leaving GCC in the base for 10.x impedes anything.
 Because clang isn't sufficient for so many non-x86 platforms we can't
 really start using clang-specific features yet anyway.
 
 Apparently I haven't been good at communicating, so I'll try to here.  I 
 apologise for ignoring this thread for the last week: I've been rather busy 
 organising the DevSummit.  The notes for the sessions will be posted to 
 various mailing lists soon (and summarised for a special status report), but 
 since the ports and toolchain build sessions are already largely up you can 
 check these on the wiki.  You'll notice that in both sessions the topic of 
 removing gcc / libstdc++ was raised and there was no objection (not sure if 
 it's in the notes, but there was a lot of support during the ports session 
 from people who didn't want the pain of maintaining compatibility with 
 gcc-in-base, and especially with g++/libstdc++ in base).  
 
 This is not a new plan, it is the plan that has been on the wiki and 
 discussed at at least two DevSummits that I have attended before this week 
 and probably others that I missed, as well as on various mailing lists and in 
 IRC.  
 
 To summarise the current issues:
 
 Our libstdc++ is ancient.  It supports C++98 well, it kind-of supports C++03. 
  It doesn't support C++11 at all and never will, nor does it support C++14.  
 An increasing number of ports are depending on C++11, because it provides 
 much cleaner syntax than C++98 and so these are being forced to depend on 
 gcc46 or gcc47 to build.  Unfortunately, libstdc++ in ports is not ABI 
 compatible with the libstdc++ that we ship, which causes library ABI 
 versions.  This problem will only get worse over the coming years.  An 
 increasing number of these ports do build with libc++ (since it's the only 
 option on OS X / iOS - most do already and most of the fixes needed are just 
 adding some inclusions since libc++ doesn't leak C headers as much as 
 libstdc++), so defaulting to libc++ will reduce these problems over time.  

True, but this doesn't cause any problems for gcc, just g++.

 Maintaining our libstdc++ is not a zero-effort operation.  We have to modify 
 it whenever libc gains new features (e.g. POSIX2008 locales, new libm 
 functions) and this requires developer time tracking down the new bugs 
 (because the static configuration files no longer match the included headers) 
 and fixing them.

Fair enough, but the number of these has been, to date, quite small.

 Maintaining out gcc is also not a zero-effort operation.  Even though it is 
 not the default compiler for amd64 or i386, we still have to add support for 
 new instructions to them, even if we only want to use them in 
 machine-dependent code on these architecture.  

It actually is close to zero effort. The effort level is quite small, as 
evidence by the small number of commits to gcc over time. Not zero, but not as 
huge a deal as you make it out to be.

However, we still need to make the efforts so long as it is part of the base.

 Our g++ in base can only work with libstdc++, not libc++.  This means that 
 shipping gcc in 10.0 in base means that we'd be shipping two C++ compilers, 
 which preferred different standard libraries, with incompatible ABIs.  This 
 is setting us up for a world of pain.

This is a legitimate issue, for g++, not for gcc. But on !x86 targets we'll 
need to continue to do this.

 When we enable LLDB during the 10.x timeframe (emaste has been working hard, 
 but it's probably not quite ready for 10.0), it will have to link against 
 both LLVM libraries and libc++ (as it uses C++11 and doesn't work with our 
 libc++).  This is a minor issue, as the only requirement here is that we 
 switch to linking LLVM against libc++ instead of libstdc++, but it is an 
 example of one more piece of code that won't build with our gcc that is in 
 the base system (not yet enabled by default).  Clang 3.4 will not build with 
 our gcc either (which will cause some bootstrapping problems that we'll have 
 to address for people going from 9.x to 10.1, but the clang 3.3 in 9.2 should 
 be useable as long as we tweak the build system to use clang and not cc for 
 the bootstrap build).

Seems more like an issue for 11 not 10.

Also, we need to be able to bootstrap the base tools with gcc, since that's 
been the fallback bootstrap method for some time for people upgrading from 
really old systems: build the system with clang disabled the first time, and 
then use that to bootstrap clang since the gcc there can build it. I'd hate to 
loose this fallback plan, but do recognize at some point we must.

 Lots of configure scripts will use gcc in preference to cc (or g++ in 
 preference to c++) if they find them in the same place.  Many of these no 
 longer work with our old gcc, but do work 

Re: patch to add AES intrinsics to gcc

[Warner Losh]

On Aug 25, 2013, at 7:12 PM, Gerald Pfeifer wrote:

 On Sat, 24 Aug 2013, Warner Losh wrote:
 If you push gcc out to a port, and you have the 'external compiler' 
 toolchain support working correctly enough to build with this, why 
 don't we just push clang out to a port, and be done with it?
 This is a stupid idea. It kills the tightly integrated nature of 
 FreeBSD. I'd say it is far too radical a departure and opens up a 
 huge can of which version of what compiler nightmare that we've 
 largely dodged to date because we had one (or maybe two) compilers 
 in the base system.
 
 I am working towards establishing lang/gcc as _the_ version of GCC
 to use for ports.
 
 Today I looked at a couple of those GCC cross-compilers we have in 
 ports, and I have to admit I am not thrilled.  Each of those I saw
 copies a lot from (older version of my ports), each has a different
 maintainer, each has some additions, and there is little consistency.
 
 Are these the base of 'external compiler' toolchain support?  Are
 there any plans to increase consistency and reduce redundancy?  In
 an ideal world, could those become slave ports of lang/gcc?

In my experience, this has grown up rather hap-hazardly. Some more order here 
would be good. In the past, for example, some ports had some of the FreeBSD 
fixes, but not all so while I could build FreeBSD/mips gcc out of /usr/src, I 
couldn't do that, even for the (then current) gcc42 port since some of the 
fixes hadn't made it up stream.

In an ideal world, we'd be able to build any version of gcc for any FreeBSD 
platform (or have it fail up front) so we can use that as an external toolchain.

The initial work I did for external toolchains, that Brooks reworked (or 
rewrote from scratch, I can't recall which he did), was with make xdev in the 
tree...  And that has its own set of pros and cons...  All of which are really 
a tangent, so I'll leave it at that.

Warner

___
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

[Warner Losh]

Can all such ports be identified with a ports build run in a special chroot 
without FreeBSD's FCC installed?

Sent from my iPad

On Aug 25, 2013, at 7:41 PM, Gerald Pfeifer ger...@pfeifer.com wrote:

 On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote:
 I object. Many ports that compiles perfectly on gcc 4.2.1 can't be 
 compiled with lang/gcc. I checked this once and the number of ports 
 that require strictly gcc 4.2.1 was bigger for me then number of 
 ports that can't be compiled with clang but fill fine on lang/gcc.
 
 I'll gonna recheck whether lang/gcc42 is sufficient for them. But I 
 have that bad feeling...
 
 If there are ports that use USE_GCC=any and do not build with
 lang/gcc, these should have USE_GCC=4.2 -- without a '+'! --
 not USE_GCC=any.
 
 It'll be great if you can fix any such port.
 
 Gerald
 ___
 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
___
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

[Warner Losh]

On Aug 24, 2013, at 4:05 AM, David Chisnall wrote:

 On 23 Aug 2013, at 23:37, Warner Losh i...@bsdimp.com wrote:
 
 I'd dispute the 'and surely it seems like it does' part of this. Non x86 
 architectures will continue to use gcc because clang just isn't ready at 
 this time for them. Some are very close (arm), some are close (powerpc64, 
 mips*), some are no where near ready, or will never be ready (sparc64, 
 ia64). There's no coherent, documented plan for these absent gcc at the 
 moment. There are lots of pieces there, and those pieces will form the basis 
 of the solution (+handbook updates) for the removal of gcc in 11, but we 
 just aren't there yet.
 
 The plan, which has been discussed on mailing lists, on IRC, and at 
 DevSummits is for tier 2 ports to depend on an external toolchain.  For those 
 vendors that are not prevented from using GPLv3 compilers, this means that 
 they will be able to take advantage of, for example, the significant 
 improvements to the MIPS and PowerPC back ends that gcc has had over the last 
 6 years. For everyone else, it will mean installing a compiler from ports.

That's the plan for FreeBSD 11, yes. For FreeBSD 10, gcc remains in the tree.

 For now, tier 2 architectures will continue to build a toolchain from the src 
 tree and use that.  By 11.0, gcc will be gone from the base system and they 
 will be required to use something external if they are not supported by 
 clang.  Brooks has been working hard on making this easy, and it is generally 
 an improvement for cross-building embedded systems as the cross-compile 
 toolchain is no longer rebuilt every time you change a file in the kernel, 
 resulting in faster builds.  It is also easier to use toolchains provided by 
 chip vendors, which is something that MIPS and ARM vendors have been asking 
 for for a very long time.  

Yes. Many of the building blocks are in place, but they haven't been stitched 
together entirely yet. The 11 time frame is plenty of time to tie up the loose 
ends and rough edges that are there, as well as to ensure you can cross build a 
system, then do a native build on that system with external toolchains...

 For x86 and ARMv6/7, Clang has been the default compiler for a long time and 
 gcc has been increasingly problematic (for example, our gcc does not support 
 ARM EABI, which will be the default in 10.0 for ARMv6 and later, so if you 
 want to build for a modern ARM chip then you need either clang or a more 
 recent gcc than we ship).  Claiming that this is something done at the 
 expense of non-x86 architectures is highly misleading, as improving ARM 
 support is one of the driving factors behind the switch.

I'm sorry, but that's not quite right. Our gcc *DOES* support arm EABI with 
soft float. In fact, that's how we're using it now and how we're using clang 
now as well. clang support for ARM is still shaky, even in -current. EABI with 
hard float hasn't been done, and will require a newer gcc and/or clang, but 
we're not entirely there yet. The fallback for weird bugs is still recompile 
with the in-tree gcc and often that has fixed issues that people hit either 
with clang, or with assumptions about generated code that weren't quite true 
with clang and needed to be fixed in our kernel.

But *ALL* the other non-x86 architectures are significantly worse with clang. 
ARM is marginally the same, but we're still some issues we're fighting through 
with ports and such. I think I was clear about which ones were affected, and 
how though in my note.

 If you are shipping a product that relies on gcc, then for the 10.x 
 timeframe, you are free to build and use the gcc from the base system, and 
 the tinderboxes will prevent any non-optional components from being modified 
 in such a way that they can't build with this gcc.  In the 11.x timeframe, 
 architectures that aren't supported by clang will need an external toolchain. 
  

Yup. And the external toolchain support will need to be well documented and we 
need a cross building/installing external toolchain story that's better. It 
works well enough to generate a system now, but not quite well enough to 
generate a self-hosting system (which is required for the ports 
cross-build-on-qemu solution).

 AMD, Intel, AMD, Oracle, ARM, and MIPS are all actively contributing to LLVM 
 and Clang, so the only platform that is unlikely to have an LLVM back end in 
 the 11.0 timeframe is IA64, and if you really care about IA64 then Intel will 
 happily sell you a compiler that does a much better job than GCC of targeting 
 this architecture.


Yes. I'm totally on board with that for the 11 time frame. 32-bit powerpc had 
issues, and isn't in your list.

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

[Warner Losh]

On Aug 24, 2013, at 6:11 AM, Sam Fourman Jr. wrote:

 In my opinion this just needs to happen, if ports break, we deal with that
 
 on  a case by case basis.
 
 Oh, I remember. mplayer on i386 can't be builded witch clang -- clang
 don't understand inlined asm.
 
 
 Well, in this case, you would just have the mplayer maintainer configure the
 port to use gcc for the i386 build of mplayer... problem solved

The problem is that there's a lot of cases in ports where this work needs to be 
done. That work is ongoing, but isn't done yet. The ports people have indicated 
that in the 10 time frame may be a bit optimistic...

Warner

___
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 (was: Re: patch to add AES intrinsics to gcc)

[Warner Losh]

On Aug 23, 2013, at 5:16 AM, Kurt Jaeger wrote:

 Hi!
 
 I have a patch that I intend to commit before the 10.0 code
 slush that removes GCC and libstdc++ from the default build on
 platforms where clang is the system compiler.  We definitely don't
 want to be supporting our 6-year-old versions of these for the
 lifetime of the 10.x branch.
 
 Isn't it a POLA violation?
 
 As for me I expect something like this:
 . 9.x gcc default and clang in base;
 . 10.x clang default and gcc in base;
 . 11.x gcc withdraw.
 
 If the 150 ports that only work with gcc, all work with a ports
 gcc and do not need the gcc from base, would the following be OK ?
 
 - 9.x gcc default and clang in base;
 - 10.x clang default and gcc in ports;

No. That breaks non x86 architecutres. gcc must remain in base for now, or 
there's no bootstrap ability. Nobody has done the lifting to cleanly integrate 
gcc as a port into buildworld, althogh Brooks' work gets us most of the way 
there.

Warner

___
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

[Warner Losh]

On Aug 23, 2013, at 6:30 AM, Ian Lepore wrote:

 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?

If it is in the tree it's gotta work. And it has to be in the tree for !x86 
architectures. So on or off for x86 doesn't really add to the load at all, and 
the C++/C11 stuff is a red herring. If it isn't cc, then people wanting clang 
by default won't care...

And besides, ports aren't completely ready to kill it, so it has to work for 
them.

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