Re: Internal compiler error on gcc with latest updates

[Craig Rodrigues]

On Mon, Dec 2, 2013 at 6:40 AM, Justin Hibbits  wrote:

> Yesterday I started a full world update for my machine (powerpc64), but
> the new gcc import ICEs at emit-rtl.c:1784, when compiling zdb.  I
> haven't tried reverting contrib/gcc yet, but is there a good way to
> debug this?
>

If you are getting the same Internal Compiler Error,
it may be worth doing a web search on the GCC web site to see if it is a
known issue:

https://www.google.com/#q=site:gcc.gnu.org

--
Craig
___
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"

gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?

[Craig Rodrigues]

Hi,

Recently when trying to debug some coredumps in CURRENT from
a userland process in the devel/libvirt port, I found that the gdb in
base could not get a backtrace from the core file:

http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002606.html

I needed to add to my /etc/src.conf WITH_LLDB=yes
and compile and install lldb, which *could* analyze the coredump.

I realize that gdb in base is on its way out the door, and that
clang and lldb are the new world order.  However, one of the
main blockers for removing gdb from base is that
there is no equivalent to kgdb in the lldb world.

Is anyone working on a kernel lldb?  When is it expected to be ready?
Will something like it be ready by end of 2014?

Even though this may not be an issue in the stable/10 branch,
it would be nice to have a kernel lldb debugger ready by
the next 10.1R if possible.

--
Craig
___
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: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?

[Craig Rodrigues]

On Wed, Jun 11, 2014 at 12:30 PM, Dimitry Andric  wrote:
> On 11 Jun 2014, at 20:53, Craig Rodrigues  wrote:
>>
>> Recently when trying to debug some coredumps in CURRENT from
>> a userland process in the devel/libvirt port, I found that the gdb in
>> base could not get a backtrace from the core file:
>>
>> http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002606.html
>
> Can you please post the output of the following?
>
> objdump -W /usr/local/sbin/libvirtd | head
>
> -Dimitry
>

$ objdump -W /usr/local/sbin/libvirtd | head

/usr/local/sbin/libvirtd: file format elf64-x86-64-freebsd

The section .debug_aranges contains:

  Length:   92
  Version:  2
  Offset into .debug_info:  0
  Pointer Size: 8
  Segment Size: 0


--
Craig
___
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: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?

[Craig Rodrigues]

On Wed, Jun 11, 2014 at 12:34 PM, Warner Losh  wrote:
>
> Except for kgdb functionality, the gdb ports (both the 6.x and 7.x ones) work 
> much better than the gdb in the tree. This may be a good stop-gap until lldb 
> is ready.
>
> Warner
>

I installed devel/gdb which installs gdb762.  When I tried to debug
the corefile,
I encountered the same problem which I saw in:
http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002606.html

--
Craig
___
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: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?

[Craig Rodrigues]

On Wed, Jun 11, 2014 at 1:39 PM, Dimitry Andric  wrote:
> Ah sorry, your objdump prints sections in a different order than mine.
> I was mainly interested in the DWARF version of debug information; maybe
> the way you built libvirt has caused it to contain DWARF4 instead of
> DWARF2.
>
> Can you post the complete objdump output instead, or post just the part
> under "The section .debug_info contains"?  That should look similar to:


Here is the full output of objdump -W /usr/local/sbin/libvirtd:

http://people.freebsd.org/~rodrigc/libvirtd_objdump.txt

--
Craig
___
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: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?

[Craig Rodrigues]

Ed,

Can we enable WITH_LLDB=yes by default in
CURRENT only?  It took me a while to figure out that I needed
to build/install lldb to debug some of my coredumps in CURRENT.

I realize that things are in motion with respect to the toolchain,
but it is annoying that in CURRENT, we have a debugger in the base system
that cannot
debug userland cores properly.  I realize that things are in motion with
respect to the
toolchain, but this will help.

I really hope that the Summer of Code project to implement kernel debugging
support
for lldb reaches completion and we can finally remove our ancient gdb from
base (at least in CURRENT).

Thanks.
--
Craig



On Wed, Jun 11, 2014 at 11:53 AM, Craig Rodrigues 
wrote:

> Hi,
>
> Recently when trying to debug some coredumps in CURRENT from
> a userland process in the devel/libvirt port, I found that the gdb in
> base could not get a backtrace from the core file:
>
>
> http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002606.html
>
> I needed to add to my /etc/src.conf WITH_LLDB=yes
> and compile and install lldb, which *could* analyze the coredump.
>
> I realize that gdb in base is on its way out the door, and that
> clang and lldb are the new world order.  However, one of the
> main blockers for removing gdb from base is that
> there is no equivalent to kgdb in the lldb world.
>
> Is anyone working on a kernel lldb?  When is it expected to be ready?
> Will something like it be ready by end of 2014?
>
> Even though this may not be an issue in the stable/10 branch,
> it would be nice to have a kernel lldb debugger ready by
> the next 10.1R if possible.
>
> --
> Craig
>
___
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"

Jenkins and LLVM clang analyzer on FreeBSD

[Craig Rodrigues]

Hi,

FYI, Li-Wen Hsu  has set up this Jenkins job which
builds FreeBSD
with the clang analyzer (
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-scan-build/ ):

https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-scan-build/

This job runs once a week.  Please view the results of this job, and provide
feedback to:  freebsd-test...@freebsd.org.

Also, if you can see any bugs in FreeBSD identified by this tool,
please feel free to submit patches to fix them! :)

Thank you Li-Wen, for setting this up!!
--
Craig
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: clang and code coverage

[Craig Rodrigues]

On Thu, Nov 6, 2014 at 9:13 AM, Arthur Mesh  wrote:

>
> /usr/bin/ld: /usr/bin/../lib/libprofile_rt.a: No such file: No such file
> or directory
>

Prokash Sinha from Panasas asked the exact same question:

https://lists.freebsd.org/pipermail/freebsd-toolchain/2014-August/001181.html

but unfortunately no one on this list responded.
It would be great if one of the toolchain experts could respond, because
this would be a useful option to use in clang.

--
Craig
___
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: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0

[Craig Rodrigues]

Hi,

I just tried to build CURRENT with WITH_LLDB=yes
in /etc/make.conf.  I got this error:

/usr/obj/opt2/branches/head/usr.bin/clang/lldb/../../../lib/clang/libllvmaarch64disassemble
r/libllvmaarch64disassembler.a(AArch64Disassembler.o): In function
`createAArch64ExternalSy
mbolizer(llvm::StringRef, int (*)(void*, unsigned long, unsigned long,
unsigned long, int,
void*), char const* (*)(void*, unsigned long, unsigned long*, unsigned
long, char const**),
 void*, llvm::MCContext*, llvm::MCRelocationInfo*)':
/opt2/branches/head/lib/clang/libllvmaarch64disassembler/../../../contrib/llvm/lib/Target/A
Arch64/Disassembler/AArch64Disassembler.cpp:(.text+0xeaf): undefined
reference to `vtable f
or llvm::AArch64ExternalSymbolizer'

Any ideas?

Thanks.

--
Craig
___
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: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0

[Craig Rodrigues]

On Thu, Jan 8, 2015 at 6:04 AM, Ed Maste  wrote:

> On 8 January 2015 at 08:45, Craig Rodrigues  wrote:
> > I just tried to build CURRENT with WITH_LLDB=yes
> > in /etc/make.conf.  I got this error:
> >
> > ...
>
> Thanks for the report Craig, I'm looking at it.
>


This fixes it for me:

Index: libllvmaarch64disassembler/Makefile
===
--- libllvmaarch64disassembler/Makefile (revision 276808)
+++ libllvmaarch64disassembler/Makefile (working copy)
@@ -8,7 +8,7 @@
 INCDIR=lib/Target/AArch64
 SRCS=  AArch64Disassembler.cpp

-.if ${MK_CLANG_EXTRAS} != "no"
+.if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLDB} != "no"
 SRCS+= AArch64ExternalSymbolizer.cpp
 .endif

--
Craig
___
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"

Dependency walker for shared libraries in FreeBSD?

[Craig Rodrigues]

Hi,

On Windows, there is a tool, http://www.dependencywalker.com/ , that
can take a DLL as input, and then display all the dependencies that this
DLL has on other libraries.  This can be used to detect unresolved symbols.

Does anyone have a script that can do this on FreeBSD?
Basically, this would involve parsing the output of things like readelf,
nm, ldd, etc.

I tried looking for a similar tool on Linux, and found these:

https://launchpad.net/depspec
http://www.purinchu.net/software/elflibviewer.php
http://sourceforge.net/projects/binscan/

but I either couldn't build these tools, or the tools simply didn't work
under FreeBSD (elflibviewer).

--
Craig
___
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"

clang and scanbuild

[Craig Rodrigues]

Hi,

We currently have a Jenkins job which checks out llvm trunk and builds
it like this:

svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
cd llvm
./configure --enable-optimized --disable-assertions --disable-docs
--enable-targets=host \
--with-c-include-dirs=${WORKDIR}/obj${WORKDIR}/src/tmp/usr/include \
--with-cxx-include-root=${WORKDIR}/obj${WORKDIR}/src/tmp/usr/include

gmake -j4

cp -p ./tools/clang/tools/scan-build/scan-build \
  ./tools/clang/tools/scan-build/scanview.css \
  ./tools/clang/tools/scan-build/sorttable.js \
  Release/bin

cp -p ./tools/clang/tools/scan-build/ccc-analyzer \
  ./tools/clang/tools/scan-build/c++-analyzer \
  Release/bin

We then do this to invoke scan-build over the FreeBSD tree:

/usr/bin/time -l \
env CCC_ANALYZER_CHECKER_DEADCODE=0 \
${SCAN_BUILD} \
--use-cc ${OBJ}${SRCDIR}/tmp/usr/bin/cc \
--use-c++ ${OBJ}${SRCDIR}/tmp/usr/bin/c++ \
-k -o $output make ${JFLAG} $MYFLAGS \
CROSS_COMPILER_PREFIX=${OBJ}${SRCDIR}/tmp/usr/bin/ "$@"


We can continue to do this, but I was wondering if:
   (1)  is there a FreeBSD port which has this stuff?
   (2)  is there enough llvm source in FreeBSD that we can build this in
 FreeBSD instead of checking out llvm source?

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

Re: clang and scanbuild

[Craig Rodrigues]

On Wed, Feb 11, 2015 at 1:43 PM, Dimitry Andric  wrote:

>
> Yes, choose either lang/clang-devel, or lang/clangXY, where XY is the
> version you are interested in.
>
>
> >   (2)  is there enough llvm source in FreeBSD that we can build this in
> > FreeBSD instead of checking out llvm source?
>
> You can already run the analyzers with the clang executable in base,
> unless you built your world using WITHOUT_CLANG_FULL.  You do need perl
> installed, of course.
>
>
Nice!  I did this:

pkg install lang/clang-devel
export PATH=$PATH:/usr/local/llvm-devel/bin
scan-build cc a.c

scan-build: Using '/usr/local/llvm-devel/bin/clang' for static analysis
a.c:10:10: warning: Use of memory after it is freed
a[5] ='b';
 ^
1 warning generated.
scan-build: 1 bug found.
scan-build: Run 'scan-view /tmp/scan-build-2015-02-16-211517-60875-1' to
examine bug reports.

scan-view /tmp/scan-build-2015-02-16-211517-60875-1
Traceback (most recent call last):
  File "/usr/local/llvm-devel/bin/scan-view", line 131, in 
main()
  File "/usr/local/llvm-devel/bin/scan-view", line 128, in main
run(port, options, root)
  File "/usr/local/llvm-devel/bin/scan-view", line 57, in run
import ScanView
ImportError: No module named ScanView


It looks like some stuff for scan-view is missing from the port.  Do you
have any
ideas offhand what is missing?  It's not so important, because the
results of scan-build can be opened up in any web browser, independently of
scan-view.

Would it be possible to include scan-build somwehere under
/usr/src/contrib/llvm
in the FreeBSD source tree?  It seems like it is handy to have.
However, if it is better to only have it in the port and not in src, I
understand.

--
Craig


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

Re: clang and scanbuild

[Craig Rodrigues]

On Mon, Feb 16, 2015 at 1:42 PM, Brooks Davis  wrote:

> On Mon, Feb 16, 2015 at 01:21:34PM -0800, Craig Rodrigues wrote:
> > On Wed, Feb 11, 2015 at 1:43 PM, Dimitry Andric  wrote:
> >
> > >
> > > Yes, choose either lang/clang-devel, or lang/clangXY, where XY is the
> > > version you are interested in.
> > >
> > >
> > > >   (2)  is there enough llvm source in FreeBSD that we can build this
> in
> > > > FreeBSD instead of checking out llvm source?
> > >
> > > You can already run the analyzers with the clang executable in base,
> > > unless you built your world using WITHOUT_CLANG_FULL.  You do need perl
> > > installed, of course.
> > >
> > >
> > Nice!  I did this:
> >
> > pkg install lang/clang-devel
> > export PATH=$PATH:/usr/local/llvm-devel/bin
> > scan-build cc a.c
> >
> > scan-build: Using '/usr/local/llvm-devel/bin/clang' for static analysis
> > a.c:10:10: warning: Use of memory after it is freed
> > a[5] ='b';
> >  ^
> > 1 warning generated.
> > scan-build: 1 bug found.
> > scan-build: Run 'scan-view /tmp/scan-build-2015-02-16-211517-60875-1' to
> > examine bug reports.
> >
> > scan-view /tmp/scan-build-2015-02-16-211517-60875-1
> > Traceback (most recent call last):
> >   File "/usr/local/llvm-devel/bin/scan-view", line 131, in 
> > main()
> >   File "/usr/local/llvm-devel/bin/scan-view", line 128, in main
> > run(port, options, root)
> >   File "/usr/local/llvm-devel/bin/scan-view", line 57, in run
> > import ScanView
> > ImportError: No module named ScanView
> >
> >
> > It looks like some stuff for scan-view is missing from the port.  Do you
> > have any
> > ideas offhand what is missing?  It's not so important, because the
> > results of scan-build can be opened up in any web browser, independently
> of
> > scan-view.
>
> You should use the wrappers in /usr/local/bin (e.g. scan-view-devel) as
> they set up
> the environment so modules can be found.
>

Ah, OK!  scan-view-devel worked.  It might be nice to have a patch in the
port
which changes the message from scan-build to tell folks to invoke
scan-view-devel instead of scan-view.

--
Craig
___
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"

Failed to build with external toolchain

[Craig Rodrigues]

Hi,

Based on this mail:

https://lists.freebsd.org/pipermail/freebsd-current/2014-November/053577.html

I created this script to build HEAD with amd64-gcc:
https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh

However, when I ran the script, I got this error:

https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/6/console

Any ideas what the problem might be?

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

[Craig Rodrigues]

On Tue, Mar 3, 2015 at 9:17 AM, Dimitry Andric  wrote:

> On 03 Mar 2015, at 09:00, Craig Rodrigues  wrote:
> CXXFLAGS+= -D_LIBCPP_HAS_NO_ADVANCED_SFINAE
>
> to the make.conf file you use for building.
>

Thanks for the tip.  I added that to make.conf, but now
I am getting a different error involving unknown compiler flags:

https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/13/console

Any ideas?

Thanks.

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

[Craig Rodrigues]

Hi,

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?

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

[Craig Rodrigues]

On Sat, Mar 7, 2015 at 3:48 PM, Dimitry Andric  wrote:

> On 07 Mar 2015, at 21:12, Craig Rodrigues  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.
>


Oh, OK.  So if I set CROSS_TOOLCHAIN=amd64-gcc,

(1)  /usr/local/share/toolchains/amd64-gcc.mk is included

(2)  X_COMPILER_TYPE=gcc is defined in (1)

(3)   This code is hit in Makefile.inc1:

.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++
DEPFLAGS+=  -I${WORLDTMP}/usr/include/c++/v1
.else
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}


So does this mean that --sysroot is not set?
Should it be?

--
Craig
___
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"

External toolchain build failing due to missing --sysroot

[Craig Rodrigues]

Warner,

I can't get the external toolchain build of CURRENT to work,
because --sysroot seems to be missing in some places.

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?

--
Craig
___
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: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Craig Rodrigues]

On Sun, Mar 22, 2015 at 11:26 AM,  wrote:

> See 
>

Can someone with toolchain expertise look at this?
After the clang 3.6.1 import, /bin/expr behaves differently.

With clang 3.5.0:

# expr 4611686018427387904 + 4611686018427387904
expr: overflow

With clang 3.6.1:

# expr 4611686018427387904 + 4611686018427387904
-9223372036854775808

--
Craig
___
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: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Craig Rodrigues]

On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric  wrote:

>
> Ah right, that was on i386, on amd64 it does result in -2^63.  It is
> indeed caused by reliance on signed integer wrapping.
>
> This diff should fix it, without rewriting the utility:
>
> Index: bin/expr/Makefile
> ===
> --- bin/expr/Makefile   (revision 280156)
> +++ bin/expr/Makefile   (working copy)
> @@ -6,6 +6,9 @@ PROG=   expr
>  SRCS=  expr.y
>  YFLAGS=
>
> +# expr relies on signed integer wrapping
> +CFLAGS+= -fwrapv
> +
>  NO_WMISSING_VARIABLE_DECLARATIONS=
>
>  .if ${MK_TESTS} != "no"
>


Well, another alternative is to patch expr.y:

Index: expr.y
===
--- expr.y  (revision 280353)
+++ expr.y  (working copy)
@@ -393,7 +393,7 @@
 }

 void
-assert_plus(intmax_t a, intmax_t b, intmax_t r)
+assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
 {
/*
 * sum of two positive numbers must be positive,
@@ -420,7 +420,7 @@
 }

 void
-assert_minus(intmax_t a, intmax_t b, intmax_t r)
+assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
 {
/* special case subtraction of INTMAX_MIN */
if (b == INTMAX_MIN && a < 0)


There were already some patches previously done to this
file to add "volatile", so maybe this would be OK to do.

What do you think?

--
Craig
___
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: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Craig Rodrigues]

On Sun, Mar 22, 2015 at 2:36 PM, Dimitry Andric  wrote:

> On 22 Mar 2015, at 22:32, Craig Rodrigues  wrote:
> >
> > On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric  wrote:
> >
> > Ah right, that was on i386, on amd64 it does result in -2^63.  It is
> indeed caused by reliance on signed integer wrapping.
> >
> > This diff should fix it, without rewriting the utility:
> >
> > Index: bin/expr/Makefile
> > ===
> > --- bin/expr/Makefile   (revision 280156)
> > +++ bin/expr/Makefile   (working copy)
> > @@ -6,6 +6,9 @@ PROG=   expr
> >  SRCS=  expr.y
> >  YFLAGS=
> >
> > +# expr relies on signed integer wrapping
> > +CFLAGS+= -fwrapv
> > +
> >  NO_WMISSING_VARIABLE_DECLARATIONS=
> >
> >  .if ${MK_TESTS} != "no"
> >
> >
> > Well, another alternative is to patch expr.y:
> >
> > Index: expr.y
> > ===
> > --- expr.y  (revision 280353)
> > +++ expr.y  (working copy)
> > @@ -393,7 +393,7 @@
> >  }
> >
> >  void
> > -assert_plus(intmax_t a, intmax_t b, intmax_t r)
> > +assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
> >  {
> > /*
> >  * sum of two positive numbers must be positive,
> > @@ -420,7 +420,7 @@
> >  }
> >
> >  void
> > -assert_minus(intmax_t a, intmax_t b, intmax_t r)
> > +assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
> >  {
> > /* special case subtraction of INTMAX_MIN */
> > if (b == INTMAX_MIN && a < 0)
> >
> >
> > There were already some patches previously done to this
> > file to add "volatile", so maybe this would be OK to do.
> >
> > What do you think?
>
> Volatile is not the solution, it is completely orthogonal.  The correct
> way would be to use unsigned integers, for which wrapping is defined,
> then convert those back and forth when presenting the results to the
> user.
>

OK, converting expr.y to use unsigned integers would require a bit of work.

Can you commit your patch to the Makefile?  It fixes the problem for now.

--
Craig
___
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: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Craig Rodrigues]

On Sun, Mar 22, 2015 at 3:01 PM, Craig Rodrigues 
wrote:

>
>
> On Sun, Mar 22, 2015 at 2:36 PM, Dimitry Andric  wrote:
>
>> On 22 Mar 2015, at 22:32, Craig Rodrigues  wrote:
>> >
>> > On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric 
>> wrote:
>> >
>> > Ah right, that was on i386, on amd64 it does result in -2^63.  It is
>> indeed caused by reliance on signed integer wrapping.
>> >
>> > This diff should fix it, without rewriting the utility:
>> >
>> > Index: bin/expr/Makefile
>> > ===
>> > --- bin/expr/Makefile   (revision 280156)
>> > +++ bin/expr/Makefile   (working copy)
>> > @@ -6,6 +6,9 @@ PROG=   expr
>> >  SRCS=  expr.y
>> >  YFLAGS=
>> >
>> > +# expr relies on signed integer wrapping
>> > +CFLAGS+= -fwrapv
>> > +
>> >  NO_WMISSING_VARIABLE_DECLARATIONS=
>> >
>> >  .if ${MK_TESTS} != "no"
>> >
>> >
>> > Well, another alternative is to patch expr.y:
>> >
>> > Index: expr.y
>> > ===
>> > --- expr.y  (revision 280353)
>> > +++ expr.y  (working copy)
>> > @@ -393,7 +393,7 @@
>> >  }
>> >
>> >  void
>> > -assert_plus(intmax_t a, intmax_t b, intmax_t r)
>> > +assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
>> >  {
>> > /*
>> >  * sum of two positive numbers must be positive,
>> > @@ -420,7 +420,7 @@
>> >  }
>> >
>> >  void
>> > -assert_minus(intmax_t a, intmax_t b, intmax_t r)
>> > +assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
>> >  {
>> > /* special case subtraction of INTMAX_MIN */
>> > if (b == INTMAX_MIN && a < 0)
>> >
>> >
>> > There were already some patches previously done to this
>> > file to add "volatile", so maybe this would be OK to do.
>> >
>> > What do you think?
>>
>> Volatile is not the solution, it is completely orthogonal.  The correct
>> way would be to use unsigned integers, for which wrapping is defined,
>> then convert those back and forth when presenting the results to the
>> user.
>>
>
> OK, converting expr.y to use unsigned integers would require a bit of work.
>
> Can you commit your patch to the Makefile?  It fixes the problem for now.
>
>
Thanks for committing the fix.  I wasn't aware of this topic, but it is
explained
quite nicely in this LLVM blog post:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html#signed_overflow

Do you think we should further change expr.y with something like this:

Index: expr.y
===
--- expr.y  (revision 280357)
+++ expr.y  (working copy)
@@ -445,12 +445,13 @@
 }

 /*
- * We depend on undefined behaviour giving a result (in r).
- * To test this result, pass it as volatile.  This prevents
- * optimizing away of the test based on the undefined behaviour.
+ * We depend on undefined signed integer overflow behaviour
+ * giving a result (in r).
+ * This file must be compiled with the "-fwrapv" compiler
+ * flag which forces defined behavior for signed integer overflow.
  */
 void
-assert_times(intmax_t a, intmax_t b, volatile intmax_t r)
+assert_times(intmax_t a, intmax_t b, intmax_t r)
 {
/*
 * If the first operand is 0, no overflow is possible,


--
Craig
___
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"

CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import

[Craig Rodrigues]

Hi,

I tried to build HEAD with gcc 4.9.1 after the latest clang 3.6.0 import,
and am getting
new build failures related to C++ such as:

/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/c++/v1/type_traits:881:87:
error: use of deleted function
'clang::Sema::TypoExprState::TypoExprState(const
clang::Sema::TypoExprState&)'

 
sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T1>()))
 == 1

See full build logs here:
https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/21/console

Any ideas what the problem might be?

Thanks.

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

[Craig Rodrigues]

On Sat, Mar 7, 2015 at 3:48 PM, Dimitry Andric  wrote:

> On 07 Mar 2015, at 21:12, Craig Rodrigues  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?
--
Craig
___
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

[Craig Rodrigues]

On Tue, Mar 24, 2015 at 8:39 PM, Warner Losh  wrote:

>
>
> 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
>
>
The following worked for me.  Is it OK to commit?

Index: Makefile.inc1
===
--- Makefile.inc1   (revision 280353)
+++ Makefile.inc1   (working copy)
@@ -375,10 +375,14 @@
 .endif
 .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++
 DEPFLAGS+= -I${WORLDTMP}/usr/include/c++/v1
+.if ${COMPILER_VERSION} > 40201
+XCFLAGS+=  --sysroot=${WORLDTMP} ${BFLAGS}
+XCXXFLAGS+=--sysroot=${WORLDTMP} ${BFLAGS}
+.endif
 .else
 TARGET_ABI?=   unknown
 TARGET_TRIPLE?=
${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd11.0
 XCFLAGS+=  -target ${TARGET_TRIPLE}
 XCFLAGS+=  --sysroot=${WORLDTMP} ${BFLAGS}

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

[Craig Rodrigues]

On Thu, Mar 26, 2015 at 11:47 AM, Warner Losh  wrote:

>
> > On Mar 26, 2015, at 2:12 AM, Craig Rodrigues 
> wrote:
>
> OK. I have a bit of egg on my face...
>
> The test is for X_COMPILER_TYPE, so COMPILER_VERSION isn't relevant. It's
> always outside the tree.
> So your original patch is correct. Please go ahead and commit that and
> accept my apologies for the wild goose chase.
>

Okee dokee, I committed my original patch:
http://lists.freebsd.org/pipermail/svn-src-all/2015-March/101492.html

No worries about geese.  External toolchain support is important to the
future of FreeBSD, and I appreciate your work.
I'm just trying to help as best I can by testing things, reporting
problems, and fixing things where I can.

--
Craig
___
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: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import

[Craig Rodrigues]

On Mon, Mar 23, 2015 at 12:12 AM, Dimitry Andric  wrote:

> On 23 Mar 2015, at 01:49, Craig Rodrigues  wrote:
> >
> > Hi,
> >
> > I tried to build HEAD with gcc 4.9.1 after the latest clang 3.6.0 import,
> > and am getting
> > new build failures related to C++ such as:
> >
> >
> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/c++/v1/type_traits:881:87:
> > error: use of deleted function
> > 'clang::Sema::TypoExprState::TypoExprState(const
> > clang::Sema::TypoExprState&)'
> >
> >
> sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T1>()))
> > == 1
> >
> > See full build logs here:
> >
> https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/21/console
> >
> > Any ideas what the problem might be?
>
> Yes, this is a bug in libc++, when compiling it with newer versions of
> gcc.  I reported this upstream some time ago: https://llvm.org/PR22771
>
> Still haven't had enough time to test Eric Fiselier's patch for it.  I
> hope I see the bottom of my TODO list anytime soon...
>
> -Dimitry
>
>

Eric Fiselier's patch in http://reviews.llvm.org/D8461 works for me.
I could compile libc++ with gcc 4.9 with this patch.

There are other gcc 4.9 compilation problems, but I will report those
separately.
--
Craig
___
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"

lldb compilation problem with gcc 4.9

[Craig Rodrigues]

Hi,

I had problems compiling lldb with gcc 4.9.

See problem description plus patch which I submitted upstream:

https://llvm.org/bugs/show_bug.cgi?id=23051

--
Craig
___
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: lldb compilation problem with gcc 4.9

[Craig Rodrigues]

On Fri, Mar 27, 2015 at 10:03 PM, Craig Rodrigues 
wrote:

> Hi,
>
> I had problems compiling lldb with gcc 4.9.
>
> See problem description plus patch which I submitted upstream:
>
> https://llvm.org/bugs/show_bug.cgi?id=23051
>
>
My patch was accepted upstream:

http://llvm.org/viewvc/llvm-project?view=revision&revision=233478

--
Craig
___
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"

Failed to build rescue with gcc 4.9

[Craig Rodrigues]

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

[Craig Rodrigues]

On Sat, Mar 28, 2015 at 2:34 PM, Craig Rodrigues 
wrote:

>
>
> 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
>
>
Hmm, so file reports that it is an ELF file, but readelf barfs on the file.

I have the file here for anyone who wants to look at it:

http://people.freebsd.org/~rodrigc/cat.lo

# file cat.lo ; readelf -a cat.lo
cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), stripped
readelf: Error: Unable to read in 0x40 bytes of section headers
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - FreeBSD
  ABI Version:   0
  Type:  REL (Relocatable file)
  Machine:   Advanced Micro Devices X86-64
  Version:   0x1
  Entry point address:   0x0
  Start of program headers:  0 (bytes into file)
  Start of section headers:  51092930964640 (bytes into file)
  Flags: 0x0
  Size of this header:   64 (bytes)
  Size of program headers:   0 (bytes)
  Number of program headers: 0
  Size of section headers:   64 (bytes)
  Number of section headers: 19
  Section header string table index: 16
readelf: Error: Unable to read in 0x4c0 bytes of section headers
readelf: Error: Section headers are not available!
Abort trap (core dumped)

--
Craig
___
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"

Fails to build sys/i386/boot2 with gcc 4.9

[Craig Rodrigues]

Hi,

To work around the problems build rescue, this time I used a build host
running FreeBSD-CURRENT at svn revision r280353

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

Buildling sys/i386/boot2 failed:

===> sys/boot/i386/boot2 (all)
objcopy -S -O binary boot1.out boot1
dd if=/dev/zero of=boot2.ldr bs=512 count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.34 secs (14989607 bytes/sec)
/usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem
/usr/obj/opt2/branches/head/tmp/usr/include
-L/usr/obj/opt2/branches/head/tmp/usr/lib
--sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/
-fomit-frame-pointer  -mrtd  -mregparm=3  -DUSE_XREAD  -DUFS1_AND_UFS2
-DFLAGS=0x80  -DSIOPRT=0x3f8  -DSIOFMT=0x3  -DSIOSPD=9600
-I/opt2/branches/head/sys/boot/i386/boot2/../../common
-I/opt2/branches/head/sys/boot/i386/boot2/../btx/lib -I.  -Wall
-Waggregate-return -Wbad-function-cast -Wcast-align  -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs  -Wpointer-arith -Wshadow
-Wstrict-prototypes -Wwrite-strings  -Winline -march=i386 -ffreestanding
-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32
-std=gnu99-Os  -fno-guess-branch-probability  -fno-unit-at-a-time
--param max-inline-insns-single=100 -mpreferred-stack-boundary=2  -S -o
boot2.s.tmp /opt2/branches/head/sys/boot/i386/boot2/boot2.c
/opt2/branches/head/sys/boot/i386/boot2/boot2.c: In function 'parse':
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:484:6: warning: suggest
parentheses around assignment used as truth value [-Wparentheses]
  if (k = ep - arg) {
  ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c: In function 'load':
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:334:9: warning: called from
here [-Winline]
 if (xfsread(ino, &hdr, sizeof(hdr)))
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:341:6: warning: called from
here [-Winline]
  if (xfsread(ino, p, hdr.ex.a_text))
  ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:344:6: warning: called from
here [-Winline]
  if (xfsread(ino, p, hdr.ex.a_data))
  ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:349:10: warning: called
from here [-Winline]
  if (xfsread(ino, ep + j, sizeof(ep[0])))
  ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:357:10: warning: called
from here [-Winline]
  if (xfsread(ino, p, ep[i].p_filesz))
  ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:365:10: warning: called
from here [-Winline]
  if (xfsread(ino, &es, sizeof(es)))
  ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
failed in call to 'xfsread': call is unlikely and code size would grow
[-Winline]
 xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
 ^
/opt2/branches/head/sys/boot/i386/boot2/boot2.c:371:7: warning: called from
here [-Winline]
   if (xfsread(ino, p, es[i].sh_size))
   ^
sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s
rm -f boot2.s.tmp
/usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem
/usr/obj/opt2/branches/head/tmp/usr/include
-L/usr/obj/opt2/branches/head/tmp/usr/lib
--sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/
-m32 -c boot2.s
/usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem
/usr/obj/opt2/branches/head/tmp/usr/include
-L/usr/obj/opt2/branches/head/tmp/usr/lib
--sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/
-fomit-frame-pointer  -mrtd  -mregparm=3  -DUSE_XREAD  -DUFS1_AND_UFS2
-DFLAGS=0x80  -DSIOPRT=0x3f8  -DSIOFMT=0x3  -DSIOSPD=9600
-I/opt2/branches/head/sys/boot/i386/boot2/../../c

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

[Craig Rodrigues]

On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh  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? :)

--
Craig
___
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"

Failed to build usr.bin/clang/clang with gcc 4.9

[Craig Rodrigues]

Hi,


When building with gcc 4.9, I am getting unresolved symbols at link
time when building usr.bin/clang/clang.  Here is one error message:

/usr/obj/opt2/branches/head/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclang
codegen.a(ModuleBuilder.o): In function `(anonymous
namespace)::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext&)':
ModuleBuilder.cpp:(.text+0x113): undefined reference to
`clang::CodeGen::CodeGenModule::clear()'

There are many more errors like that in  my full build log here:

https://people.freebsd.org/~rodrigc/gcc/buildworld.2015_03_29.log.txt


Any ideas?

--
Craig
___
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 usr.bin/clang/clang with gcc 4.9

[Craig Rodrigues]

On Sun, Mar 29, 2015 at 1:52 PM, Dimitry Andric  wrote:
>
>
> And none of these prints any compilation command lines?  Are you running
> with make -s, by any chance?  If so, try removing it so we can see how
> the various source files are being compiled.


I am not using make -s.  If you  look at the log file, the full make
invocation I used
is captured at the top of the log file.  I used NO_CLEAN and NO_KERNELCLEAN.

I wiped out the object tree, and tried again.  I managed to successfully
buildworld, as long as I skipped building all the boot directories.

Here is the new log file:

https://people.freebsd.org/~rodrigc/gcc/buildworld.2015_03_29_2.log.txt

There are many warnings which need to be cleaned up over time.  I
saw this one which looked a bit weird:

/usr/local/bin/x86_64-freebsd-ld: error in
/usr/obj/opt2/branches/head/lib32/usr/lib32/crt1.o(.eh_frame);
no .eh_frame_hdr table will be created.

--
Craig
___
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: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import

[Craig Rodrigues]

On Mon, Mar 23, 2015 at 12:12 AM, Dimitry Andric  wrote:
>
> On 23 Mar 2015, at 01:49, Craig Rodrigues  wrote:
> >
> > Hi,
> >
> > I tried to build HEAD with gcc 4.9.1 after the latest clang 3.6.0
import,
> > and am getting
> > new build failures related to C++ such as:
> >
> >
/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/c++/v1/type_traits:881:87:
> > error: use of deleted function
> > 'clang::Sema::TypoExprState::TypoExprState(const
> > clang::Sema::TypoExprState&)'
> >
> >
sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T1>()))
> > == 1
> >
> > See full build logs here:
> >
https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/21/console
> >
> > Any ideas what the problem might be?
>
> Yes, this is a bug in libc++, when compiling it with newer versions of
> gcc.  I reported this upstream some time ago: https://llvm.org/PR22771
>
> Still haven't had enough time to test Eric Fiselier's patch for it.  I
> hope I see the bottom of my TODO list anytime soon...
>
> -Dimitry
>

Hi,

I just updated my tree to include your latest fixes such as r28064.

I'm still getting this:

 from
/builds/FreeBSD_HEAD_external_toolchain_gcc/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/DeclBase.cpp:14:
/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/c++/v1/type_traits:845:28:
error:   initializing argument 1 of 'char
std::__1::__is_convertible_imp::__test(_Tp) [with _Tp =
clang::StoredDeclsList]'
 template  char  __test(_Tp);
^
*** [DeclBase.o] Error code 1

make[6]: stopped in
/builds/FreeBSD_HEAD_external_toolchain_gcc/lib/clang/libclangast

Any ideas?


See:

https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/27/console

--

Craig
___
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: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import

[Craig Rodrigues]

On Tue, Mar 31, 2015 at 11:20 AM, Dimitry Andric  wrote:

> On 31 Mar 2015, at 20:13, Dimitry Andric  wrote:
> ...
> > but then:
> >
> > + patch
> > Hmm...  Looks like a unified diff to me...
> > The text leading up to this was:
> > --
> > |Index: contrib/libc++/include/type_traits
> > |===
> > |--- contrib/libc++/include/type_traits (revision 280762)
> > |+++ contrib/libc++/include/type_traits (working copy)
> > --
> > Patching file contrib/libc++/include/type_traits using Plan A...
> > Reversed (or previously applied) patch detected!  Assume -R? [y]
> > Hunk #1 succeeded at 842.
> > Hunk #2 succeeded at 877.
> > Hmm...  Ignoring the trailing garbage.
> > done
> >
> > E.g., it undoes the change to type_traits that was merged in the
> subversion update.
>
>
OK, I undid the patch.  Now the clang and libc++ parts build, but I'm
still getting problems building rescue:

https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/29/console

--
Craig
___
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: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import

[Craig Rodrigues]

On Tue, Mar 31, 2015 at 12:48 PM, Dimitry Andric  wrote:

> On 31 Mar 2015, at 21:38, Craig Rodrigues  wrote:
> >
> > On Tue, Mar 31, 2015 at 11:20 AM, Dimitry Andric 
> wrote:
> >
> >> On 31 Mar 2015, at 20:13, Dimitry Andric  wrote:
> >> ...
> >>> but then:
> >>>
> >>> + patch
> >>> Hmm...  Looks like a unified diff to me...
> >>> The text leading up to this was:
> >>> --
> >>> |Index: contrib/libc++/include/type_traits
> >>> |===
> >>> |--- contrib/libc++/include/type_traits (revision 280762)
> >>> |+++ contrib/libc++/include/type_traits (working copy)
> >>> --
> >>> Patching file contrib/libc++/include/type_traits using Plan A...
> >>> Reversed (or previously applied) patch detected!  Assume -R? [y]
> >>> Hunk #1 succeeded at 842.
> >>> Hunk #2 succeeded at 877.
> >>> Hmm...  Ignoring the trailing garbage.
> >>> done
> >>>
> >>> E.g., it undoes the change to type_traits that was merged in the
> >> subversion update.
> >>
> >>
> > OK, I undid the patch.  Now the clang and libc++ parts build, but I'm
> > still getting problems building rescue:
> >
> >
> https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/29/console
>
> Hm, that is strange.  I have just completed a build with
> amd64-xtoolchain-gcc, and apart from boot2, everything worked...
>
> What does readelf say when you run it on the cat.lo file which is
> complained about in the log?  And what happens if you delete it, and
> restart the build?
>

See:
https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001545.html
___
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: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import

[Craig Rodrigues]

On Tue, Mar 31, 2015 at 1:41 PM, Dimitry Andric  wrote:

> On 31 Mar 2015, at 22:06, Craig Rodrigues  wrote:
> >
> > On Tue, Mar 31, 2015 at 12:48 PM, Dimitry Andric 
> wrote:
> > On 31 Mar 2015, at 21:38, Craig Rodrigues  wrote:
> > >
> > > On Tue, Mar 31, 2015 at 11:20 AM, Dimitry Andric 
> wrote:
> > >
> > >> On 31 Mar 2015, at 20:13, Dimitry Andric  wrote:
> > >> ...
> > >>> but then:
> > >>>
> > >>> + patch
> > >>> Hmm...  Looks like a unified diff to me...
> > >>> The text leading up to this was:
> > >>> --
> > >>> |Index: contrib/libc++/include/type_traits
> > >>> |===
> > >>> |--- contrib/libc++/include/type_traits (revision 280762)
> > >>> |+++ contrib/libc++/include/type_traits (working copy)
> > >>> --
> > >>> Patching file contrib/libc++/include/type_traits using Plan A...
> > >>> Reversed (or previously applied) patch detected!  Assume -R? [y]
> > >>> Hunk #1 succeeded at 842.
> > >>> Hunk #2 succeeded at 877.
> > >>> Hmm...  Ignoring the trailing garbage.
> > >>> done
> > >>>
> > >>> E.g., it undoes the change to type_traits that was merged in the
> > >> subversion update.
> > >>
> > >>
> > > OK, I undid the patch.  Now the clang and libc++ parts build, but I'm
> > > still getting problems building rescue:
> > >
> > >
> https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/29/console
> >
> > Hm, that is strange.  I have just completed a build with
> > amd64-xtoolchain-gcc, and apart from boot2, everything worked...
> >
> > What does readelf say when you run it on the cat.lo file which is
> > complained about in the log?  And what happens if you delete it, and
> > restart the build?
> >
> > See:
> >
> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001545.html
>
> 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?
>



Well my build host is 10.1-RELEASE, so maybe there are changes
that went into 10-STABLE after 10.1 that prevent this from working.

I'll give a shot at hacking things and let you know how far I get.
--
Craig
___
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"

Kernel compilation failures with gcc 4.9

[Craig Rodrigues]

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

Any ideas?
--
Craig
___
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: Kernel compilation failures with gcc 4.9

[Craig Rodrigues]

On Tue, Mar 31, 2015 at 4:55 PM, Warner Losh  wrote:

>
> >
> > 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.
>
>
John-Mark,

Do you have time to help fix compilation with gcc 4.9 of AESNI in the
kernel?
It currently does not compile with gcc 4.9.

See my original bug report here:
https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001577.html

We are trying to fix the kernel build enough with gcc 4.9 so that
we can at least set up a Jenkins continuous build (with -Werror turned off
initially).

Thanks.
--
Craig
___
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: Kernel compilation failures with gcc 4.9

[Craig Rodrigues]

On Tue, Mar 31, 2015 at 10:10 PM, John-Mark Gurney  wrote:
>
>
> This is an issue w/ gcc 4.9's headers... It is including stdlib.h,
> via mm_malloc.h which is conflicting w/ sys/malloc.h's version of free..
>
> kan wrapped the include of mm_malloc.h in an #if __STDC_HOSTED__ which is
> why gcc 4.2 doesn't have the issue per my request a couple years ago:
> https://svnweb.freebsd.org/changeset/base/r242182
>
> A similar fix needs to be applied here...


Interesting, so r242182 does this inside the gcc header file itself:

--- head/contrib/gcc/config/i386/xmmintrin.h 2011/03/14 13:31:34 219639
+++ head/contrib/gcc/config/i386/xmmintrin.h 2012/10/27 17:39:36 242182
@@ -39,7 +39,9 @@
 #include 

 /* Get _mm_malloc () and _mm_free ().  */
+#if __STDC_HOSTED__
 #include 
+#endif


We would need to apply the same patch to the gcc header
file in gcc 4.9.  I'm not sure if that will be allowed, since the
direction we are going in is to support gcc as an external toolchain,
unless we can push that change upstream to gcc.
I'll let the toolchain@ team decide that one.

The alternative is to patch the aesni header files.  This patch is
a bit gross, but I was able to compile an entire GENERIC kernel (including
aesni) with gcc 4.9:

Index: aesni/aesencdec.h
===
--- aesni/aesencdec.h(revision 280912)
+++ aesni/aesencdec.h(working copy)
@@ -27,6 +27,11 @@
  *
  */

+#ifdef _KERNEL
+/* Suppress inclusion of gcc's mm_malloc.h header */
+#define _MM_MALLOC_H_INCLUDED 1
+#endif
+
 #include 

 static inline void
Index: aesni/aesni_ghash.c
===
--- aesni/aesni_ghash.c(revision 280912)
+++ aesni/aesni_ghash.c(working copy)
@@ -71,6 +71,11 @@
 #include 
 #endif

+#ifdef _KERNEL
+/* Suppress inclusion of gcc's mm_malloc.h header */
+#define _MM_MALLOC_H_INCLUDED 1
+#endif
+
 #include 
 #include 
 #include 
Index: aesni/aesni_wrap.c
===
--- aesni/aesni_wrap.c(revision 280912)
+++ aesni/aesni_wrap.c(working copy)
@@ -45,6 +45,11 @@
 #include 

 #include "aesencdec.h"
+#ifdef _KERNEL
+/* Suppress inclusion of gcc's mm_malloc.h header */
+#define _MM_MALLOC_H_INCLUDED 1
+#endif
+
 #include 

 MALLOC_DECLARE(M_AESNI);


What's the best way to move forward on this?

--
Craig
___
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: FYI: Things that I've noticed for powerpc64-xtoolchain-gcc...

[Craig Rodrigues]

On Sun, Mar 29, 2015 at 1:13 AM, Mark Millard  wrote:

> You [Craig Rodrigues] seem to be checking some ??-xtoolchain-gcc things
> officially. I've some user-experience notes from happening to use
> powerpc64-xtoolchain-gcc in my exploration of FreeBSD. Hopefully some of it
> might be of interest. It groups together information from various notices
> as I was doing the explorations.
>

Thanks for doing these investigations.
However, I have to say that your e-mails contain too much detail,
and seem almost like rambling brain dumps.  They are hard to follow, and I
usually stop reading them about one quarter
of the way through the e-mail.  My mind can't absorb all the detail you
are providing.  I cannot speak for other people on the toolchain@ team,
but I wouldn't be surprised if there are other people who feel the same as
I do.

In future, I suggest that you cut down your e-mails to be very concise.
If you can extract the bare minimum of error message, and put that in
the e-mail, with minimal discussion, that would be the best way to start.
For your further analysis and full logs, put those on a web site.
In your e-mail, you can put a URL pointer and tell people if they are still
interested in looking at the problem, they can get the full logs and further
analysis from your web site.

It is even better if you can supply patches which you think fix the problem.

That's the strategy that I have used, and I have found that it has
worked very well, and the toolchain@ team has been super responsive.

toolchain@ folks are very busy, so if you send e-mails which are more
work to digest than the bugs they are trying to fix, they will tend to
ignore
your e-mails.

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

[Craig Rodrigues]

On Sat, Mar 28, 2015 at 2:34 PM, Craig Rodrigues 
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  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 u

Re: Failed to build rescue with gcc 4.9

[Craig Rodrigues]

On Thu, Apr 2, 2015 at 8:27 AM, Craig Rodrigues  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.

--
Craig
___
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: Fails to build sys/i386/boot2 with gcc 4.9

[Craig Rodrigues]

On Sat, Mar 28, 2015 at 4:05 PM, Craig Rodrigues 
wrote:

> Hi,
>
> To work around the problems build rescue, this time I used a build host
> running FreeBSD-CURRENT at svn revision r280353
>
> 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
>
> Buildling sys/i386/boot2 failed:
>
> ===> sys/boot/i386/boot2 (all)
> objcopy -S -O binary boot1.out boot1
> dd if=/dev/zero of=boot2.ldr bs=512 count=1
> 1+0 records in
> 1+0 records out
> 512 bytes transferred in 0.34 secs (14989607 bytes/sec)
> /usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem
> /usr/obj/opt2/branches/head/tmp/usr/include
> -L/usr/obj/opt2/branches/head/tmp/usr/lib
> --sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/
> -fomit-frame-pointer  -mrtd  -mregparm=3  -DUSE_XREAD  -DUFS1_AND_UFS2
> -DFLAGS=0x80  -DSIOPRT=0x3f8  -DSIOFMT=0x3  -DSIOSPD=9600
> -I/opt2/branches/head/sys/boot/i386/boot2/../../common
> -I/opt2/branches/head/sys/boot/i386/boot2/../btx/lib -I.  -Wall
> -Waggregate-return -Wbad-function-cast -Wcast-align  -Wmissing-declarations
> -Wmissing-prototypes -Wnested-externs  -Wpointer-arith -Wshadow
> -Wstrict-prototypes -Wwrite-strings  -Winline -march=i386 -ffreestanding
> -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32
> -std=gnu99-Os  -fno-guess-branch-probability  -fno-unit-at-a-time
> --param max-inline-insns-single=100 -mpreferred-stack-boundary=2  -S -o
> boot2.s.tmp /opt2/branches/head/sys/boot/i386/boot2/boot2.c
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c: In function 'parse':
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:484:6: warning: suggest
> parentheses around assignment used as truth value [-Wparentheses]
>   if (k = ep - arg) {
>   ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c: In function 'load':
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
> failed in call to 'xfsread': call is unlikely and code size would grow
> [-Winline]
>  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
>  ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:334:9: warning: called
> from here [-Winline]
>  if (xfsread(ino, &hdr, sizeof(hdr)))
>  ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
> failed in call to 'xfsread': call is unlikely and code size would grow
> [-Winline]
>  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
>  ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:341:6: warning: called
> from here [-Winline]
>   if (xfsread(ino, p, hdr.ex.a_text))
>   ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
> failed in call to 'xfsread': call is unlikely and code size would grow
> [-Winline]
>  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
>  ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:344:6: warning: called
> from here [-Winline]
>   if (xfsread(ino, p, hdr.ex.a_data))
>   ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
> failed in call to 'xfsread': call is unlikely and code size would grow
> [-Winline]
>  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
>  ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:349:10: warning: called
> from here [-Winline]
>   if (xfsread(ino, ep + j, sizeof(ep[0])))
>   ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
> failed in call to 'xfsread': call is unlikely and code size would grow
> [-Winline]
>  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
>  ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:357:10: warning: called
> from here [-Winline]
>   if (xfsread(ino, p, ep[i].p_filesz))
>   ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
> failed in call to 'xfsread': call is unlikely and code size would grow
> [-Winline]
>  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
>  ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:365:10: warning: called
> from here [-Winline]
>   if (xfsread(ino, &es, sizeof(es)))
>   ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining
> failed in call to 'xfsread': call is unlikely and code size would grow
> [-Winline]
>  xfsread(ufs_ino_t inode, void *buf, size_t nbyte)
>  ^
> /opt2/branches/head/sys/boot/i386/boot2/boot2.c:371:7: warning: called
> from here [-Winline]
>if (xfsread(ino, p, es[i].sh_size))
>^
> sed -e &#

[Request for Help] Reducing gcc 4.9 compilation warnings

[Craig Rodrigues]

Hi,

After the latest commits by members of freebsd-toolchain@ ,
I have managed to compile latest CURRENT world and GENERIC
kernel on amd64 with an gcc 4.9 external toolchain by doing:

   pkg install devel/amd64-xtoolchain-gcc
   cd /usr/src
   sed -i "" -e 's/boot2//' sys/boot/i386/Makefile
   make buildworld CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR=
   make buildkernel CROSS_TOOLCHAIN=amd64-gcc NO_WERROR=yes WERROR=


It was necessary to skip boot2 from building because of errors
reported here:
https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-April/001658.html

The boot2 compilation errors still need to be worked on.

However, most other things compile with warnings.  If folks are
interested in looking at the warnings, you can see them here:

https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/warnings17

Please look at these warnings, and if you see places to
patch the code to eliminate the warnings, please submit patches
and commit them if you can.

clang is still going to be the default compiler in the base system,
but it is nice to have FreeBSD compilable by multiple compilers.
--
Craig
___
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: [Request for Help] Reducing gcc 4.9 compilation warnings

[Craig Rodrigues]

On Sun, Apr 19, 2015 at 2:10 AM, Eitan Adler  wrote:

>
> Perhaps it would be useful to do a second run of this, but with a
> modified share/mk to silence the most useless of these warnings?
>
>
Sure, that's fine.  Can you provide a modified share/mk which you think
does the right thing?  We can try it.

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

[Craig Rodrigues]

On Mon, May 18, 2015 at 12:30 PM, Warner Losh  wrote:

>
> > On Mar 20, 2015, at 2:10 PM, Craig Rodrigues 
> 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

--
Craig
___
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"

devel/amd64-xtoolchain-gcc out of date?

[Craig Rodrigues]

Hi,

On a FreeBSD 10.1-RELEASE system I just did:

pkg install devel/amd64-gcc
pkg install devel/amd64-toolchain-gcc

pkg info -o -g '*gcc*'
amd64-gcc-4.9.2_1  devel/amd64-gcc
amd64-xtoolchain-gcc-0.1   devel/amd64-xtoolchain-gcc

The devel/amd64-toolchain-gcc package installs this file:

/usr/local/share/toolchains/gcc.mk:

XCC=/usr/local/bin/x86_64-portbld-freebsd10.0-gcc
XCXX=/usr/local/bin/x86_64-portbld-freebsd10.0-g++
XCPP=/usr/local/bin/x86_64-portbld-freebsd10.0-cpp
CROSS_BINUTILS_PREFIX=/usr/local/x86_64-freebsd/bin/
X_COMPILER_TYPE=gcc

However, the devel/amd64-gcc package installs binaries which are:

/usr/local/bin/x86_64-portbld-freebsd10.1-c++
/usr/local/bin/x86_64-portbld-freebsd10.1-cpp
/usr/local/bin/x86_64-portbld-freebsd10.1-g++
/usr/local/bin/x86_64-portbld-freebsd10.1-gcc
/usr/local/bin/x86_64-portbld-freebsd10.1-gcc-4.9.2
/usr/local/bin/x86_64-portbld-freebsd10.1-gcc-ar
/usr/local/bin/x86_64-portbld-freebsd10.1-gcc-nm
/usr/local/bin/x86_64-portbld-freebsd10.1-gcc-ranlib

So an attempt to cross-compile fails because XCPP
is not pointing to a binary which does not exist.

When will this get fixed in the package repository?

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

Re: clang and scanbuild

[Craig Rodrigues]

On Wed, Feb 11, 2015 at 1:43 PM, Dimitry Andric  wrote:

> Yes, choose either lang/clang-devel, or lang/clangXY, where XY is the
> version you are interested in.
>
>
It looks like scan-build was removed from lang/clang-devel
in July.  Would it be possible to add it back?

Thanks.
--
Craig
___
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: bt_split.c error: dereferencing type-punned pointer will break strict-aliasing rules (powerpc64-xtoolchain use)

[Craig Rodrigues]

On Sun, Oct 4, 2015 at 4:06 AM, Mark Millard  wrote:

>
> /usr/src/lib/libc/db/btree/bt_split.c:548:7: error: dereferencing
> type-punned pointer will break strict-aliasing rules
> [-Werror=strict-aliasing]
>bt_preserve(t, *(pgno_t *)bl->bytes) == RET_ERROR)
>

You will get many of these warnings all over the codebase.
You should add NO_WERROR=
to your make invocation, or put NO_WERROR= in make.conf.

That's what I do here:
https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc4.9/631/consoleFull

--
Craig
___
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"

error: your copy of LLDB does not support scripting.

[Craig Rodrigues]

Hi,

In /etc/make.conf, I put WITH_LLDB="yes"
and rebuilt/reinstalled the world.

I then tried:

(lldb) script
error: your copy of LLDB does not support scripting.

Is there a way to configure LLDB with script support?

--
Craig
___
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: Can we have a toolchain that works?

[Craig Rodrigues]

[Moving discussion to freebsd-toolchain]

Dag,

Regarding your question about a working debugger, due to your problems
debugging
code with the in-tree gdb on latest current, we have a few options:

(1)  Enable WITH_LLDB by default in the make infrastructure, and install
lldb.

   We already have lldb in the tree:
 https://svnweb.freebsd.org/base/head/contrib/llvm/tools/lldb/
   but it is not built by default.

lldb does not have kgdb support though.

(2)  Kick gdb out of the base system, and tell people to install the
devel/gdb port.
   This will install gdb 7.10 from ports.
   This port also installs kgdb

--
Craig
___
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"

[Differential] [Request, 27 lines] D1722: Add -s option to config

[rodrigc (Craig Rodrigues)]

rodrigc created this revision.
rodrigc added reviewers: brooks, imp.
rodrigc added a subscriber: freebsd-toolchain.

REVISION SUMMARY
  This option allows for specifying the directory to use as the location for
  configuration source files.  This option was ported from NetBSD.
  
  Submitted by: Steve Kiernan , Simon Gerraty 

  Obtained from:  Juniper Networks, Inc.
  GitHub Pull Request: https://github.com/freebsd/freebsd/pull/18

TEST PLAN
  Did a "make tinderbox"

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

AFFECTED FILES
  usr.sbin/config/config.8
  usr.sbin/config/main.c

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] D2187: Ensure cross assembler, linker and objcopy are used for the build32 stage

[rodrigc (Craig Rodrigues)]

rodrigc accepted this revision.

BRANCH
  /head

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

To: dim, bapt, emaste, imp, rodrigc
Cc: emaste, 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] [Closed] D1722: Add -s option to config

[rodrigc (Craig Rodrigues)]

rodrigc closed this revision.
rodrigc added a comment.

Committed under rS277904

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] [Request, 16 lines] D2285: gcc 4.9.1 compilation fixes for aesni

[rodrigc (Craig Rodrigues)]

rodrigc created this revision.
rodrigc added a reviewer: jmg.
rodrigc added a subscriber: freebsd-toolchain.

REVISION SUMMARY
  In the version of gcc in the FreeBSD tree, this modification was made to
  the compiler:
  https://svnweb.freebsd.org/base?view=revision&revision=r242182
  
   #if __STDC_HOSTED__
   #include 
   #endif
  
  A similar change was done to clang in the FreeBSD tree:
  https://svnweb.freebsd.org/base?view=revision&revision=r218893
  
  However, for external gcc toolchains, this patch is not in the compiler's 
header
  file.
  
  This patch to FreeBSD's aesni code allows compilation with an external
  gcc toolchain

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

AFFECTED FILES
  sys/crypto/aesni/aesencdec.h
  sys/crypto/aesni/aesni_ghash.c
  sys/crypto/aesni/aesni_wrap.c

To: rodrigc, jmg
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] [Updated, 36 lines] D2285: gcc 4.9.1 compilation fixes for aesni

[rodrigc (Craig Rodrigues)]

rodrigc updated this revision to Diff 4825.
rodrigc added a comment.

OK, here's an updated diff where things are separate out into a different 
header file.

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D2285?vs=4798&id=4825

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

AFFECTED FILES
  sys/crypto/aesni/aesencdec.h
  sys/crypto/aesni/aesni_ghash.c
  sys/crypto/aesni/aesni_os.h

To: rodrigc, jmg
Cc: emaste, dim, 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, 36 lines] D2285: gcc 4.9.1 compilation fixes for aesni

[rodrigc (Craig Rodrigues)]

rodrigc updated this revision to Diff 4840.
rodrigc added a comment.

Change to <>

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D2285?vs=4825&id=4840

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

AFFECTED FILES
  sys/crypto/aesni/aesencdec.h
  sys/crypto/aesni/aesni_ghash.c
  sys/crypto/aesni/aesni_os.h

To: rodrigc, jmg
Cc: kostikbel, emaste, dim, 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] [Closed] D2285: gcc 4.9.1 compilation fixes for aesni

[rodrigc (Craig Rodrigues)]

rodrigc closed this revision.
rodrigc updated this revision to Diff 4852.
rodrigc added a comment.

Closed by commit rS281606 (authored by @rodrigc).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D2285?vs=4840&id=4852#toc

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

AFFECTED FILES
  head/sys/crypto/aesni/aesencdec.h
  head/sys/crypto/aesni/aesni_ghash.c
  head/sys/crypto/aesni/aesni_os.h

To: rodrigc, jmg
Cc: kostikbel, emaste, dim, 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] [Request, 6 lines] D2305: Fix bootstraping of crunchide

[rodrigc (Craig Rodrigues)]

rodrigc created this revision.
rodrigc added reviewers: emaste, imp.
rodrigc added a subscriber: freebsd-toolchain.

REVISION SUMMARY
  When using an external gcc 4.9 toolchain on a FreeBSD 10.1 build host,
  building of the CURRENT branch failed when trying to build rescue.
  
  See this discussion:
  https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-April/001614.html
  https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-April/001616.html

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

AFFECTED FILES
  Makefile.inc1

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] [Abandoned] D2305: Fix bootstraping of crunchide

[rodrigc (Craig Rodrigues)]

rodrigc abandoned this revision.
rodrigc added a comment.

Fixed by rS281659

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] [Request, 22 lines] D2690: In ypbind, eliminate error: dereferencing type-punned pointer will break strict-aliasing rules

[rodrigc (Craig Rodrigues)]

rodrigc created this revision.
rodrigc added reviewers: araujo, bapt, emaste, dim.
rodrigc added a subscriber: freebsd-toolchain.
rodrigc set the repository for this revision to rS FreeBSD src repository.
Herald added a subscriber: imp.

REVISION SUMMARY
  Without this fix, compiling ypbind with gcc 4.9 will give warnings such as 
this:
  
  ```
  /opt2/branches/head/usr.sbin/ypbind/ypbind.c: In function 'rpc_received':
  /opt2/branches/head/usr.sbin/ypbind/ypbind.c:948:2: warning: dereferencing 
type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
*(u_int32_t *)&ybr.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_addr = 
raddrp->sin_addr.s_addr;
^
  ```

REPOSITORY
  rS FreeBSD src repository

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

AFFECTED FILES
  usr.sbin/ypbind/ypbind.c

CHANGE DETAILS
  diff --git a/usr.sbin/ypbind/ypbind.c b/usr.sbin/ypbind/ypbind.c
  --- a/usr.sbin/ypbind/ypbind.c
  +++ b/usr.sbin/ypbind/ypbind.c
  @@ -225,10 +225,10 @@
   
res.ypbind_status = YPBIND_SUCC_VAL;
res.ypbind_resp_u.ypbind_error = 0; /* Success */
  - *(u_int32_t *)&res.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_addr =
  - ypdb->dom_server_addr.sin_addr.s_addr;
  - *(u_short *)&res.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_port =
  - ypdb->dom_server_addr.sin_port;
  + memcpy(&res.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_addr,
  + &ypdb->dom_server_addr.sin_addr.s_addr, sizeof(u_int32_t));
  + memcpy(&res.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_port,
  + &ypdb->dom_server_addr.sin_port, sizeof(u_short));
/*printf("domain %s at %s/%d\n", ypdb->dom_domain,
inet_ntoa(ypdb->dom_server_addr.sin_addr),
ntohs(ypdb->dom_server_addr.sin_port));*/
  @@ -275,8 +275,12 @@
   
bzero(&bindsin, sizeof bindsin);
bindsin.sin_family = AF_INET;
  - bindsin.sin_addr.s_addr = *(u_int32_t 
*)argp->ypsetdom_binding.ypbind_binding_addr;
  - bindsin.sin_port = *(u_short 
*)argp->ypsetdom_binding.ypbind_binding_port;
  + memcpy(&bindsin.sin_addr.s_addr,
  + &argp->ypsetdom_binding.ypbind_binding_addr,
  + sizeof(u_int32_t));
  + memcpy(&bindsin.sin_port,
  + &argp->ypsetdom_binding.ypbind_binding_port,
  + sizeof(u_short));
rpc_received(argp->ypsetdom_domain, &bindsin, 1);
   
return((void *) &result);
  @@ -945,8 +949,10 @@
   
bzero(&ybr, sizeof ybr);
ybr.ypbind_status = YPBIND_SUCC_VAL;
  - *(u_int32_t *)&ybr.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_addr = 
raddrp->sin_addr.s_addr;
  - *(u_short *)&ybr.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_port = 
raddrp->sin_port;
  + memcpy(ybr.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_addr,
  + &raddrp->sin_addr.s_addr, sizeof(u_int32_t));
  + memcpy(&ybr.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_port,
  + &raddrp->sin_port, sizeof(u_short));
   
if (writev(ypdb->dom_lockfd, iov, 2) != iov[0].iov_len + 
iov[1].iov_len) {
syslog(LOG_WARNING, "write: %m");

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

To: rodrigc, araujo, bapt, emaste, dim
Cc: imp, freebsd-toolchain
diff --git a/usr.sbin/ypbind/ypbind.c b/usr.sbin/ypbind/ypbind.c
--- a/usr.sbin/ypbind/ypbind.c
+++ b/usr.sbin/ypbind/ypbind.c
@@ -225,10 +225,10 @@
 
 	res.ypbind_status = YPBIND_SUCC_VAL;
 	res.ypbind_resp_u.ypbind_error = 0; /* Success */
-	*(u_int32_t *)&res.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_addr =
-		ypdb->dom_server_addr.sin_addr.s_addr;
-	*(u_short *)&res.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_port =
-		ypdb->dom_server_addr.sin_port;
+	memcpy(&res.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_addr,
+	&ypdb->dom_server_addr.sin_addr.s_addr, sizeof(u_int32_t));
+	memcpy(&res.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_port,
+	&ypdb->dom_server_addr.sin_port, sizeof(u_short));
 	/*printf("domain %s at %s/%d\n", ypdb->dom_domain,
 		inet_ntoa(ypdb->dom_server_addr.sin_addr),
 		ntohs(ypdb->dom_server_addr.sin_port));*/
@@ -275,8 +275,12 @@
 
 	bzero(&bindsin, sizeof bindsin);
 	bindsin.sin_family = AF_INET;
-	bindsin.sin_addr.s_addr = *(u_int32_t *)argp->ypsetdom_binding.ypbind_binding_addr;
-	bindsin.sin_port = *(u_short *)argp->ypsetdom_binding.ypbind_binding_port;
+	memcpy(&bindsin.sin_addr.s_addr,
+	&argp->ypsetdom_binding.ypbind_binding_addr,
+	sizeof(u_int32_t));
+	memcpy(&bindsin.sin_port,
+	&argp->ypsetdom_binding.ypbind_binding_port,
+	sizeof(u_short));
 	rpc_received(argp->ypsetdom_domain, &bindsin, 1);
 
 	return((void *) &result);
@@ -945,8 +949,10 @@
 
 	bzero(&ybr, sizeof ybr);
 	ybr.ypbind_status = YPBIND_SUCC_VAL;
-	*(u_int32_t *)&ybr.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_addr = raddrp->sin_addr.s_addr;
-	*(u_short *)&ybr.ypbind_resp_u.ypbind_bindinfo.ypbind_binding_port = raddrp->sin_port;
+	memcpy(ybr.ypbind_resp_u

[Differential] [Commented On] D2690: In ypbind, eliminate error: dereferencing type-punned pointer will break strict-aliasing rules

[rodrigc (Craig Rodrigues)]

rodrigc added a comment.

Sorry for the late response.  Please address @dim 's comment, if you have not
addressed it already.

Also, removing the type-alias punned warnings is trickier than the other types
of fixes that we have done to clean up the code.
For this change, I would feel more comfortable if we actually tested ypbind 
with this code change.

I know, this is a headcahe. :(
But still, we have to do the right thing.

Regarding importing ypbind from OpenBSD.  I think this is a good idea, because 
it looks like they more actively maintain the code. 
However, this code in FreeBSD is *old*almost 17 years old.  Even if we 
import from OpenBSD, I don't know if
there are changes to functionality, command-line options, etc. that will be 
introduced.
This will require testing also.

It depends on how much interest you have in ypbind. :)
I don't have a lot of interest, and was just looking at doing minimal code 
changes to fix compiler warnings.

Let me know what approach you want to take.  I will support you.


REPOSITORY
  rS FreeBSD src repository

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

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

To: rodrigc, bapt, emaste, dim, araujo
Cc: imp, 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] [Accepted] D2690: In ypbind, eliminate error: dereferencing type-punned pointer will break strict-aliasing rules

[rodrigc (Craig Rodrigues)]

rodrigc accepted this revision.
This revision has a positive review.

REPOSITORY
  rS FreeBSD src repository

BRANCH
  /head

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

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

To: araujo, bapt, emaste, dim, rodrigc
Cc: imp, 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"