Re: FreeBSD 13 console stops working under VMware

[Dimitry Andric]

On 8 May 2021, at 16:02, Roger Leigh  wrote:
> 
> This might sound like a bit of an odd one, but I’ll try to describe it.  When 
> I run a FreeBSD 13-RELEASE virtual machine under VMware, it appears to work 
> correctly, but randomly stops working.
> 
> If I focus the VMware window, and press Ctrl-G to grab input focus (or click 
> in the window), I can log into the system using the console.  However, if I 
> press Ctrl-Alt to ungrab the input focus, or click outside the window, the 
> block cursor on the console vanishes, and it’s no longer possible to type any 
> input.
> 
> However… if I grab focus again, I can use Alt-Fn to switch to a different 
> virtual console, log in again and everything is fine… up until I switch focus 
> to something else and the block cursor vanishes in that virtual console.  
> Repeat until you run out of virtual consoles!
> 
> I can’t reproduce this with FreeBSD 12.  It seems to only happen with FreeBSD 
> 13.  I’ve had it happen reproducibly when losing focus, but then again 
> sometimes I’ve had a few minutes where it doesn’t happen, until it starts 
> occurring again.  While it seems that losing focus is the trigger, there 
> might be something else going on.
> 
> Has anyone else noticed this or have any suggested workarounds?

Press the Scroll Lock key to 'fix' it, if that is possible for you. This is 
some weird interaction between VMware's input focus grabbing method and our 
console, which sometimes turns on Scroll Lock accidentally. I have not been 
able to put my finger on when it happens exactly, but it does happen often.

For me, it usually occurs when I use Microsoft Remote Desktop to access a 
Windows machine running VMware, and switch back and forth between Remote 
desktop and another application. Something about losing the focus is making the 
VMware GUI inject a Scroll Lock event. It's pretty tricky to generate Scroll 
Lock via Remote Desktop though, especially from a Mac, which doesn't have that 
key at all. :)

-Dimitry

PS: Note that Scroll Lock is normally used in FreeBSD's console to scroll back 
in the virtual consoles, as opposed to Linux's shift-PageUp and shift-PageDown. 
But it is a toggle, not a one-off key.



signature.asc
Description: Message signed with OpenPGP

Re: build failed for 12.2-p5

[Dimitry Andric]

On 27 Mar 2021, at 12:39, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> I compiled 12.2-p4 from sources 2 days ago but any attempt to build update 
> for 12.2-p5 ends with error.
> 
> Previous build was done on 11.4:
> 
> # cd /usr/src/
> # git clone https://github.com/freebsd/freebsd.git -b releng/12.2 ./
> # make buildworld
> # make buildkernel
> 
> 11.4 machine was upgraded to 12.2 (I did also run mergemaster) so now I have 
> FreeBSD 12.2-RELEASE-p4 amd64 GENERIC
> 
> # cd /usr/src/
> # git pull --ff-only
> # make -DNO_CLEAN buildworld
> 
> it ends with the following error
> 
> sh /usr/src/tools/install.sh  -s -o root -g wheel -m 555   xinstall 
> /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/install
> sh /usr/src/tools/install.sh  -o root -g wheel -m 444  install.debug 
> /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib/debug/usr/bin/install.debug
> *** Signal 11

You'll need to debug the core dump to see what it segfaulted on. In this
case, I would first suspect the hardware. Run a full memtest86 for 24
hours to see if it results in any errors.


> Stop.
> make[3]: stopped in /usr/src/usr.bin/xinstall
> *** Error code 1
> 
> Usr: 437.951s  Krnl: 15.620s  Totl: 7:48.92s  CPU: 96.7%  swppd: 0  I/O: 
> 55800+84576
> 
> I tried without -DNO_CLEAN but it failed again
> 
> sh /usr/src/tools/install.sh  -o root -g wheel -m 444  make-roken.debug 
> /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib/debug/usr/bin/make-roken.debug
> ===> kerberos5/lib/libroken (obj,all,install)
> [Creating objdir 
> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/kerberos5/lib/libroken...]
> make-roken > roken.h
> *** Signal 11

This won't help you at all, if the first build failed then there is no
reason the next will work. If your hardware is faulty then you will only
run into random errors like this, which is why I would suggest checking
your hardware first.

Now, the roken.h file that was produced is obviously prematurely cut
off, which is almost certainly the cause for the next failure:


> # make -DNO_CLEAN buildkernel
> 
> cc  -O2 -pipe -fno-common -I/usr/src/crypto/heimdal/lib/roken -I. 
> -DHAVE_CONFIG_H -I/usr/src/kerberos5/include -g -MD -MF.depend.copyhostent.o 
> -MTcopyhostent.o -std=gnu99  -Qunused-arguments  
> -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -c 
> /usr/src/crypto/heimdal/lib/roken/copyhostent.c -o copyhostent.o
> /usr/src/crypto/heimdal/lib/roken/copyhostent.c:42:1: error: unknown type name
>  'ROKEN_LIB_FUNCTION'
> ROKEN_LIB_FUNCTION struct hostent * ROKEN_LIB_CALL
> ^
> /usr/src/crypto/heimdal/lib/roken/copyhostent.c:42:51: error: expected ';' 
> after top level
>  declarator
> ROKEN_LIB_FUNCTION struct hostent * ROKEN_LIB_CALL
>  ^
>  ;

Since the roken.h file is bad, it won't compile. Delete the bad roken.h,
or maybe your entire /usr/obj, and after your hardware turns out to be
okay, try again.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: 11.4-STABLE - libcxxrt changes (?) broke libreoffice

[Dimitry Andric]

On 25 Feb 2021, at 10:07, Bengt Ahlgren  wrote:
> 
> Dimitry Andric  writes:
> 
>> On 24 Feb 2021, at 19:13, Dimitry Andric  wrote:
>>> 
>>> On 24 Feb 2021, at 16:04, Bengt Ahlgren  wrote:
>>>> 
>>>> After updating my laptop with 11.4-STABLE to r369345, libreoffice
>>>> (7.0.3.1_2) just exits with "Application Error".  Going back to
>>>> 11.4-STABLE r369313, before the libcxxrt changes, makes the same
>>>> libreoffice binary work again.
>>>> 
>>>> I build libreoffice with the KF5, QT5 and JAVA options on, in a 11.4-REL
>>>> poudriere jail.
>>>> 
>>>> I didn't see any other application crashes.
>>> 
>>> This is likely fixed by:
>>> https://cgit.freebsd.org/src/commit/?id=d149877758f162f0c777e7760164bf2c1f7a1bc1
>>> 
>>> for which the MFC timer will expire tomorrow, then I will commit the fix.
>> 
>> Since this can cause crashes, I've fast-tracked the MFC:
>> 
>> stable/11:
>> https://cgit.freebsd.org/src/commit/?id=696961f67c5eaabe03713dbf1b4fc2b7a0ce1cb1
>>   or: https://svnweb.freebsd.org/base?view=revision=369363
>> 
>> stable/12:
>> https://cgit.freebsd.org/src/commit/?id=64809c763b0c73fe488b61601670067056b07780
>>   or: https://svnweb.freebsd.org/base?view=revision=369362
>> 
>> stable/13:
>> https://cgit.freebsd.org/src/commit/?id=1c1460747efd44eb74762b960883656b56134e30
>> 
>> (Note stable/13 is not exported to Subversion.)
> 
> Thanks for your very quick response!  I have updated to r369363, but
> unfortunately back to not working.  libreoffice --backtrace gives this
> gdbtrace.log (truncated):
> 
> (no debugging symbols found)...(no debugging symbols found)...warning: Lowest 
> section in /usr/local/lib/libicudata.so.68 is .hash at 0120
> 
> Program received signal SIGBUS, Bus error.
> 0x00082ac05057 in ?? () from 
> /usr/local/lib/libreoffice/program/libgcc3_uno.so
> Current language:  auto; currently minimal
> #0  0x00082ac05057 in ?? () from 
> /usr/local/lib/libreoffice/program/libgcc3_uno.so
> #1  0x00082ac04c47 in ?? () from 
> /usr/local/lib/libreoffice/program/libgcc3_uno.so
> #2  0x0008014061f6 in __cxa_end_catch () at 
> /usr/src/contrib/libcxxrt/exception.cc:611
> #3  0x0008037ac717 in dp_misc::create_ucb_content () from 
> /usr/local/lib/libreoffice/program/libdeploymentmisclo.so
> #4  0x0008379116b2 in deployment_component_getFactory () from 
> /usr/local/lib/libreoffice/program/../program/libdeployment.so

This looks like an old version of libcxxrt is used, i.e. just after the
alignment fix was applied prematurely in r369324 (this was reverted
again in r369236, so there was a very small window of commits which you
may have been able to hit).


> I did the re-building with -DNO_CLEAN, but I doubt that would affect
> this.  Would you like me to file a PR?

I'm not sure that would help much, as the bug seems to be solved for me,
and I cannot reproduce any crashes anymore. But if you can come up with
a test case that is small (i.e. not the whole of libreoffice, it takes
many hours to build), then we can look again.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: 11.4-STABLE - libcxxrt changes (?) broke libreoffice

[Dimitry Andric]

On 24 Feb 2021, at 19:13, Dimitry Andric  wrote:
> 
> On 24 Feb 2021, at 16:04, Bengt Ahlgren  wrote:
>> 
>> After updating my laptop with 11.4-STABLE to r369345, libreoffice
>> (7.0.3.1_2) just exits with "Application Error".  Going back to
>> 11.4-STABLE r369313, before the libcxxrt changes, makes the same
>> libreoffice binary work again.
>> 
>> I build libreoffice with the KF5, QT5 and JAVA options on, in a 11.4-REL
>> poudriere jail.
>> 
>> I didn't see any other application crashes.
> 
> This is likely fixed by:
> https://cgit.freebsd.org/src/commit/?id=d149877758f162f0c777e7760164bf2c1f7a1bc1
> 
> for which the MFC timer will expire tomorrow, then I will commit the fix.

Since this can cause crashes, I've fast-tracked the MFC:

stable/11: 
https://cgit.freebsd.org/src/commit/?id=696961f67c5eaabe03713dbf1b4fc2b7a0ce1cb1
   or: https://svnweb.freebsd.org/base?view=revision=369363

stable/12: 
https://cgit.freebsd.org/src/commit/?id=64809c763b0c73fe488b61601670067056b07780
   or: https://svnweb.freebsd.org/base?view=revision=369362

stable/13: 
https://cgit.freebsd.org/src/commit/?id=1c1460747efd44eb74762b960883656b56134e30

(Note stable/13 is not exported to Subversion.)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: 11.4-STABLE - libcxxrt changes (?) broke libreoffice

[Dimitry Andric]

On 24 Feb 2021, at 16:04, Bengt Ahlgren  wrote:
> 
> After updating my laptop with 11.4-STABLE to r369345, libreoffice
> (7.0.3.1_2) just exits with "Application Error".  Going back to
> 11.4-STABLE r369313, before the libcxxrt changes, makes the same
> libreoffice binary work again.
> 
> I build libreoffice with the KF5, QT5 and JAVA options on, in a 11.4-REL
> poudriere jail.
> 
> I didn't see any other application crashes.

This is likely fixed by:
https://cgit.freebsd.org/src/commit/?id=d149877758f162f0c777e7760164bf2c1f7a1bc1

for which the MFC timer will expire tomorrow, then I will commit the fix.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: `clang -pg` generates binary which coredumps on start

[Dimitry Andric]

On 29 Jan 2021, at 00:57, Lev Serebryakov  wrote:
> 
> I'm trying to profile my user-level program on FreeBSD 12-STABLE (amd64). 
> When I build it with `cc -g -pg -O3` it coredumps on start. What do I do 
> wrong?
> 
> (lldb) bt
> * thread #1, name = 'mergenets', stop reason = signal SIGSEGV
>  * frame #0: 0x
>frame #1: 0x0028ebbf mergenets`__vdso_gettc(th=0x7270, 
> tc=0x7fffddbc) at __vdso_gettc.c:0
>frame #2: 0x0028e8c3 mergenets`binuptime [inlined] 
> tc_delta(th=) at __vdso_gettimeofday.c:46:10
>frame #3: 0x0028e8ba mergenets`binuptime(bt=0x7fffde08, 
> tk=0x71b0, abs=0) at __vdso_gettimeofday.c:78
>frame #4: 0x0028ea73 mergenets`__vdso_clock_gettime(clock_id=4, 
> ts=0x7fffde68) at __vdso_gettimeofday.c:165:10
>frame #5: 0x00281efb mergenets`__clock_gettime(clock_id=4, 
> ts=0x7fffde68) at clock_gettime.c:48:11
>frame #6: 0x0024339f mergenets`nstime_update_impl [inlined] 
> nstime_get(time=0x000800403a88) at jemalloc_nstime.c:128:2
>frame #7: 0x00243395 
> mergenets`nstime_update_impl(time=0x000800403a88) at jemalloc_nstime.c:160
>frame #8: 0x00234b6d mergenets`__je_arena_new [inlined] 
> arena_decay_reinit(decay=0x000800403a20, decay_ms=) at 
> jemalloc_arena.c:572:2
>frame #9: 0x00234b21 mergenets`__je_arena_new [inlined] 
> arena_decay_init(decay=0x000800403a20, decay_ms=, 
> stats=0x0008004009a0) at jemalloc_arena.c:593
>frame #10: 0x00234b1a 
> mergenets`__je_arena_new(tsdn=0x, ind=0, 
> extent_hooks=) at jemalloc_arena.c:1858
>frame #11: 0x002239c0 mergenets`__je_arena_init [inlined] 
> arena_init_locked(tsdn=0x, ind=0, 
> extent_hooks=0x00205778) at jemalloc_jemalloc.c:338:10
>frame #12: 0x002239b2 
> mergenets`__je_arena_init(tsdn=0x, ind=0, 
> extent_hooks=0x00205778) at jemalloc_jemalloc.c:366
>frame #13: 0x0022f946 mergenets`malloc_init_hard_a0_locked at 
> jemalloc_jemalloc.c:1328:6
>frame #14: 0x00222cf5 mergenets`a0ialloc [inlined] 
> malloc_init_hard_a0 at jemalloc_jemalloc.c:1343:8
>frame #15: 0x00222caa mergenets`a0ialloc [inlined] malloc_init_a0 
> at jemalloc_jemalloc.c:214
>frame #16: 0x00222caa mergenets`a0ialloc(size=6223, zero=false, 
> is_internal=false) at jemalloc_jemalloc.c:234
>frame #17: 0x002225fc mergenets`__libc_allocate_tls [inlined] 
> malloc_aligned(size=6200, align=16) at tls.c:135:8
>frame #18: 0x002225e2 
> mergenets`__libc_allocate_tls(oldtls=0x, 
> tcbsize=, tcbalign=) at tls.c:359
>frame #19: 0x002227d0 mergenets`_init_tls at tls.c:469:8
>frame #20: 0x0021f234 mergenets`_start(ap=, 
> cleanup=) at crt1.c:66:3

Likely https://bugs.freebsd.org/249121 (and maybe 
https://bugs.llvm.org/show_bug.cgi?id=48165).

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD buildworld problem.

[Dimitry Andric]

On 22 Aug 2020, at 16:46, Budi Janto  wrote:
> 
> On 8/22/20 9:19 PM, Dimitry Andric wrote:
>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
>>> Preprocessed source(s) and associated run script(s) are located at:
>>> c++: note: diagnostic msg: /tmp/ObjCContainersASTChecker-393fe9.cpp
>>> c++: note: diagnostic msg: /tmp/ObjCContainersASTChecker-393fe9.sh
>> 
>> Can you put these two files in a compressed tarball, and attach it to a
>> Bugzilla PR?
>> 
>> Alternatively, send that tarball to me, so I can try if I can reproduce
>> it.
>> 
>> -Dimitry
>> 
> 
> Thank you for your fast respone. Here, I've attached those files.

Hmm, I have tried with a lot of different clang 10.x builds, but I can't
get it to crash with your reproduction files.

Could your crash maybe be caused by out-of-memory conditions, or some
sort of hardware problem? Does it occur every time in the same file?
And have you seen any messages in dmesg or the system logs saying
"kernel: swap_pager_getswapspace(number): failed" ?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD buildworld problem.

[Dimitry Andric]

On 22 Aug 2020, at 16:06, Budi Janto  wrote:
> 
> I've got trouble `make buildworld` in this days. I need to attach this
> msg console.
> 
> # uname -smrv
> FreeBSD 12.1-STABLE FreeBSD 12.1-STABLE r359271 GENERIC  amd64
> 
> # svnlite info /usr/src/
> Path: .
> Working Copy Root Path: /usr/src
> URL: https://svn.freebsd.org/base/stable/12
> Relative URL: ^/stable/12
> Repository Root: https://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 364482
> Node Kind: directory
> Schedule: normal
> Last Changed Author: mav
> Last Changed Rev: 364471
> Last Changed Date: 2020-08-22 07:42:33 +0700 (Sat, 22 Aug 2020)
> 
> <...>
> 1.   parser at end of file
> 2.
> /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/FoldingSet.h:329:15:
> instantiating function definition
> 'llvm::FoldingSetNodeID::Add'
> #0 0x0245c4a3 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
> (/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/c+++0x245c4a3)
> #1 0x0245a7b5 llvm::sys::RunSignalHandlers()
> (/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/c+++0x245a7b5)
> #2 0x0245e466 CrashRecoverySignalHandler(int)
> (/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/c+++0x245e466)
> #3 0x032bbfb0 handle_signal
> (/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/c+++0x32bbfb0)
> c++: error: clang frontend command failed due to signal (use -v to see
> invocation)
> FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git
> llvmorg-10.0.1-0-gef32c611aa2)
> Target: x86_64-unknown-freebsd12.1
> Thread model: posix
> InstalledDir: /usr/obj/usr/src/amd64.amd64/tmp/usr/bin
> c++: note: diagnostic msg: PLEASE submit a bug report to
> https://bugs.freebsd.org/submit/ and include the crash backtrace,
> preprocessed source, and associated run script.
> c++: note: diagnostic msg:
> 
> 
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> c++: note: diagnostic msg: /tmp/ObjCContainersASTChecker-393fe9.cpp
> c++: note: diagnostic msg: /tmp/ObjCContainersASTChecker-393fe9.sh

Can you put these two files in a compressed tarball, and attach it to a
Bugzilla PR?

Alternatively, send that tarball to me, so I can try if I can reproduce
it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: `efivar -l` fails on UEFI booted 11.4-RELEASE

[Dimitry Andric]

On 28 Jun 2020, at 04:21, Kyle Evans  wrote:
> 
> On Sat, Jun 27, 2020 at 8:04 PM Yasuhiro KIMURA  wrote:
>> 
>> On UEFI booted 11.4-RELEASE system `efivar -l` fails as following.
>> 
>> root@rolling-vm-freebsd3[160]# uname -a
>> FreeBSD rolling-vm-freebsd3.home.utahime.org 11.4-RELEASE FreeBSD 
>> 11.4-RELEASE #0 r362094: Fri Jun 12 18:27:15 UTC 2020 
>> r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>> root@rolling-vm-freebsd3[161]# efivar -l
>> efivar: Error listing names: No such file or directory

Perhaps the efivar utility could suggest loading the module in this case?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: 11.4-RELEASE make delete-old

[Dimitry Andric]

On 27 Jun 2020, at 03:55, Greg Balfour  wrote:
> 
> On a fresh install of 11.4-RELEASE, rebuilding the operating system
> results in several files being deleted during the "make delete-old"
> step.  This surprised me.  I wouldn't have expected this on a rebuild
> of a new install without any updates applied.  See below, but for
> example /usr/bin/llvm-ar is present after the initial install but is then
> removed by the "make delete-old" step.  Is this to be expected?
> Is the correct action to respond y when prompted about the files?
> 
> root@test:/usr/src # make -j 4 buildworld buildkernel
> ...
> root@test:/usr/src # make installkernel
> ...
> root@test:/usr/src # make installworld
> ...
> root@test:/usr/src # make delete-old
 Removing old files (only deletes safe to delete libs)
> remove /usr/bin/llvm-ar? y
> remove /usr/lib/debug/usr/bin/llvm-ar.debug? y
> remove /usr/bin/llvm-nm? y
> remove /usr/lib/debug/usr/bin/llvm-nm.debug? y
> remove /usr/bin/llvm-ranlib? y
> remove /usr/share/man/man1/llvm-ar.1.gz? y
> remove /usr/share/man/man1/llvm-nm.1.gz? y
> remove /usr/share/man/man1/llvm-symbolizer.1.gz? y
 Old files removed
 Removing old directories
 Old directories removed
> To remove old libraries run 'make delete-old-libs'.

Hmm, you found an issue in tools/build/mk/OptionalObsoleteFiles.inc. At
some point llvm-ar, llvm-nm, llvm-objdump and llvm-symbolizer got
promoted out of MK_CLANG_EXTRAS, so they always get installed. But in
OptionalObsoleteFiles they are still under MK_CLANG_EXTRAS, so if you
don't have that enabled, they are proposed for deletion.

I have MFCd a few additional changes to fix this, in:
https://svnweb.freebsd.org/changeset/base/362674

but this will have to be manually applied to your source tree, if you
don't want to get prompted anymore. Otherwise, simply ignore the
removal requests.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Buildworld and buildkernel with very slow compilation, recently

[Dimitry Andric]

On 21 Jun 2020, at 14:36, Chris Nehren  wrote:
> 
> On Sunday, June 21, 2020 8:11:15 AM EDT Michael Grimm wrote:
>> Hi,
>> 
>> I am following FreeBSD 12.1-STABLE.
>> 
>> Clang has been upgraded to version 10.0.0 on May, 1st, and ever since that
>> time, I do observe a dramatic increase in compilation times of building
>> world, kernel and ports. I didn't benchmark the exact times, but
>> compilation times are at least increased by a factor of 1.5. Nothing has
>> changed of the last month besides upgrading 12.1-Stable every other week.
>> 
>> Has anyone else been bitten by this?
> 
> I don't have measurements to corroborate this, but here's a mailing list
> thread where folks are talking about it (split across two URLs, the OP posted
> in April and then there was a followup in May):
> 
> http://lists.llvm.org/pipermail/llvm-dev/2020-April/140938.html
> https://lists.llvm.org/pipermail/llvm-dev/2020-May/141482.html
> 
> So there definitely seems to be *something* going on, and you are indeed not
> crazy. :)

Indeed, there is some upstream discussion going on about this issue.
There are some scenarios where people see non-negligible performance
loss, but apparently not everybody suffers from it. If you build the
whole ports collection, it is rather likely you may bump into it. I have
personally not seen much performance difference in building world,
kernel etc.

One of the upstream problems is that there is not really any
authoritative performance regression log being built up, so it is hard
to see where such regressions were introduced. Somebody then has to
spend a lot of time tracking down each and every regression, and then
attempt to untangle it from the dozens of commits made around the same
time. :)

In any case, there is at least some attention on it now, so hopefully
this will improve again. I don't think such fixes will be trivial
though, so it is not likely they will land in 10.0.1.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: svn commit: r361465 - in stable: 11/lib/clang/include/clang/Config 11/lib/clang/include/llvm/Config 12/lib/clang/include/clang/Config 12/lib/clang/include/llvm/Config

[Dimitry Andric]

Hi Mike,

Unless you need zlib compressed debug information, you will not be
affected. I hope that on nano-scale systems you will seldom have to deal
with multi-GB .debug sections. :-)

Note that I have asked the release engineering team for approval to
merge this change into 11.4, so hopefully it will be in the upcoming
release.

-Dimitry

On 25 May 2020, at 18:15, mike tancsa  wrote:
> 
> Is there any fallout from this commit not being there ? I have
> deployed some nanobsd images based on a tree last week.  Are there any
> bugs I would run into as a result of this ? Or is it benign ?
> 
> Thanks,
> 
> ---Mike
> 
> On 5/25/2020 12:06 PM, Dimitry Andric wrote:
>> Author: dim
>> Date: Mon May 25 16:06:30 2020
>> New Revision: 361465
>> URL: https://svnweb.freebsd.org/changeset/base/361465
>> 
>> Log:
>>  Regenerate llvm config headers to correctly enable zlib support
>> 
>>  During the initial upgrade to 10.0.0 in r357120, I generated these
>>  headers once, but they were missing zlib-related settings at that time.
>>  These should have been regenerated again during the merge of the final
>>  10.0.0 release.
>> 
>>  Direct commit to stable/{11,12}, since head has gotten 10.0.1 in the
>>  mean time, with up-to-date generated headers.
>> 
>>  Reported by:hyam...@gmail.com
>>  PR: 246244



signature.asc
Description: Message signed with OpenPGP

Re: crash while building libunbound.so on 12-STABLE

[Dimitry Andric]

On 24 May 2020, at 12:17, Donald Wilde  wrote:
> 
> Let's see if I can report this adequately enough. The macro-task I am
> attempting to accomplish is to update my (English) FreeBSD Handbook to
> 12-STABLE from the ports collection asextracted 2020-05-23.
> 
> The actual failure in creating libunbound.so is that the command to
> compile iterator.c is short one argument. This occurs while trying to
> compile ghostscript9.
> 
> MAKE_JOBS_UNSAFE=yes
...
> ./iterator/iterator.c:2159:47: error: too few arguments to function call, 
> expected 12, have 11
> INIT_REQUEST_STATE, FINISHED_STATE, , 1)) {
> ^
> ./iterator/iterator.c:679:1: note: 'generate_sub_request' declared here
> static int
> ^
> 1 error generated.

It looks like this error has already been reported here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246648

and here:

https://github.com/NLnetLabs/unbound/issues/239

There is a patch in the upstream ticket, maybe you can try that.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: svn commit: r356465 - in stable/12: . contrib/llvm-project/clang/include/clang/CodeGen contrib/llvm-project/clang/lib/Basic/Targets contrib/llvm-project/clang/lib/CodeGen contrib/llvm-project/clan

[Dimitry Andric]

On 8 Jan 2020, at 22:00, Dimitry Andric  wrote:
> 
> On 8 Jan 2020, at 19:37, mike tancsa  wrote:
>> 
>> On 1/8/2020 1:14 PM, mike tancsa wrote:
>>> On 1/8/2020 1:08 PM, Ian Lepore wrote:
>>>> I am at r356502
>>>>> root@asrock-ryzen7a:/usr/src # sleep 20;time make -j 16 buildworld >
>>>>> /var/log/build.out ; time make -j16 buildkernel > /var/log/build.out.k
>>>>> [Creating objdir /usr/obj/usr/src/amd64.amd64...]
>>>>> 20805.460u 1075.767s 26:02.05 1400.8%   58220+3452k 650321+3431159io
>>>>> 222076pf+0w
>>>>> 1487.734u 147.997s 1:45.14 1555.7%  52726+3205k 195595+3387101io
>>>>> 70456pf+0w
>>>>> root@asrock-ryzen7a:/usr/src #
>>>>> 
>>>>> Just tried again. installkernel/world and reboot, yet still get
>>>>> SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker.
...
> I think something in the MK_SYSTEM_LINKER logic may have fallen over due
> to the change in this output.  Ed, any ideas?
> 
> Note I didn't see any reports about this in head, but it could also be
> a problem there.

I just noticed this was fixed in head by Bryan Drewery in r354859:

URL: https://svnweb.freebsd.org/changeset/base/354859

Log:
 WITH_SYSTEM_LINKER: Fix rebuilding lld every time.

 This is due to LLD_REVISION_STRING being renamed to LLD_REVISION in
 r351442 and the value being moved to another location in r351965.

 `make test-system-linker` can be used to see the values being used here.

 Reported by:   ler

I have just MFC'd this to stable/12, in r356518.  Thanks for the report!

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: svn commit: r356465 - in stable/12: . contrib/llvm-project/clang/include/clang/CodeGen contrib/llvm-project/clang/lib/Basic/Targets contrib/llvm-project/clang/lib/CodeGen contrib/llvm-project/clan

[Dimitry Andric]

On 8 Jan 2020, at 19:37, mike tancsa  wrote:
> 
> On 1/8/2020 1:14 PM, mike tancsa wrote:
>> On 1/8/2020 1:08 PM, Ian Lepore wrote:
>>> I am at r356502
 root@asrock-ryzen7a:/usr/src # sleep 20;time make -j 16 buildworld >
 /var/log/build.out ; time make -j16 buildkernel > /var/log/build.out.k
 [Creating objdir /usr/obj/usr/src/amd64.amd64...]
 20805.460u 1075.767s 26:02.05 1400.8%   58220+3452k 650321+3431159io
 222076pf+0w
 1487.734u 147.997s 1:45.14 1555.7%  52726+3205k 195595+3387101io
 70456pf+0w
 root@asrock-ryzen7a:/usr/src #
 
 Just tried again. installkernel/world and reboot, yet still get
 SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker.
 
 
---Mike
 
>>> What's the output of "make test-system-compiler"?  That will display
>>> all the variables used to make the decisions on what to (re)build.
>> Just installed again and rebooted
>> 
>> root@asrock-ryzen7a:/usr/src # svnlite status --show-updates
>> Status against revision: 356505
>> root@asrock-ryzen7a:/usr/src #
>> 
>> root@asrock-ryzen7a:/usr/src # make test-system-compiler
>> USING_SYSTEM_COMPILER  = yes
>> MK_SYSTEM_COMPILER = yes
>> MK_CROSS_COMPILER  = yes
>> MK_CLANG_BOOTSTRAP = no
>> MK_GCC_BOOTSTRAP   = no
>> WANT_COMPILER_TYPE = clang
>> WANT_COMPILER_VERSION  = 90001
>> WANT_COMPILER_VERSION_FILE =
>> lib/clang/include/clang/Basic/Version.inc
>> WANT_COMPILER_FREEBSD_VERSION  = 1200021
>> WANT_COMPILER_FREEBSD_VERSION_FILE = lib/clang/freebsd_cc_version.h
>> CC = cc
>> COMPILER_TYPE  = clang
>> COMPILER_FEATURES  =  c++11 c++14 c++17 retpoline
>> COMPILER_VERSION   = 90001
>> COMPILER_FREEBSD_VERSION   = 1200021
>> XCC= cc
>> X_COMPILER_TYPE= clang
>> X_COMPILER_FEATURES=  c++11 c++14 c++17 retpoline
>> X_COMPILER_VERSION = 90001
>> X_COMPILER_FREEBSD_VERSION = 1200021
>> root@asrock-ryzen7a:/usr/src # make test-system-linker
>> USING_SYSTEM_LINKER= no
>> MK_SYSTEM_LINKER   = yes
>> MK_LLD_BOOTSTRAP   = yes
>> MK_BINUTILS_BOOTSTRAP  = yes
>> WANT_LINKER_TYPE   = lld
>> WANT_LINKER_VERSION= 90001
>> WANT_LINKER_VERSION_FILE   =
>> lib/clang/include/lld/Common/Version.inc
>> WANT_LINKER_FREEBSD_VERSION=
>> WANT_LINKER_FREEBSD_VERSION_FILE   =
>> lib/clang/include/lld/Common/Version.inc
>> LD = ld
>> LINKER_TYPE= lld
>> LINKER_FEATURES=  build-id ifunc filter retpoline
>> LINKER_VERSION = 90001
>> LINKER_FREEBSD_VERSION =
>> c1a0a213378a458fbea1a5c77b315c7dce08fd05-1200010
>> XLD= ld
>> X_LINKER_TYPE  = lld
>> X_LINKER_FEATURES  =  build-id ifunc filter retpoline
>> X_LINKER_VERSION   = 90001
>> X_LINKER_FREEBSD_VERSION   =
>> c1a0a213378a458fbea1a5c77b315c7dce08fd05-1200010
>> root@asrock-ryzen7a:/usr/src #
>> 
> I also did make delete-old and make delete-old-libs, but no difference.
> make test-system-compiler and  make test-system-linker give the same
> results.
> 
> Also just tried blowing away /usr/obj and the same deal. The system
> linker needs to be rebuilt each time
> 
> make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined
> that CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
> make[1]: "/usr/src/Makefile.inc1" line 348: SYSTEM_LINKER: libclang will
> be built for bootstrapping a cross-linker.

Hm, so it thinks the compiler is new enough, but not the linker?  This
might be due to the recent change of the upstream Subversion revision
into a Git coommit hash, e.g. lld used to print:

LLD 9.0.0 (FreeBSD 372316-135) (compatible with GNU linkers)

but now it prints:

LLD 9.0.1 (FreeBSD c1a0a213378a458fbea1a5c77b315c7dce08fd05-136) 
(compatible with GNU linkers)

The first number or hash is the upstream revision or commit, the second
number is "our" monotonically increasing version number.  If we make
changes that require re-bootstrapping the linker, we bump that second
number.

I think something in the MK_SYSTEM_LINKER logic may have fallen over due
to the change in this output.  Ed, any ideas?

Note I didn't see any reports about this in head, but it could also be
a problem there.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Is it necessary to bump target triple for lib32

[Dimitry Andric]

On 19 Oct 2019, at 05:51, Jeremy  wrote:
> 
> While I was doing a buildworld for FreeBSD 12 stable (r353745) for amd64, I
> noticed the target triple was set at x86_64-unknown-freebsd12.0 while it
> was building the 32 bit libraries. I was wondering if it was necessary to
> bump it to 12.1 now that 12.1 is getting ready for release, or if it
> doesn't matter either way. I believe the relevant commit was from
> (r338268). In any case, buildworld completed with no issues.
> 
> If it's not necessary, sorry for the noise.

You are right, this is coming from Makefile.libcompat:

$ grep freebsd12 Makefile.libcompat
LIB32CPUFLAGS+= -target x86_64-unknown-freebsd12.0
LIB32CPUFLAGS=  -target mipsel-unknown-freebsd12.0
LIB32CPUFLAGS=  -target mips-unknown-freebsd12.0

Glen, I think you have a list somewhere of the files that need to have
their versions bumped for releng branches, could you please add
Makefile.libcompat to it too?

Maybe at one point we should have one source of truth for that obtaining
that version number... :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Error build 12.1-STABLE amd64 r353431

[Dimitry Andric]

On 11 Oct 2019, at 12:46, Alex V. Petrov  wrote:
> 
> fatal error: error in backend: Cannot emit physreg copy instruction
> c++: error: clang frontend command failed with exit code 70 (use -v to
> see invocation)
> FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on
> LLVM 8.0.1)
> Target: x86_64-unknown-freebsd12.1
> Thread model: posix
> InstalledDir: /usr/bin
> c++: note: diagnostic msg: PLEASE submit a bug report to
> https://bugs.freebsd.org/submit/ and include the crash backtrace,
> preprocessed source, and associated run script.
> c++: note: diagnostic msg:
> 
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> c++: note: diagnostic msg: /tmp/TransBlockObjCVariable-9bd54d.cpp
> c++: note: diagnostic msg: /tmp/TransBlockObjCVariable-9bd54d.sh

Can you please compress these two files into a tarball, and post it
somewhere, e.g. on bugs.freebsd.org?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib

[Dimitry Andric]

On 29 Jul 2019, at 03:07, Ed Maste  wrote:
> 
> On Fri, 26 Jul 2019 at 22:44, Jeremy Chadwick via freebsd-stable
>  wrote:
>> 
>> TL;DR for lazy folks:
>> 
>> stable/11 r350330 world + minimal clang = 1:29:34
>> stable/11 r350330 world + full clang= 1:46:31
>> stable/11 r350252 world + minimal clang =   56:52
>> stable/11 r350252 world + full clang= 1:14:30
> 
> Yes, because you're currently running r349226, and the world build
> thus first builds its own toolchain. Try the same experiment running
> on a r349226 or later installed world.

Indeed, that is the most likely explanation.  Unfortunately stable/11's
Makefile.inc1 does not explicitly show that it is going to bootstrap the
toolchain, like in head and stable/12, which show this right at the
start of buildworld:

--- buildworld ---
make[1]: "/usr/src/Makefile.inc1" line 349: SYSTEM_COMPILER: libclang will be 
built for bootstrapping a cross-compiler.
make[1]: "/usr/src/Makefile.inc1" line 354: SYSTEM_LINKER: libclang will be 
built for bootstrapping a cross-linker.
--- buildworld_prologue ---

Instead, you can only check for the *absence* of the following message:

"Determined that CC=xxx matches the source tree.  Not bootstrapping a 
cross-compiler."

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib

[Dimitry Andric]

On 24 Jul 2019, at 23:21, Dimitry Andric  wrote:
> 
> On 24 Jul 2019, at 22:56, mike tancsa  wrote:
>> 
>> On 7/24/2019 1:21 PM, mike tancsa wrote:
>>> On 7/24/2019 12:02 PM, Dimitry Andric wrote:
> ...
>>> # cat /etc/src.conf /etc/make.conf
>>> MK_SYSTEM_COMPILER=no
>>> MK_SYSTEM_LINKER=no
>>> KERNCONF=server
>>> MK_SYSTEM_COMPILER=no
>>> MK_SYSTEM_LINKER=no
>> 
>> Hmmm, is the logic reversed somehow ?  The good news is if nothing is
>> defined, it does the right thing.
> 
> The idea is that the default is to *not* bootstrap the compiler, if the
> system compiler is new enough.  E.g. if you build r350256 from a system
> built before r350256, it will normally automatically bootstrap
> everything.
> 
> E.g., your previous builds did not have to bootstrap, and now they do,
> which is why they take longer.
> 
> So the only good way to compare is to force MK_SYSTEM_COMPILER=yes and
> MK_SYSTEM_LINKER=yes, so both buildworlds will do the same thing.
> 
> I did a few tests on a relatively fast machine, and buildworld with
> those settings on took approximately the same time at r350255 and
> r350256.  I'm now repeating those experiments to feed the results to
> ministat.

Repeating buildworld 3 times for r350255 and r350256 (with both
MK_SYSTEM_COMPILER and MK_SYSTEM_LINKER set to "yes") shows no
difference in measured real time, according to ministat:

$ head real-*.txt
==> real-r350255.txt <==
1562.12
1587.61
1582.78

==> real-r350256.txt <==
1574.50
1559.20
1584.50

$ ministat real-*.txt
x real-r350255.txt
+ real-r350256.txt
+--+
|+  x +   x   +   x|
|  |_|A___M__AM__|||
+--+
N   Min   MaxMedian   AvgStddev
x   3   1562.12   1587.61   1582.78 1577.5033 13.539477
+   31559.21584.51574.5 1572.7333 12.742187
No difference proven at 95.0% confidence

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib

[Dimitry Andric]

On 24 Jul 2019, at 22:56, mike tancsa  wrote:
> 
> On 7/24/2019 1:21 PM, mike tancsa wrote:
>> On 7/24/2019 12:02 PM, Dimitry Andric wrote:
...
>> # cat /etc/src.conf /etc/make.conf
>> MK_SYSTEM_COMPILER=no
>> MK_SYSTEM_LINKER=no
>> KERNCONF=server
>> MK_SYSTEM_COMPILER=no
>> MK_SYSTEM_LINKER=no
> 
> Hmmm, is the logic reversed somehow ?  The good news is if nothing is
> defined, it does the right thing.

The idea is that the default is to *not* bootstrap the compiler, if the
system compiler is new enough.  E.g. if you build r350256 from a system
built before r350256, it will normally automatically bootstrap
everything.

E.g., your previous builds did not have to bootstrap, and now they do,
which is why they take longer.

So the only good way to compare is to force MK_SYSTEM_COMPILER=yes and
MK_SYSTEM_LINKER=yes, so both buildworlds will do the same thing.

I did a few tests on a relatively fast machine, and buildworld with
those settings on took approximately the same time at r350255 and
r350256.  I'm now repeating those experiments to feed the results to
ministat.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib

[Dimitry Andric]

On 24 Jul 2019, at 17:12, mike tancsa  wrote:
> 
> On 7/24/2019 9:45 AM, Dimitry Andric wrote:
>> On 24 Jul 2019, at 14:47, mike tancsa  wrote:
>>> On 7/23/2019 2:40 PM, Dimitry Andric wrote:
>>>> Author: dim
>>>> Date: Tue Jul 23 18:40:32 2019
>>>> New Revision: 350256
>>>> URL: https://svnweb.freebsd.org/changeset/base/350256
>>>> 
>>> Hi,
>>> 
>>>Not sure if this is just a difference in the versions or more things
>>> are being compiled, but I noticed a buildworld on my Ryzen went from ~
>>> 31min to just over 40min.   Is this expected ?
>> Most likely this is because it will now build a bootstrap compiler,
>> whereas previously your system may have skipped this step.  Can you
>> compare the results when setting MK_SYSTEM_COMPILER=no and
>> MK_SYSTEM_LINKER=no ?
> 
> Adding those two to src.conf and make.conf still shows 40min
> 
>  time make -j14 buildworld > /var/log/build.out ; time make -j14
> buildkernel > /var/log/build.out.
> [Creating objdir /usr/obj/usr/src/amd64.amd64...]
> 25312.621u 1237.984s 40:09.72 1101.8%   45579+3473k 65+320io
> 214633pf+0w
> 1675.467u 173.497s 2:37.90 1170.9%  37728+3167k 207118+3329460io
> 61829pf+0w
> 
> Should I be setting these vars somewhere else ?

Ah, setting them in src.conf, make.conf or the environment will be
overridden from Makefile.inc1, unfortunately.  It will then show
something like:

make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 343: SYSTEM_COMPILER: 
libclang will be built for bootstrapping a cross-compiler.
make[1]: "/home/dim/src/stable-12/Makefile.inc1" line 348: SYSTEM_LINKER: 
libclang will be built for bootstrapping a cross-linker.

E.g, it detects that your system compiler is of a lower version than
the compiler in the source tree, and will thus bootstrap the latter.

Can you compare the timings when setting MK_SYSTEM_COMPILER=yes and
MK_SYSTEM_LINKER=yes?  In that case, both before and after r350256, the
results should be fairly similar, I expect.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Buildworld times (was Re: svn commit: r350256 - in stable/12: . contrib/compiler-rt/lib/sanitizer_common contrib/libunwind/src contrib/llvm/lib/DebugInfo/DWARF contrib/llvm/lib/MC contrib/llvm/lib

[Dimitry Andric]

On 24 Jul 2019, at 14:47, mike tancsa  wrote:
> 
> On 7/23/2019 2:40 PM, Dimitry Andric wrote:
>> Author: dim
>> Date: Tue Jul 23 18:40:32 2019
>> New Revision: 350256
>> URL: https://svnweb.freebsd.org/changeset/base/350256
>> 
> Hi,
> 
> Not sure if this is just a difference in the versions or more things
> are being compiled, but I noticed a buildworld on my Ryzen went from ~
> 31min to just over 40min.   Is this expected ?

Most likely this is because it will now build a bootstrap compiler,
whereas previously your system may have skipped this step.  Can you
compare the results when setting MK_SYSTEM_COMPILER=no and
MK_SYSTEM_LINKER=no ?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: RELENG_10 to RELENG11 buildworld no possible ?

[Dimitry Andric]

On 10 Jul 2019, at 15:27, Dimitry Andric  wrote:
> 
> On 9 Jul 2019, at 19:02, Warner Losh  wrote:
>> On Tue, Jul 9, 2019 at 12:12 AM Dimitry Andric  wrote:
>>> On 9 Jul 2019, at 08:08, Warner Losh  wrote:
> ...
>>>> Could you look into what the new requirement is? If there's no simple
>>> workaround, I'd like to at least document what the minimum is better than I
>>> have.
>>> 
>>> Okay,
>>> http://releases.llvm.org/8.0.0/docs/ReleaseNotes.html#minimum-required-compiler-version
>>> says:
>>> 
>>> Clang   3.5
>>> Apple Clang 6.0
>>> GCC 5.1
>>> Visual Studio   2017
>>> 
>> 
>> OK, so the clang in releng10 is 3.4.1. I'll update the note then.
> 
> I committed a workaround in r349876, which makes it possible to directly
> build clang 8.0.0 with clang 3.4.1, and will MFC that after the usual
> timeout.

I have now merged the workaround to stable/{11,12}, and reverted the
notes, in r349967.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: RELENG_10 to RELENG11 buildworld no possible ?

[Dimitry Andric]

On 9 Jul 2019, at 19:02, Warner Losh  wrote:
> On Tue, Jul 9, 2019 at 12:12 AM Dimitry Andric  wrote:
>> On 9 Jul 2019, at 08:08, Warner Losh  wrote:
...
>>> Could you look into what the new requirement is? If there's no simple
>> workaround, I'd like to at least document what the minimum is better than I
>> have.
>> 
>> Okay,
>> http://releases.llvm.org/8.0.0/docs/ReleaseNotes.html#minimum-required-compiler-version
>> says:
>> 
>> Clang   3.5
>> Apple Clang 6.0
>> GCC 5.1
>> Visual Studio   2017
>> 
> 
> OK, so the clang in releng10 is 3.4.1. I'll update the note then.

I committed a workaround in r349876, which makes it possible to directly
build clang 8.0.0 with clang 3.4.1, and will MFC that after the usual
timeout.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: RELENG_10 to RELENG11 buildworld no possible ?

[Dimitry Andric]

On 9 Jul 2019, at 08:08, Warner Losh  wrote:
> 
> On Mon, Jul 8, 2019 at 11:58 PM Dimitry Andric  wrote:
> On 8 Jul 2019, at 17:38, Warner Losh  wrote:
> >
> > On Mon, Jul 8, 2019 at 7:21 AM Mike Tancsa  wrote:
> >> On 7/8/2019 3:09 AM, Patrick M. Hausen wrote:
> >>> Hi all,
> >>>
> >>>> Am 08.07.2019 um 08:30 schrieb Thomas Mueller :
> >>>> Or maybe via 11.2R, if that can be built from RELENG_10?
> >>> I just completed a successful build of RELENG_11_2 on a
> >>> RELENG_10_4 system …
> >>>
> >>> Kind regards,
> >>> Patrick
> >>
> >> I am guessing all is good up until
> >>
> >>
> >> https://lists.freebsd.org/pipermail/svn-src-stable-11/2019-April/009220.html
> >>
> >> If I svn update -r346291(commit before the import of the new clang) all
> >> builds fine.
> >>
> >> Not sure if its worth a note in UPDATING, or mentioning it here in the
> >> google archives will be good enough for anyone else who runs into it.
> >>
> >
> > I think it is worth a note. I'll add one.
> >
> > We should also followup with dim@ to see why static_assert from RELENG_10
> > is incompatible with the new compiler, and why it's used in a way that
> > would break.
> 
> I took a quick look, but I don't think there is any quick solution.  For
> some reason, clang 3.4.1 (which shipped with 10.4) cannot handle the
> static_asserts which are inside the piece of code in question.  Also,
> there are several other compilation errors, due to it being unable or
> unwilling to cast pointers.
> 
> Upstream LLVM has recently bumped the requirements for building quite
> aggressively, it could very well be that a higher version of clang or
> gcc is now required to build 8.0, precisely because of the above.  At
> some point they apparently wanted to drop the workarounds for old
> compilers.
> 
> Could you look into what the new requirement is? If there's no simple 
> workaround, I'd like to at least document what the minimum is better than I 
> have.

Okay, 
http://releases.llvm.org/8.0.0/docs/ReleaseNotes.html#minimum-required-compiler-version
 says:

Clang   3.5
Apple Clang 6.0
GCC 5.1
Visual Studio   2017

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: RELENG_10 to RELENG11 buildworld no possible ?

[Dimitry Andric]

On 8 Jul 2019, at 17:38, Warner Losh  wrote:
> 
> On Mon, Jul 8, 2019 at 7:21 AM Mike Tancsa  wrote:
>> On 7/8/2019 3:09 AM, Patrick M. Hausen wrote:
>>> Hi all,
>>> 
 Am 08.07.2019 um 08:30 schrieb Thomas Mueller :
 Or maybe via 11.2R, if that can be built from RELENG_10?
>>> I just completed a successful build of RELENG_11_2 on a
>>> RELENG_10_4 system …
>>> 
>>> Kind regards,
>>> Patrick
>> 
>> I am guessing all is good up until
>> 
>> 
>> https://lists.freebsd.org/pipermail/svn-src-stable-11/2019-April/009220.html
>> 
>> If I svn update -r346291(commit before the import of the new clang) all
>> builds fine.
>> 
>> Not sure if its worth a note in UPDATING, or mentioning it here in the
>> google archives will be good enough for anyone else who runs into it.
>> 
> 
> I think it is worth a note. I'll add one.
> 
> We should also followup with dim@ to see why static_assert from RELENG_10
> is incompatible with the new compiler, and why it's used in a way that
> would break.

I took a quick look, but I don't think there is any quick solution.  For
some reason, clang 3.4.1 (which shipped with 10.4) cannot handle the
static_asserts which are inside the piece of code in question.  Also,
there are several other compilation errors, due to it being unable or
unwilling to cast pointers.

Upstream LLVM has recently bumped the requirements for building quite
aggressively, it could very well be that a higher version of clang or
gcc is now required to build 8.0, precisely because of the above.  At
some point they apparently wanted to drop the workarounds for old
compilers.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: ZFS...

[Dimitry Andric]

On 9 May 2019, at 10:32, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> Patrick M. Hausen wrote on 2019/05/09 09:46:
>> Hi all,
>>> Am 09.05.2019 um 00:55 schrieb Michelle Sullivan :
>>> No, one disk in the 16 disk zRAID2 ...  previously unseen but it could be 
>>> the errors have occurred in the last 6 weeks... everytime I reboot it 
>>> started resilvering, gets to 761M resilvered and then stops.
>> 16 disks in *one* RAIDZ2 vdev? That might be the cause of your insanely
>> long scrubs. In general it is not recommended though I cannot find the
>> source for that information quickly just now.
> 
> Extremely slow scrub is an issue even on 4 disks RAIDZ. I already posted 
> about it in the past. This scrub is running from Sunday 3AM.
> Time to go is big lie. Is was "19hXXm" 12 hour ago.
> 
>  pool: tank0
> state: ONLINE
>  scan: scrub in progress since Sun May  5 03:01:48 2019
>10.8T scanned out of 12.7T at 30.4M/s, 18h39m to go
>0 repaired, 84.72% done
> config:
> 
>NAMESTATE READ WRITE CKSUM
>tank0   ONLINE   0 0 0
>  raidz1-0  ONLINE   0 0 0
>gpt/disk0tank0  ONLINE   0 0 0
>gpt/disk1tank0  ONLINE   0 0 0
>gpt/disk2tank0  ONLINE   0 0 0
>gpt/disk3tank0  ONLINE   0 0 0
> 
> Disks are OK, monitored by smartmontools. There is nothing odd, just the long 
> long scrubs. This machine was started with 4x 1TB (now 4x 4TB) and scrub was 
> slow with 1TB disks too. This machine - HP ML110 G8) was my first machine 
> with ZFS. If I remember it well it was FreeBSD 7.0, now running 11.2. Scrub 
> was / is always about one week. (I tried some sysctl tuning without much gain)

Unfortunately https://svnweb.freebsd.org/changeset/base/339034, which
greatly speeds up scrubs and resilvers, was not in 11.2 (since it was
cut at r334458).

If you could update to a more recent snapshot, or try the upcoming 11.3
prereleases, you will hopefully see much shorter scrub times.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD 12.0 RELEASE i386 can not build a kernel?

[Dimitry Andric]

On 28 Feb 2019, at 00:37, Rodney W. Grimes  
wrote:
> 
> config CUSTOM
> Kernel build directory is ../compile/CUSTOM
> Don't forget to do ``make cleandepend && make depend''
> fb-bld-120-i386.dnsmgr.net:root {200}# cd ../compile/CUSTOM
> fb-bld-120-i386.dnsmgr.net:root {201}# (make cleandepend && make depend && 
> make -j4 && make install) >
> fb-bld-120-i386.dnsmgr.net:root {202}# more make.OUT
> make: "../../../conf/../../../conf/kern.pre.mk" line 127: amd64/arm64/i386 
> kernel requires linker ifunc support

After ifunc support was introduced, you have to run at least
"make kernel-toolchain" before "make buildkernel", or otherwise just run
"make buildworld" first.  That will build the linker which supports the
required functionality.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: x86intrin.h not found after 10.4->11.2 upgrade

[Dimitry Andric]

On 8 Jan 2019, at 12:50, Morgan Reed  wrote:
> 
> Just did a find across /usr for the file and it's definitely there so I'm
> not sure why the compiler can't find it :/

Please post the output of:

cc -v -x c -c /dev/null -o /dev/null


> 
> # find /usr -name x86intrin.h
> /usr/include/x86intrin.h

This copy should not exist.  Any idea where it came from, and what is
its contents?


> /usr/src/contrib/llvm/tools/clang/lib/Headers/x86intrin.h
> /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd11.2/7.4.0/include/x86intrin.h
> /usr/local/llvm60/lib/clang/6.0.1/include/x86intrin.h
> /usr/lib/clang/6.0.0/include/x86intrin.h

If your /usr/bin/cc reports being clang 6.0.0, then the latter one is
correct.

My guess would be that something (/etc/make.conf, for instance) is
messing with your CFLAGS, causing the internal headers to not be found.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Just updated to 12 from11 - did ld change ?

[Dimitry Andric]

On 12 Nov 2018, at 23:06, Pete French  wrote:
> 
> Just trying out the BETA4 version of 12, updating from 11-STABLE. All went
> nice and smoothly, but when compiing coe I had to make some tweaks to the
> arhuments I am passing to 'ld' when part-linking objects against static
> libraries. Did something chnage here ? Its not on the release notes that I
> can see, and the version of clang seems to be the same as on my 11 boxes.

If you are on amd64, ld is now LLVM's lld.  You can check this with "ld -v":

$ ld -v
LLD 6.0.1 (FreeBSD 335540-125) (compatible with GNU linkers)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: aesni on i386 w/gcc breaks 11-STABLE kernel build

[Dimitry Andric]

On 30 May 2018, at 04:29, Dan Allen  wrote:
> 
> I am building FreeBSD 11 stable i386 on an old Pentium 4 machine.  The 
> clang/llvm build is just horrific in length, so I am substituting gcc by the 
> appropriate /etc/src.conf defines such as WITHOUT_CLANG, 
> WITHOUT_CLANG_BOOTSTRAP, WITH_GCC, WITH_GCC_BOOTSTRAP.
> 
> After deleting clang via make delete-old in /usr/src, all of userland builds 
> fine, but the kernel will not build due to the aesni module.

Hmm, I wonder how you managed to build world, as my build ends with the
following errors:

In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:111:1: error: "__fldcw" 
redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:98:1: error: this is the location of 
the previous definition
In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:112:1: error: "__fldenv" 
redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:99:1: error: this is the location of 
the previous definition
In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:114:1: error: "__fnstcw" 
redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:105:1: error: this is the location of 
the previous definition
In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:115:1: error: "__fnstenv" 
redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:104:1: error: this is the location of 
the previous definition
In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:116:1: error: "__fnstsw" 
redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:106:1: error: this is the location of 
the previous definition
*** [exponential_test.o] Error code 1

make[6]: stopped in /usr/src/lib/msun/tests
1 error

This is on a cleanly installed 11.2-BETA2, with the following in
/etc/src.conf:

MK_CLANG=no
MK_CLANG_BOOTSTRAP=no
MK_CLANG_EXTRAS=no
MK_CLANG_FULL=no
MK_CLANG_IS_CC=no
MK_GCC=yes
MK_GCC_BOOTSTRAP=yes
MK_GNUCXX=yes
MK_LLD=no
MK_LLD_BOOTSTRAP=no
MK_LLD_IS_LD=no
MK_LLDB=no

It looks like the macros in fenv.h and ieeefp.h are clashing, and Ngie
Cooper worked around it in
https://svnweb.freebsd.org/changeset/base/321483, but for some reason
only for clang.

But even after I applied a band-aid for this, it dies on another part:

--- all_subdir_stand ---
cc1: warnings being treated as errors
/usr/src/stand/i386/gptboot/gptboot.c: In function 'main':
/usr/src/stand/i386/gptboot/gptboot.c:258: warning: declaration of 'autoboot' 
shadows a global declaration
/usr/src/stand/common/bootstrap.h:64: warning: shadowed declaration is here
*** [gptboot.o] Error code 1

make[5]: stopped in /usr/src/stand/i386/gptboot
1 error

Here the warning is right, as 'autoboot' is indeed shadowed, though it
may not be problematic in practice.


> The build break is due to compiling /usr/src/sys/crypto/aesni/aesni_ghash.c, 
> which in turn #includes wmmintrin.h, emmintrin.h, and smmintrin.h which are 
> all clang-specific headers.

In this case, you cannot compile it with gcc-in-base, since it is too
old to have the right intrinsics headers.


> I am rebuilding with MK_CRYPT=no to see if this works around the problem, but 
> it seems like perhaps just this one aesni module should not be built rather 
> than all of CRYPT having to be disabled.

Probably only the module should be disabled, if the version of gcc is
too old.  I have no idea where the needed intrinsics headers were added
upstream.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: uptime / w coredumping on RELENG11 (i386 only)

[Dimitry Andric]

On 17 May 2018, at 02:01, Dewayne Geraghty 
<dewayne.gerag...@heuristicsystems.com.au> wrote:
> 
> On 17/05/2018 7:17 AM, Dimitry Andric wrote:
>> On 16 May 2018, at 15:54, Mike Tancsa <m...@sentex.net> wrote:
>>> On 5/15/2018 2:31 PM, Dimitry Andric wrote:
>>>> On 15 May 2018, at 20:22, Mike Tancsa <m...@sentex.net> wrote:
>>>>>> Anyone else see this ?
>>>> See <https://bugs.freebsd.org/227552>.  There is a fix coming up.
>>> I tried the patch and did a full rebuild and it indeed fixed the problem
>>> for me.  Is the bug potentially more wide spread that just libxo ? Also
>>> does it possibly affect amd64, just in a non obvious way ?
>> Yes to both, at least theoretically.  The problem is actually in
>> elftoolchain's strip command, which can mess up the TLS section in an
>> executable or shared library.  When the dynamic linker loads such a bad
>> file, it will setup incorrect TLS data, which can lead to crashes.
>> 
>> In case of libxo.so.0, this appears to have been caused by clang 6
>> giving a slightly different ELF layout than clang 5.  During buildworld,
>> libxo.so.0 is built with debugging information, which is later copied
>> to a libxo.so.0.debug file, while it is removed from the original
>> libxo.so.0 file.
>> 
>> Up to this point, everything is still fine with libxo.so.0, still, but
>> during installworld, the file is stripped *again*, by install -s (this
>> is something we should revisit because it seems no longer useful).  This
>> second round of stripping messes up the TLS section.
>> 
>> -Dimitry
>> 
> Revisit? Perhaps, but it seems that its a regression against clang6 over
> clang5.

Well, my argument is that as long as any compiler and linker spit out a
valid ELF file, strip should not corrupt it. :)

And for certain, running strip twice on the same file should never
change it (except for maybe timestamp-related fields).


> Looking at
> https://svnweb.freebsd.org/base?view=revision=333600
> its appears that the section flags are correctly applied now.  When
> 333600 enters 11.1Beta?, do you think the build/installation process
> requires revision?

No, it should be enough to fix strip.  In the installworld stage, the
copy of strip built during the cross-tools stage is used.

What I meant with revisiting this, is that historically we've stripped
executables and shared libraries during installworld, as those could
optionally have been built with debug information.

But since the introduction of /usr/lib/debug, this is no longer the
case: effectively, everything is built *with* debug information, and
this debug information is already stripped out and moved to separate
files during the buildworld stage.

Therefore, it is no longer necessary to strip those files again.


> Its a little disappointing to hear that the stripping process breaks the
> output, if applied >1.

And that was actually the bug.  Note that this only happens for TLS
segments, which are not used very often.  That is probably the reason
we never ran into problems before.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: uptime / w coredumping on RELENG11 (i386 only)

[Dimitry Andric]

On 16 May 2018, at 15:54, Mike Tancsa <m...@sentex.net> wrote:
> 
> On 5/15/2018 2:31 PM, Dimitry Andric wrote:
>> On 15 May 2018, at 20:22, Mike Tancsa <m...@sentex.net> wrote:
>>> 
>>>> 
>>>> Anyone else see this ?
>> 
>> See <https://bugs.freebsd.org/227552>.  There is a fix coming up.
> 
> I tried the patch and did a full rebuild and it indeed fixed the problem
> for me.  Is the bug potentially more wide spread that just libxo ? Also
> does it possibly affect amd64, just in a non obvious way ?

Yes to both, at least theoretically.  The problem is actually in
elftoolchain's strip command, which can mess up the TLS section in an
executable or shared library.  When the dynamic linker loads such a bad
file, it will setup incorrect TLS data, which can lead to crashes.

In case of libxo.so.0, this appears to have been caused by clang 6
giving a slightly different ELF layout than clang 5.  During buildworld,
libxo.so.0 is built with debugging information, which is later copied
to a libxo.so.0.debug file, while it is removed from the original
libxo.so.0 file.

Up to this point, everything is still fine with libxo.so.0, still, but
during installworld, the file is stripped *again*, by install -s (this
is something we should revisit because it seems no longer useful).  This
second round of stripping messes up the TLS section.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: uptime / w coredumping on RELENG11 (i386 only)

[Dimitry Andric]

On 15 May 2018, at 20:22, Mike Tancsa  wrote:
> 
> On 5/15/2018 2:10 PM, Mike Tancsa wrote:
>> Wasnt sure if it was my VM, so i took a stock 11.1R installed it on a
>> new VM and updated the sources to today.  Stock GENERIC kernel
>> 
>> **  this is i386 **
>> 
>> 
>> via truss (w)
>> 
>> access("/etc/localtime",R_OK)= 0 (0x0)
>> open("/etc/localtime",O_RDONLY,06605223677)  = 5 (0x5)
>> fstat(5,{ mode=-r--r--r-- ,inode=1367764,size=118,blksize=32768 }) = 0 (0x0)
>> read(5,"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0"...,29000) = 118 (0x76)
>> close(5) = 0 (0x0)
>> SIGNAL 11 (SIGSEGV) code=SEGV_MAPERR trapno=12 addr=0x28000184
>> process killed, signal = 11 (core dumped)
>> 
>> (gdb) bt
>> #0  ifree (tsd=0x2800) at arena.h:799
>> #1  0x2814b506 in __free (ptr=0x280601ef) at tsd.h:716
>> #2  0x2808bb07 in xo_do_emit_fields () at
>> /usr/src/contrib/libxo/libxo/libxo.c:6419
>> #3  0x28089a1c in xo_do_emit (xop=, flags=> optimized out>, fmt=0x804ad4d "{:time-of-day/%s} ")
>>at /usr/src/contrib/libxo/libxo/libxo.c:6470
>> #4  0x28089b61 in xo_emit (fmt=0x804ad4d "{:time-of-day/%s} ") at
>> /usr/src/contrib/libxo/libxo/libxo.c:6541
>> #5  0x08049f50 in ?? ()
>> #6  0x0804ad4d in ?? ()
>> #7  0xbfbfe044 in ?? ()
>> #8  0x28065e58 in list_global () from /libexec/ld-elf.so.1
>> #9  0x in ?? ()
>> Current language:  auto; currently minimal
>> (gdb)
>> 
>> I dont have debug symbols yet
>> 
>> r333636
>> 
>> Anyone else see this ?

See .  There is a fix coming up.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: lint errors in stable/11

[Dimitry Andric]

On 10 May 2018, at 12:47, Rick Miller  wrote:
> 
> On Thu, May 10, 2018 at 6:35 AM Rick Miller  wrote:
...
>> Performing a release build via release/release.sh in r331337 of stable/11
>> errors citing the lack of lint. It’s understood lint was removed from
>> stable/11 so src.conf includes WITHOUT_LINT, but errors persist. As the
>> code review alludes to[1], lint is irrelevant here. It seems WITHOUT_LINT
>> may not be the only thing I’m looking for. What is the best approach for
>> mitigating these errors?
>> 
>> 
> Here’s the error w/o email munging:
> 
> ===> usr.bin/xlint/xlint (all)
> /data/dists/11.1.9.0-amd64-md/usr/src/contrib/apr/atomic/uni
> x/builtins.c:71:53:
> warning: passing 'const void *' to parameter of type 'volatile void *'
> discards
> qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
> 
>return (void*) __sync_val_compare_and_swap(mem, cmp, with);
> 
>^~~
> 
> 1 warning generated.
> 
> ===> usr.bin/xlint/llib (all)
> 
> sh: lint: not found

Are you building on a -CURRENT host?  If so, see the previous mail
thread about this:

https://lists.freebsd.org/pipermail/freebsd-stable/2017-November/088092.html

and https://bugs.freebsd.org/223892.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: gptboot broken when compiled with clang 6 and WITHOUT_LOADER_GELI -- clang 5 is OK

[Dimitry Andric]

On 26 Apr 2018, at 12:06, Dimitry Andric <d...@freebsd.org> wrote:
> 
> On 26 Apr 2018, at 06:17, Dewayne Geraghty 
> <dewayne.gerag...@heuristicsystems.com.au> wrote:
>> 
>> Andre, You're not alone.  I think there's a problem with clang6 on i386
>> FreeBSD 11.1X, refer:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227552
>> https://forums.freebsd.org/threads/uptime-w-i386-breakage.65584/
>> and perhaps also on amd64, search for
>> https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=clang_id=226390.
>> 
>> Without time to investigate I've reverted userland
>> FreeBSD 11.2-PRERELEASE  r332843Mamd64 1101515 1101509
>> FreeBSD 11.2-PRERELEASE  r332843Mi386 1101515 1101509
> 
> As noted in another post, I cannot reproduce the problems with gptboot,
> but with FreeBSD-11.2-PRERELEASE-i386-20180420-r332802, I do indeed see
> w and uptime crashing in libxo:
> 
> (gdb) bt
> #0  ifree (tsd=0x2800) at arena.h:799
> #1  0x2814b506 in __free (ptr=0x280601ef) at tsd.h:716
> #2  0x2808bb07 in xo_do_emit_fields () at 
> /usr/src/contrib/libxo/libxo/libxo.c:6419
> #3  0x28089a1c in xo_do_emit (xop=, flags= optimized out>, fmt=0x804ad4d "{:time-of-day/%s} ") at 
> /usr/src/contrib/libxo/libxo/libxo.c:6470
> #4  0x28089b61 in xo_emit (fmt=0x804ad4d "{:time-of-day/%s} ") at 
> /usr/src/contrib/libxo/libxo/libxo.c:6541
> #5  0x08049f50 in main (argc=, argv= out>) at /usr/src/usr.bin/w/w.c:475
> #6  0x080494cd in _start1 ()
> #7  0x08049448 in _start ()
> #8  0x in ?? ()
> 
> Not sure if this has anything to do with clang though, it looks more
> like a double free to me, at first glance.  I'll do some debugging.

Strangely, simply recompiling libxo fixes the problem, or at least works
around it.  This is on the r332802 snapshot, so I guess the libxo.so.0
file shipped may be broken, somehow.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: gptboot broken when compiled with clang 6 and WITHOUT_LOADER_GELI -- clang 5 is OK

[Dimitry Andric]

On 26 Apr 2018, at 06:17, Dewayne Geraghty 
 wrote:
> 
> Andre, You're not alone.  I think there's a problem with clang6 on i386
> FreeBSD 11.1X, refer:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227552
> https://forums.freebsd.org/threads/uptime-w-i386-breakage.65584/
> and perhaps also on amd64, search for
> https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=clang_id=226390.
> 
> Without time to investigate I've reverted userland
> FreeBSD 11.2-PRERELEASE  r332843Mamd64 1101515 1101509
> FreeBSD 11.2-PRERELEASE  r332843Mi386 1101515 1101509

As noted in another post, I cannot reproduce the problems with gptboot,
but with FreeBSD-11.2-PRERELEASE-i386-20180420-r332802, I do indeed see
w and uptime crashing in libxo:

(gdb) bt
#0  ifree (tsd=0x2800) at arena.h:799
#1  0x2814b506 in __free (ptr=0x280601ef) at tsd.h:716
#2  0x2808bb07 in xo_do_emit_fields () at 
/usr/src/contrib/libxo/libxo/libxo.c:6419
#3  0x28089a1c in xo_do_emit (xop=, flags=, fmt=0x804ad4d "{:time-of-day/%s} ") at 
/usr/src/contrib/libxo/libxo/libxo.c:6470
#4  0x28089b61 in xo_emit (fmt=0x804ad4d "{:time-of-day/%s} ") at 
/usr/src/contrib/libxo/libxo/libxo.c:6541
#5  0x08049f50 in main (argc=, argv=) 
at /usr/src/usr.bin/w/w.c:475
#6  0x080494cd in _start1 ()
#7  0x08049448 in _start ()
#8  0x in ?? ()

Not sure if this has anything to do with clang though, it looks more
like a double free to me, at first glance.  I'll do some debugging.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: gptboot broken when compiled with clang 6 and WITHOUT_LOADER_GELI -- clang 5 is OK

[Dimitry Andric]

On 25 Apr 2018, at 18:58, Andre Albsmeier  wrote:
> 
> I have set up a new system disk for an i386 11.2-PRERELEASE box. I did the
> usual
> 
> gpart create -s gpt $disk
> gpart add -t freebsd-boot -s 984 $disk
> gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 $disk
> ...
> 
> thing, just to notice that the box wouldn't boot. It seems to hang where
> stage 2 should be run -- when the '\' should start spinning the screen
> turns white and the box hangs (tested on two machines, an Asus P5W and a
> Supermicro A2SAV).
> 
> So I replaced gptboot on the new disk by the one from an older machine
> and everything was fine. I wanted to find out what is actually causing
> the issue and recompiled /usr/src/stand after updating the old sources
> in several steps.
> 
> Eventually it turned out that it depends on the compiler. When compiling
> the latest /usr/src/stand with clang 5.0.1 the resulting gptboot works.
> When using 6.0.0 it doesn't. To be exact, it's gptboot.o which is causing
> the problems. When using a gptboot.o from a clang 5 system it is OK, when
> using a gptboot.o from a clang 6 system it fails.
> 
> To add more confusion: I usually have WITHOUT_LOADER_GELI in my make.conf.
> When removing this, the resulting gptboot works even when compiled with
> clang 6...
> 
> I can reproduce this in case s.o. wants me to do some tests...

I can't reproduce it on my end, unfortunately.  I downloaded the latest
FreeBSD-11.2-PRERELEASE-i386-20180420-r332802 snapshot, installed it to
a GPT partitioned disk, and it boots just fine.

This snapshot corresponds to r332802, which has clang 6.0.0, with the
EFLAGS change still reverted, so I assume its copy of gptboot is also
compiled with that.

Which exact revision of the base system were you using?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: buildworld from 11.1-R-p8 to stable/11 fails in contrib/llvm

[Dimitry Andric]

On 31 Mar 2018, at 17:51, Thiemo Nordenholz  wrote:
> 
> having first upgraded from 11.1-RELEASE to FreeBSD 11.1-RELEASE-p8 amd64 via 
> freebsd-upgrade, I wanted to switch to -stable and svnup'ed to r331758.
> 
> Subsequent "make buildworld" fails when compiling what looks like a part of 
> llvm:
> 
> c++-O2 -pipe -I/usr/src/contrib/llvm/tools/lldb/include 
> -I/usr/src/contrib/llvm/tools/lldb/source 
> -I/usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/FreeBSD 
> -I/usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/POSIX 
> -I/usr/src/contrib/llvm/tools/lldb/source/Plugins/Process/Utility 
> -I/usr/obj/usr/src/lib/clang/libllvm -I/usr/obj/usr/src/lib/clang/libclang 
> -DLLDB_DISABLE_PYTHON -I/usr/src/contrib/llvm/tools/clang/include 
> -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER 
> -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include 
> -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS 
> -DNDEBUG -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.1\" 
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.1\" -DDEFAULT_SYSROOT=\"\" 
> -ffunction-sections -fdata-sections -MD -MF.depend.Host_common_MainLoop.o 
> -MTHost/common/MainLoop.o -fstack-protector-strong -Qunused-arguments  
> -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c 
> /usr/src/contrib/llvm/tools/lldb/source/Host/common/MainLoop.cpp -o 
> Host/common/MainLoop.o
> /usr/src/contrib/llvm/tools/lldb/source/Host/common/MainLoop.cpp:144:10: 
> error: no viable conversion from returned value of type 'int' to function 
> return type 'sigset_t' (aka '__sigset')
>  return 0;
> 
> As the respective source code seems to be in the tree for quite some time, I 
> wonder why I cannot seem to find other such issues occurring - what am I 
> missing here? I have no /etc/make.conf, no MAKEFLAGS set, and emptied 
> /usr/obj/ before each of my attempts (-j8, -j4, and no flags, with clang and 
> gcc (see below)).

My guess is that your source tree is inconsistently updated.  This error can 
only occur when SIGNAL_POLLING_UNSUPPORTED is defined to 1 in MainLoop.cpp, and 
that can only occur if your copy of lib/clang/include/lldb/Host/Config.h is 
either out of date, corrupt, or empty.

Can you check whether the following lines exist in your copy of 
lib/clang/include/lldb/Host/Config.h:

#define HAVE_SYS_EVENT_H 1

#define HAVE_PPOLL 1

If not, it is best to delete your source tree and do a fresh checkout.


> Trying "env WITHOUT_CLANG=YES WITH_GCC=YES make buildworld" also fails, 
> however in /usr/src/lib/libc/tests/ssp (as make says):
> 
> cc -O2 -pipe -fstack-protector-all -Wstack-protector -fsanitize=bounds -g 
> -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k 
> -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
> -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch 
> -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments  -o 
> h_raw.full h_raw.o
> /usr/obj/usr/src/tmp/usr/bin/ld: 
> /usr/obj/usr/src/tmp/usr/lib/clang/5.0.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a:
>  No such file: No such file or directory
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> Again - as I did not see similar issues on the mailing list, I wonder what's 
> going on here. Perhaps anyone else can shed some light or give me a hint on 
> how to proceed. I'd really like to try out the graphics/drm-next-kmod port...

In this case, I think you would also need WITHOUT_CLANG_BOOTSTRAP.  Or 
alternatively, build using WITHOUT_TESTS.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: zfs problems after rebuilding system [SOLVED]

[Dimitry Andric]

On 3 Mar 2018, at 13:56, Bruce Evans <b...@optusnet.com.au> wrote:
> 
> On Sat, 3 Mar 2018, tech-lists wrote:
>> On 03/03/2018 00:23, Dimitry Andric wrote:
...
>>> Whether this is due to some sort of BIOS handover trouble, or due to
>>> cheap and/or crappy USB-to-SATA bridges (even with brand WD and Seagate
>>> disks!), I have no idea.  I attempted to debug it at some point, but
>>> a well-placed "sleep 10" was an acceptable workaround... :)
>> 
>> That fixed it, thank you again :D
> 
> That won't work for the boot drive.
> 
> When no boot drive is detected early enough, the kernel goes to the
> mountroot prompt.  That seems to hold a Giant lock which inhibits
> further progress being made.  Sometimes progress can be made by trying
> to mount unmountable partitions on other drives, but this usually goes
> too fast, especially if the USB drive often times out.

What I would like to know, is why our USB stack has such timeout issues
at all.  When I boot Linux on the same type of hardware, I never see USB
timeouts.  They must be doing something right, or maybe they just don't
bother checking some status bits that we are very strict about?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: "Cross" building for same architecture, different CPUTYPE

[Dimitry Andric]

On 4 Mar 2018, at 18:29, Christian Ullrich  wrote:
> 
> I'm trying to buildworld/buildkernel of stable/11 r330373 for an Intel Atom 
> CPU (CPUTYPE=slm) on a (slightly faster, CPUTYPE=core-avx2) build machine. 
> That works fine, but make installkernel on the Atom box fails with a SIGILL 
> (signal 4) in the "install" command (sorry, no log or screenshot).
> 
> As far as I can tell, this is because installkernel uses the install from 
> ...obj.../tmp/legacy/usr/bin, which is built for the host. Disassembling the 
> binary shows that it uses AVX opcodes. The "main" part of the build output 
> correctly respects the CPUTYPE override.

How are you overriding?  As far as I know, the bootstrap-tools are built
using NO_CPU_CFLAGS, which disables any cpu-specific CFLAGS.  However,
this does not work in two cases:

1) If you assign CPUTYPE with = instead of ?= (in make.conf or src.conf)
2) If you set -march= flags in CFLAGS directly

With 1), if you specify CPUTYPE= as a variable directly on the make
command line, it will effectively disable NO_CPU_CFLAGS.


> I suppose I'm doing something wrong here, but what? It must be possible to 
> build for a different CPU of the same family, right? I even tried running a 
> cross build (TARGET=amd64 TARGET_ARCH=amd64), but since the build host _is_ 
> amd64, the Makefiles laughed at me and only did the normal build.
> 
> The command that did not work was:
> 
> MAKEOBJDIRPREFIX=/usr/obj/slm make CPUTYPE=slm buildworld buildkernel
> 
> I have CPUTYPE?=core-avx2 in make.conf, but that should be irrelevant here.

Actually, that *is* relevant for the stages after bootstrap-tools,
build-tools and cross-tools.  E.g. 4.x and later.

Again, this depends on how exactly you are overriding CPUTYPE.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: zfs problems after rebuilding system

[Dimitry Andric]

On 3 Mar 2018, at 01:09, Freddie Cash  wrote:
> 
> You said it's an external USB drive, correct? Could it be a race condition
> during the boot process where the USB mass storage driver hasn't detected
> the drive yet when /etc/rc.d/zfs is run?
> 
> As a test, add a "sleep 30" in that script before the "zfs mount -a" call
> and reboot.

Indeed.  I have had the following for a few years now, due to USB drives
with ZFS pools:

--- /usr/src/etc/rc.d/zfs   2016-11-08 10:21:29.820131000 +0100
+++ /etc/rc.d/zfs   2016-11-08 12:49:52.971161000 +0100
@@ -25,6 +25,8 @@

 zfs_start_main()
 {
+   echo "Sleeping for 10 seconds to let USB devices settle..."
+   sleep 10
zfs mount -va
zfs share -a
if [ ! -r /etc/zfs/exports ]; then

For some reason, USB3 (xhci) controllers can take a very, very long time
to correctly attach mass storage devices: I usually see many timeouts
before they finally get detected.  After that, the devices always work
just fine, though.

Whether this is due to some sort of BIOS handover trouble, or due to
cheap and/or crappy USB-to-SATA bridges (even with brand WD and Seagate
disks!), I have no idea.  I attempted to debug it at some point, but
a well-placed "sleep 10" was an acceptable workaround... :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: i386 with 4GB RAM: less than 2GB available on A2SAV (Intel Atom E3940)

[Dimitry Andric]

On 28 Jan 2018, at 15:57, Andre Albsmeier  wrote:
> I have a lot of machines running with 4 GB physical RAM and, for
> some reasons, I still have to use a 32 bits OS.
> 
> All of them show something between 3 and 3.5 GB of RAM available
> in dmesg but the brand new Supermicro A2SAV really shocked me:
> 
> FreeBSD 11.1-STABLE #0: Mon Jan 15 06:57:10 CET 2018
> ...
> real memory  = 4294967296 (4096 MB)
> avail memory = 1939558400 (1849 MB)
> ...
> 
> So do people have any ideas how I might get a bit closer to at least
> 3 GB? I assume there are no FreeBSD knobs which might help but hope
> dies last...

This is a common problem on i386.  Most likely some ranges are reserved
for I/O mappings, such as video cards.  If you boot with -v, I think the
kernel prints an overview of the physical ram chunks available?  I don't
know of any other way to get such an overview.

Another option is to try PAE, but I have no idea how stable that is...

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: why does buildworld fail on stable/11 ?

[Dimitry Andric]

On 24 Jan 2018, at 09:51, Scott Bennett  wrote:
> 
> Subject: Re: why does buildworld fail on stable/11 ?
> 
> I wrote:
>>On Mon, 22 Jan 2018 12:42:58 + lists  wrote:
>>> On 22/01/2018 09:17, Scott Bennett wrote:
Anyway, I'm stuck.  Can someone please tell me what is going wrong and
 how to fix it?  I'd really like to be able to update my system, not only to
 keep it reasonably current, but also to be able to customize a kernel.  
 Thanks
 in advance for any suggestions/solutions.
>>> 
> [much deleted  --SB]
>>> then
>>> 
>>> [/usr/src #] make cleandir && make clean && make buildworld && make
>>> buildkernel && make installkernel && mergemaster -p
>> 
>>At this point, that looks very optimistic, to say the least. :-)  I've
>> tried "make cleanworld" (with /etc/make.conf still in place), and it failed
>> exactly like the buildworld example I posted before.
> 
> Okay.  Here's what happened.
> 
> Script started on Wed Jan 24 02:17:30 2018
> hellas#   mv /etc/make.conf{,.save}
> hellas#   mv /etc/src.conf{,.save}
> hellas#   cd /usr/src
> hellas#   make cleandir
> "/usr/src/share/mk/local.sys.mk", line 51: Malformed conditional 
> (${.MAKE.MODE:Mmeta*} != "")
> "/usr/src/share/mk/local.sys.mk", line 58: Malformed conditional 
> (${.MAKE.MODE:Mnofilemon} == "")
> "/usr/src/share/mk/local.sys.mk", line 76: if-less else
> "/usr/src/share/mk/local.sys.mk", line 79: if-less endif
> "/usr/src/share/mk/sys.mk", line 476: if-less endif
> bmake: fatal errors encountered -- cannot continue

Looks like your make is broken.  What is the output of "which make"?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: 11.1-RELEASE from SVN

[Dimitry Andric]

On 23 Jul 2017, at 14:36, Sydney Meyer via freebsd-stable 
 wrote:
> 
> are there any "last-minute" issues/changes with the 11.1-RELEASE build?
> 
> The 11.1-RELEASE appears to be gone from SVN after the switch from 
> releng/11.1 to -RELEASE and the Press Release Schedule seems to have changed 
> without notice.
> 
> Not that this is an issue to me, as the releases aren't officially released 
> until @re sends the announcment email, i'm just curious..

Don't worry, the release engineers are furiously working behind the
scenes to get all the correct bits built, verified and uploaded.  This
will just take a few days.  The schedule is here:

https://www.freebsd.org/releases/11.1R/schedule.html

It is also perfectly normal for stable/11 to be renamed -STABLE again,
this is the usual procedure after tagging releases in releng.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition

[Dimitry Andric]

On 30 Apr 2017, at 14:06, Konstantin Belousov <kostik...@gmail.com> wrote:
> 
> On Sat, Apr 29, 2017 at 07:55:24PM +0200, Dimitry Andric wrote:
...
>> So in that case, if Jung-uk's solution works, it is probably the best
>> way forward, and it can even be upstreamed.  Jung-uk, how does your
>> patch handle an updated header under /usr/include which contains e.g.
>> new definitions, which are not in the fixed includes directory?
> 
> Am I right that Jung-uk fix replaces vm_ooffset_t and vm_pindex_t with
> explicit int64_t and uint64_t use, as the course of action for gcc
> fixincludes step ?  If yes, I completely disagree.
> 
> The change blocks any future changes to the type that might occur in the
> base system, for the code compiled by gcc.  End result might be as bad
> as mismatched ABI, in the worst case.
> 
> I share the opinion that fixincludes is not only useless, but really
> damaging.  Gcc ships workarounds for e.g. issues in X11 headers, which
> application depends on the presence of the corresponding headers at the
> gcc build time.  For clean (poudriere-like) builds these fixes are never
> applied, so port build results are inconsistent, at least.
> 
> Nobody so far explained why fixincludes is needed for the modern base
> headers. IMO if we have real problems in headers we ship, we must fix it
> in the base.
> 
> With all of the above, IMO most sane way to fix problems is to
> rename fixincludes directory to some name which is ignored by gcc,
> e.g. include-fixed -> include-fixed.saved. This can be done as
> post-installation step in the ports.

I agree, it would be best to avoid storing any copies of system headers
completely.

Maybe the port can have an option FIX_INCLUDES, which defaults to off?
I am not sure if there is anybody that really wants these 'fixed'
headers, though. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition

[Dimitry Andric]

On 29 Apr 2017, at 19:00, Gerald Pfeifer  wrote:
> 
> On Thu, 27 Apr 2017, Jung-uk Kim wrote:
>>> I found the problem,  but I do not know how to resolve this.  When you
>>> install the GCC compiler from the PKG repository it appears to create a
>>> modified set of include files from the system (default?) include files
>>> (/usr/include).  However, when the modified /usr/include/sys/types.h
>>> file is created, the typedef for vm_ooffset_t is modified,  and there is
>>> no reference to __vm_ooffset_t that the compiler can resolve.
>>> 
>>> < typedef   __int64_t   vm_ooffset_t;
>>> ---
 typedef   __vm_ooffset_t  vm_ooffset_t;
>> ...
>> You have to rebuild lang/gcc from the ports tree to fix this problem.
>> 
>> https://lists.freebsd.org/pipermail/freebsd-current/2017-February/064937.html
> Does this mean that the GCC port/package needs to be updated?  If so,
> should I file a PR report on this issue?
> I (temporarily) fixed this problem by hand editting the modified types.h
> file and things seem to work.
 I already wrote a patch (attached). :-)
>> If the maintainer (gerald) approves.  CC'd.
> 
> Thanks for bringing this to my attention.
> 
> Can you please help me understand why this is necessary?

This is because gcc's fixincludes process makes copies of certain system
headers (in this case, /usr/include/sys/types.h) with slight
modifications.  Then, it places the directory containing the modified
headers at the front of the include search path.  So far so good.

Now, whenever sys/types.h is updated, as happened with the vm_ooffset_t
change, the header in gcc's own preferred directory might not match the
definitions which are expected, leading to compilation errors.


> If the
> port/package is builts from scratch, does this trigger the problem?

Yes, basically you need to rebuild all gcc ports from scratch, whenever
you update any system header that matches gcc's list of files it wants
to modify.

But getting those errors in the first place can be very confusing to an
end-user.  And having to rebuild all those ports might be a burden.

As some people pointed out, simply moving away or deleting the directory
with fixed includes appears to work around the problems.  So maybe the
question is if gcc really needs to modify those headers at all?

I have looked at gcc's build system a bit, but it does not seem very
easy to disable the fixincludes step.  I guess that is simply not
supported.

So in that case, if Jung-uk's solution works, it is probably the best
way forward, and it can even be upstreamed.  Jung-uk, how does your
patch handle an updated header under /usr/include which contains e.g.
new definitions, which are not in the fixed includes directory?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: buildworld fails immediately

[Dimitry Andric]

On 23 Mar 2017, at 06:38, Aryeh Friedman  wrote:
> 
> root@lilith:/usr/src # make buildworld
> make[1]: "/usr/src/Makefile.inc1" line 144: SYSTEM_COMPILER: Determined
> that CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
...
> c++  -O2 -pipe -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include
> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
> -D__STDC_CONSTANT_MACROS -DNDEBUG
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\"
> -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -MD -MF.depend.Support_APInt.o
> -MTSupport/APInt.o -Qunused-arguments
> -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions
> -fno-rtti  -stdlib=libc++ -Wno-c++11-extensions  -c
> /usr/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o
> c++: error: unable to execute command: Bus error (core dumped)
> c++: error: clang frontend command failed due to signal (use -v to see
> invocation)
> FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM
> 3.9.1)
> Target: x86_64-unknown-freebsd11.0
> Thread model: posix
> InstalledDir: /usr/bin
> c++: note: diagnostic msg: PLEASE submit a bug report to
> https://bugs.freebsd.org/submit/ and include the crash backtrace,
> preprocessed source, and associated run script.
> c++: note: diagnostic msg:
> 
> 
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> c++: note: diagnostic msg: /tmp/APInt-8fe456.cpp
> c++: note: diagnostic msg: /tmp/APInt-8fe456.sh

If it's consistently repeatable, please create a tarball of the
/tmp/APInt-*.{cpp.sh} files, and upload those to a bug report.  If it's
not consistently repeatable, check your hardware (e.g. run memtest86).

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: 11-STABLE fails to build with MK_OFED enabled

[Dimitry Andric]

On 15 Mar 2017, at 13:42, Pete French  wrote:
> 
> 
> 
> /usr/src/sys/modules/mlx4ib/../../ofed/drivers/infiniband/hw/mlx4/sysfs.c:90:22:
>  error:
>  format specifies type 'unsigned long long *' but the argument has type
>  'u64 *' (aka 'unsigned long *') [-Werror,-Wformat]
>sscanf(buf, "%llx", _ag_val);
>    ^~~~
> %lx
> 
> Fairly trivial to fix obviously - I chnaged it to %lx - but not sure that 
> would
> work on non 64 bit platforms.

Hi Pete,

I have merged the fix (r310232) in r315328.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Building i386 on i386

[Dimitry Andric]

On 01 Feb 2017, at 14:27, hartmut.bra...@dlr.de wrote:
> 
> is $subj still supposed to work on 11.0? I get a 'virtual memory exhausted' 
> during linking of clang.

How much memory does your machine have?  I build this regularly, on a VM with 
2G RAM (and 4G swap).

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 10.3-RELEASE-p13 "unsupported file layout"

[Dimitry Andric]

On 11 Jan 2017, at 23:35, George Mitchell <george+free...@m5p.com> wrote:
> 
> On 01/11/17 17:25, Dimitry Andric wrote:
>> On 11 Jan 2017, at 21:24, George Mitchell <george+free...@m5p.com> wrote:
...
>>> building shared library libc.so.7
>>> cc (a very long compile line)
>>> ./libc.so.7: unsupported file layout
>> 
>> If things went correctly, the libc.so.7 file should be in
>> /usr/obj/usr/src/lib/libc.  If so, can you post the output of:
>> 
>> file /usr/obj/usr/src/lib/libc/libc.so.7
>> readelf -h /usr/obj/usr/src/lib/libc/libc.so.7
>> 
>> -Dimitry
>> 
> root@sullivan:/usr/src # file /usr/obj/usr/src/lib/libc/libc.so.7
> /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit LSB shared object,
> x86-64, version 1 (FreeBSD), dynamically linked, not stripped
> root@sullivan:/usr/src # readelf -h /usr/obj/usr/src/lib/libc/libc.so.7
> 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:  DYN (Shared object file)
>  Machine:   Advanced Micro Devices X86-64
>  Version:   0x1
>  Entry point address:   0x3aee0
>  Start of program headers:  64 (bytes into file)
>  Start of section headers:  1644696 (bytes into file)
>  Flags: 0x0
>  Size of this header:   64 (bytes)
>  Size of program headers:   56 (bytes)
>  Number of program headers: 6
>  Size of section headers:   64 (bytes)
>  Number of section headers: 40
>  Section header string table index: 37
> 
> That isn't the only libc.so.7 in my build tree, though:
> 
> /usr/obj/usr/src/tmp/lib/libc.so.7:ELF 64-bit LSB shared object,
> x86-64, version 1 (FreeBSD), dynamically linked, not stripped
> /usr/obj/usr/src/lib/libc/libc.so.7:   ELF 64-bit LSB shared object,
> x86-64, version 1 (FreeBSD), dynamically linked, not stripped
> /usr/obj/lib32/usr/src/lib/libc/libc.so.7: ELF 32-bit LSB shared object,
> Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped

Hm, that all looks perfectly normal, supposing that you are on amd64.
Maybe it's the stripping that fails?  Do you have STRIP defined in your
environment, or make.conf?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 10.3-RELEASE-p13 "unsupported file layout"

[Dimitry Andric]

On 11 Jan 2017, at 21:24, George Mitchell  wrote:
> 
> After today's OpenSSH security message, I did:
> 
> cd /usr
> rm -rf obj

Hmm, not sure if it is wise to completely remove the /usr/obj directory.
Did you re-create it afterwards?


> cd src
> svn update -r311916
> make buildworld
> 
> After a while, I got to:
> 
> building shared library libc.so.7
> cc (a very long compile line)
> ./libc.so.7: unsupported file layout

If things went correctly, the libc.so.7 file should be in
/usr/obj/usr/src/lib/libc.  If so, can you post the output of:

file /usr/obj/usr/src/lib/libc/libc.so.7
readelf -h /usr/obj/usr/src/lib/libc/libc.so.7

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Cannot buildworld r310779 on FreeBSD 11.0-STABLE #0 r310265 amd64

[Dimitry Andric]

On 29 Dec 2016, at 23:51, Jakub Lach  wrote:
> 
> I'm quite puzzled. Emptied /usr/obj, make cleandir and
> # make buildworld && make buildkernel... svn st is clear.
...
> /usr/src/usr.bin/dtc/fdt.cc -o fdt.o
> /usr/src/usr.bin/dtc/fdt.cc:1593:8: error: cannot initialize a variable of
> type 'char *' with an
>  rvalue of type 'const char *'
>char *val = strchr(def, '=');
>  ^ 

This was fixed in head with r309191, but it was not MFC'd yet.  I have
done so in r310808.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Compile error while building world

[Dimitry Andric]

On 28 Dec 2016, at 23:47, Jack Raats  wrote:
> 
> At this moment I’ll get the following error while compiling buildworld
> 
> 
> 
> --- clang-tblgen.full ---
> 
> c++ -O2 -pipe -I/usr/obj/usr/src/tmp/usr/src/lib/clang/libllvm 
> -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_ON_UNIX 
> -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG 
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
> -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -g -Qunused-arguments 
> -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions 
> -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -static 
> -L/usr/obj/usr/src/tmp/legacy/usr/lib -o clang-tblgen.full  
> ClangASTNodesEmitter.o ClangAttrEmitter.o ClangCommentCommandInfoEmitter.o 
> ClangCommentHTMLNamedCharacterReferenceEmitter.o 
> ClangCommentHTMLTagsEmitter.o ClangDiagnosticsEmitter.o 
> ClangSACheckersEmitter.o NeonEmitter.o TableGen.o 
> /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmminimal/libllvmminimal.a  
> -lncursesw  -lpthread -legacy
> 
> /usr/lib/libpthread.a(thr_syscalls.o): In function `__thr_fdatasync':
> 
> /usr/src/lib/libthr/thread/thr_syscalls.c:(.text+0xe51): undefined reference 
> to `__sys_fdatasync'
> 
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> *** [clang-tblgen.full] Error code 1
> 
> 
> 
> Systeem: FreeBSD 11.0-STABLE  At revision 310725.

The fdatasync symbol was added to head in r304209, and that was MFC'd to
stable/11 in r304980, almost 4 months ago.  For some reason, you don't
seem to have it in libc.a.

Can you link any application statically?  And if you use -lpthread?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)

[Dimitry Andric]

On 16 Dec 2016, at 23:56, Warner Losh <i...@bsdimp.com> wrote:
> 
> On Fri, Dec 16, 2016 at 11:00 AM, Dimitry Andric <d...@freebsd.org> wrote:
...
>> Yes, this is almost exactly what I have done on a machine that was
>> originally installed with gptzfsboot on the first partition, which was
>> 512K.  Since all the partitions on this SSD were aligned to 1M, I
>> reduced the size of the first partition to 224K, freeing up a hole of
>> exactly 800K for an EFI partition:
...
> You likely want to carve out more like 50MB instead of 800k for UEFI
> partition. 800k is the minimum, but it also precludes many things you
> may need to do with UEFI applications down the line.

Well, this is the default boot1.efifat size.  If you think 50MB is more
reasonable, the boot1.efifat size should have a corresponding size.

That said, as long as there are almost no such UEFI applications, I'm
not bothering.  Besides, even if there were, I don't have any interest
in the UEFI "ecosphere" as-is.  I see it as an ugly-but-necessary
pre-bootloader environment only.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Upgrading boot from GPT(BIOS) to GPT(UEFI)

[Dimitry Andric]

On 16 Dec 2016, at 18:53, Antony Uspensky  wrote:
> 
> On Fri, 16 Dec 2016, Eric van Gyzen wrote:
>> On 12/16/2016 11:39, Slawa Olhovchenkov wrote:
>>> On Fri, Dec 16, 2016 at 06:08:34PM +0100, Fernando Herrero Carr?n wrote:
 Hi everyone,
 
 A few months ago I got myself a new box and I have been happily running
 FreeBSD on it ever since. I noticed that the boot was not as fast as I had
 expected and I've realized that, while my disk is GPT partitioned, the boot
 process is still BIOS based:
 
 % gpart show
 =>   34  976773101  ada0  GPT  (466G)
 34  6- free -  (3.0K)
 40   1024 1  freebsd-boot  (512K)
   1064984- free -  (492K)
   2048   67108864 2  freebsd-swap  (32G)
   67110912  909662208 3  freebsd-zfs  (434G)
  976773120 15- free -  (7.5K)
...
> I would shrink ada0p1 down to 128K (size of gptzfsboot = 88K now) and place 
> efi partition (~800K) on free space between new p1 and p2. No need to touch 
> swap partition.

Yes, this is almost exactly what I have done on a machine that was
originally installed with gptzfsboot on the first partition, which was
512K.  Since all the partitions on this SSD were aligned to 1M, I
reduced the size of the first partition to 224K, freeing up a hole of
exactly 800K for an EFI partition:

=>   40  976773088  ada0  GPT  (466G)
 40   2008- free -  (1.0M)
   2048448 1  freebsd-boot  (224K)
   2496   1600 4  efi  (800K)
   4096   33554432 2  freebsd-swap  (16G)
   33558528  943214592 3  freebsd-zfs  (450G)
  976773120  8- free -  (4.0K)

Then I wrote the preformatted boot1.efifat image to it, using: gpart
bootcode -p /boot/boot1.efifat -i 4 ada0.  You can also use dd of
course, but I prefer using gpart for these kinds of manipulations.

This way, you can choose between booting in old school BIOS mode, or
UEFI mode.  If the UEFI mode works flawlessly, you can always decide
later to dump the freebsd-boot partition, and use only an EFI partition.

-Dimitry

P.S.: The only thing that triggers my OCD here is that the EFI partition
has index 4, but is physically the second.  But I can live with that,
until I finally delete the freebsd-boot partition. :)



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: broken source upgrade 9.3-STABLE to 10.3-STABLE

[Dimitry Andric]

On 14 Dec 2016, at 10:14, Eugene Grosbein  wrote:
> 
> On 14.12.2016 16:07, Kurt Jaeger wrote:
>> Hi!
>> 
>>> I've got legacy FreeBSD server running 8.4-STABLE and I'm trying to upgrade 
>>> it.
>>> Source upgrade for 8.4 to 9.3-STABLE r310015 went flawlessly.
>>> After reboot, I checked out stable/10 r310043 sources and ran buildworld 
>>> again.
>>> It fails:
>> 
>> I suggest two different approaches (have not tried that, but...)
>> 
>> 1) sidegrade (with build-from-source) to 9.3-RELEASE, then use
>>   freebsd-update to 10.x
>> 
>> 2) don't upgrade to 10-STABLE, but surce-upgrade to 10.0 or 10.1-RELEASE
>> 
> 
> I've manually applied single-line change r309860 to stable/10 tree
> and that fixed the problem, now build continues.

Hi Eugene,

This was a mistake on my part, sorry about that.  Obviously, the version
of clang in 10.x should support compiling with gcc 4.2.1, since that is
the easiest way of upgrading from previous releases.  I applied the same
fix to stable/10 in r310082.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CVE-2016-7434 NTP

[Dimitry Andric]

On 13 Dec 2016, at 03:18, Michelle Sullivan <miche...@sorbs.net> wrote:
> 
> Dimitry Andric wrote:
>> On 08 Dec 2016, at 06:08, Michelle Sullivan <miche...@sorbs.net> wrote:
>>> Are we going to get a patch for CVE-2016-7434 on FreeBSD 9.3?
>> On Nov 22, in r309009, Xin Li merged ntp 4.2.8p9, which fixes this
>> issue, to stable/9:
>> 
>> https://svnweb.freebsd.org/changeset/base/309009
>> 
>> Unfortunately the commit message did not mention the CVE identifier.  I
>> can't find any corresponding security advisory either.
...
> No updates needed to update system to 9.3-RELEASE-p52.
> No updates are available to install.
> Run '/usr/sbin/freebsd-update fetch' first.
> [root@gauntlet /]# ntpd --version
> ntpd 4.2.8p8-a (1)
> 
> So no then...
> 
> 9.3 is still so-say supported so I'm not talking about -STABLE.

Well, as I mentioned, there was no Security Advisory (which is a little
strange), so I didn't expect there to be any binary updates.  As far as
I know, binary updates are only built for Security Advisories and Errata
Notices.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CVE-2016-7434 NTP

[Dimitry Andric]

On 08 Dec 2016, at 06:08, Michelle Sullivan  wrote:
> 
> Are we going to get a patch for CVE-2016-7434 on FreeBSD 9.3?

On Nov 22, in r309009, Xin Li merged ntp 4.2.8p9, which fixes this
issue, to stable/9:

https://svnweb.freebsd.org/changeset/base/309009

Unfortunately the commit message did not mention the CVE identifier.  I
can't find any corresponding security advisory either.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: boot1.efifat's FAT12 volume label prevents booting (some systems)

[Dimitry Andric]

On 06 Nov 2016, at 16:07, Harry Schmalzbauer  wrote:
> 
> Recently I played with bsdinstall and UEFI setup, which left the system
> unbootable (11.0-Release).
> The culprit is the MS-DOS volume lable "EFI" of the EFI partition.
> At least on Intel Single-Socket Servers (for Xeon E3 IvyBridge/BearToot
> + Haswell/RainbowPass), the UEFI firmware can't handle the identical
> path/volumelabel.

That is pretty weird.  I wasn't aware that any firmware even used this
label for anything?  Maybe they mount it under a directory named after
the label, or something.


> Simply reformatting with a different volume label (EFIFAT e.g.) solves
> that problem!
> Shall I file a bug report?

Please do, so it is not forgotten.  It is relatively easy to change the
volume label, by editing sys/boot/efi/boot1/generate-fat.sh, and then
regenerating the FAT templates.


> Btw, can someone explain in short words why BOOT64.EFI seems to be
> boot1.efi, but padded with 0x20 up to 128k?

At buildworld time, pre-populated FAT file system templates are used,
instead of playing games with mounting ramdisks and creating file
systems in them.  The build process just inserts the contents of
boot1.efi into a fixed location into the existing FAT template.

And the template is pre-propulated with a 128kiB bootx64.efi file.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Building FreeBSD 11.0-stable on FreeBSD 10.1-stable fails

[Dimitry Andric]

On 16 Oct 2016, at 17:22, Warner Losh <i...@bsdimp.com> wrote:
> 
> On Sun, Oct 16, 2016 at 5:34 AM, Dimitry Andric <d...@freebsd.org> wrote:
>> On 16 Oct 2016, at 12:20, Torfinn Ingolfsen <torfinn.ingolf...@getmail.no> 
>> wrote:
>>> I am trying to build FreeBSD 11.0-stable on a machine which runs:
>>> tingo@kg-v7$ uname -a
>>> FreeBSD kg-v7.kg4.no 10.1-STABLE FreeBSD 10.1-STABLE #0 r278322: Fri Feb  6 
>>> 21:36:01 CET 2015
>>> r...@kg-v7.kg4.no:/usr/obj/usr/src/sys/GENERIC  amd64
>>> 
>>> I have emptied /usr/src and /usr/obj and fetched the latest stable/11 via 
>>> subversion:
>>> tingo@kg-v7$ egrep "^BRANCH|^REVISION" /usr/src/sys/conf/newvers.sh
>>> REVISION="11.0"
>>> BRANCH="STABLE"
>>> 
>>> But building it (per the procedure in the handbook) fails at the buildworld 
>>> stage. Both 'make -j5 buildworld' and 'make buildworld' fails, like this:
>>> 
>>> c++: error: unable to execute command: Segmentation fault (core dumped)
...
>> Please make sure your stable/10 is at least r286033.
> 
> What's the issue this fixes?

It fixes a possible crash in clang 3.4, which can occur if newer
versions of llvm are compiled.  Unfortunately this fix only went in
after 10.3-RELEASE.


> Right now we have safeties in place in
> buildworld that indicate we 'support' back to 9 sometime. If that's
> not really the case, we need to fix something (either fix so we don't
> need this specific revision, or fix the Makefile to indicate we don't
> support back that far).

The fix was also merged to stable/9 in r286035.  As far as I know, we
have always required people to upgrade to the latest revision in stable
branches before attempting to hop to the next stable branch (or head).

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Building FreeBSD 11.0-stable on FreeBSD 10.1-stable fails

[Dimitry Andric]

On 16 Oct 2016, at 12:20, Torfinn Ingolfsen  
wrote:
> I am trying to build FreeBSD 11.0-stable on a machine which runs:
> tingo@kg-v7$ uname -a
> FreeBSD kg-v7.kg4.no 10.1-STABLE FreeBSD 10.1-STABLE #0 r278322: Fri Feb  6 
> 21:36:01 CET 2015
> r...@kg-v7.kg4.no:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> I have emptied /usr/src and /usr/obj and fetched the latest stable/11 via 
> subversion:
> tingo@kg-v7$ egrep "^BRANCH|^REVISION" /usr/src/sys/conf/newvers.sh
> REVISION="11.0"
> BRANCH="STABLE"
> 
> But building it (per the procedure in the handbook) fails at the buildworld 
> stage. Both 'make -j5 buildworld' and 'make buildworld' fails, like this:
> 
> c++: error: unable to execute command: Segmentation fault (core dumped)
> c++: error: clang frontend command failed due to signal (use -v to see 
> invocation)
> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
> Target: x86_64-unknown-freebsd10.1
> Thread model: posix
> c++: note: diagnostic msg: PLEASE submit a bug report to 
> https://bugs.freebsd.org/submit/ and include the crash backtrace, 
> preprocessed source, and associated run script.
> c++: note: diagnostic msg:
> 
> 
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> c++: note: diagnostic msg: /tmp/CGBlocks-abcdc1.cpp
> c++: note: diagnostic msg: /tmp/CGBlocks-abcdc1.sh

Please make sure your stable/10 is at least r286033.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: buildkernel fails with a 'invalid conversion specifier' compiler error

[Dimitry Andric]

On 18 Sep 2016, at 20:37, Alex T.  wrote:
> 
> I'm on stable/10 branch and have been using it to rebuild world
> and kernel. This is the revision I'm currently trying to build but
> started seeing the following issue way before it.
> 
> URL: svn://svn.freebsd.org/base/stable/10
> Revision: 305760
> 
> The world builds fine, but building the kernel fails with this error:
> 
> /usr/src/sys/cam/cam_xpt.c:1060:27: error:
>  invalid conversion specifier 'b'
>  [-Werror,-Wformat-invalid-specifier]
>  ...printf("%s%d: quirks=0x%b\n", perip...
>~^
> /usr/src/sys/cam/cam_xpt.c:1061:36: error:
>  data argument not used by format
>  string [-Werror,-Wformat-extra-args]
>  ...periph->unit_number, quirks, bit_st...
> 
> This is how my /etc/make.conf looks like:
> WITH_PKGNG=yes
> SSP_CFLAGS=-fstack-protector-all
> WITH_SSP_PORTS=yes
> WITHOUT="DOCS"
> 
> and I don't have /etc/src.conf. Has anyone seen this issue?
> 
> Any idea what might me misconfigured missing here?

It's hard to say what is different on your system, but it looks like the
-fformat-extensions flag is somehow not being used for building your
kernel.  If you can't figure out what causes this, you can try to work
around it by setting WITHOUT_FORMAT_EXTENSIONS, or setting WERROR to
empty.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Benchmarks results for FreeBSD 11

[Dimitry Andric]

On 28 Aug 2016, at 02:10, K. Macy  wrote:
> 
>> The problem here is that Phoronix took a Beta version of FreeBSD 11.
>> Beta versions have a lot of debugging (malloc, invariants, witness)
>> options enabled which make it significantly slower than release
>> versions. This is even obviously when you run a Beta as a desktop. It
>> just feels much slower.
> 
> 
> I don't know what was going on in these particular tests, but in a
> more recent benchmarking run
> -https://www.phoronix.com/scan.php?page=article=freebsd11-clang-gcc=1
> - you're seeing the result of openmp being disabled in base. The clang
> maintainer for src refuses to include libomp as required for -fopenmp
> because nothing in base requires it.

Come on, this is nonsense.  I have indicated earlier that I would have
liked to import openmp into base, but this was shot down precisely for
that reason: nothing in base uses it.

So for now, the solution is simply: install one of the llvm ports, and
use it.  These have configuration setting to install every optional
component from the LLVM project.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Problems while reading from /dev/cd0

[Dimitry Andric]

On 23 Aug 2016, at 08:50, Gerhard Schmidt  wrote:
> 
> I'm having some very curios Problems while reading from an BD-R recorded
> as a tar directly on the disk without a filesystem.
> 
> When i try to read the Disk via 'tar tvvf /dev/cd0'
> 
> i get the following output
> 
> -rw-r--r--  0 root   wheel 5793264611  1 Jan  2015 file1.db
> tar: Error reading '/dev/cd0'
> Archive Format: POSIX ustar format,  Compression: none
> tar: Error exit delayed from previous errors.
> 
> reading the whole file via 'dd if=/dev/cd0 of=backup.tar bs=2048' and
> than 'tar tvvf backup.tar' the file is read without a hitch. So the data
> on the disk is OK but can't be read directly by tar.
> 
> if i try the dd without the bs=2048 i get
> 
> dd: /dev/cd0: Invalid argument
> 0+0 records in
> 0+0 records out
> 0 bytes transferred in 0.000115 secs (0 bytes/sec)
> 
> So there is a problem reading anything other than 2048 byte blocks from
> a Disk.

Have you tried tar's -b option, to set the block size 2048?  Maybe that
will help.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: new certificate for svn.freebsd.org?

[Dimitry Andric]

On 17 Jun 2016, at 01:21, Wolfgang Zenker  wrote:
> 
> I'm getting presented a new SSL certificate for svn.freebsd.org.
> Like the previous one, it can not be verified by svnlite on any
> of my 10-STABLE machines, though ca_root_nss is installed. But
> the previous certificate at least matched the fingerprint given
> on https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/svn.html
> 
> Trying to update:
> # svnlite up /usr/src
> Updating '/usr/src':
> Error validating server certificate for 'https://svn.freebsd.org:443':
> - The certificate is not issued by a trusted authority. Use the
>   fingerprint to validate the certificate manually!
> Certificate information:
> - Hostname: svn.freebsd.org
> - Valid: from Jun 15 00:00:00 2016 GMT until Jun 29 23:59:59 2017 GMT
> - Issuer: Gandi Standard SSL CA 2, Gandi, Paris, Paris, FR
> - Fingerprint: 86:5C:C5:84:F5:2D:40:FA:C6:F9:F0:D9:F5:40:D0:D5:6B:90:CB:CE

The fingerprint looks good.


> (R)eject, accept (t)emporarily or accept (p)ermanently?
> 
> Is it just me?

No, probably everybody who doesn't have ca_root_nss installed. Make sure
you have that package installed, and a symlink /etc/ssl/cert.pem
pointing to /usr/local/share/certs/ca-root-nss.crt.

Alternatively, manually append the following certificate (CN=AddTrust
External CA Root) to /etc/ssl/cert.pem:

-BEGIN CERTIFICATE-
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
-END CERTIFICATE-

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [FreeBSD-Stable] svn commit: r296462 - in stable/9: crypto/openssl/crypto/bio crypto/openssl/crypto/bn crypto/openssl/doc/apps crypto/openssl/ssl secure/usr.bin/openssl/man

[Dimitry Andric]

On 09 Mar 2016, at 16:48, Eric Masson  wrote:
> 
> Mike Tancsa  writes:
> 
> Hi,
> 
>> good trace - pre openssl commit
>> 
>> debug2: kex_parse_kexinit:
>> hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,umac...@openssh.com [preauth]
>> debug2: kex_parse_kexinit:
>> hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,umac...@openssh.com [preauth]
>> debug2: kex_parse_kexinit: none [preauth]
>> debug2: kex_parse_kexinit: none [preauth]
>> debug2: kex_parse_kexinit:  [preauth]
>> debug2: kex_parse_kexinit:  [preauth]
>> debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
>> debug2: kex_parse_kexinit: reserved 0  [preauth]
>> debug2: mac_setup: setup hmac-sha1 [preauth]
>> debug1: kex: client->server aes256-ctr hmac-sha1 none [preauth]
>> debug2: mac_setup: setup hmac-sha1 [preauth]
>> debug1: kex: server->client aes256-ctr hmac-sha1 none [preauth]
>> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
>> debug3: mm_request_send entering: type 0 [preauth]
>> debug3: mm_request_receive entering
>> debug3: monitor_read: checking request 0
>> debug3: mm_answer_moduli: got parameters: 1024 2048 2048
>> bad trace - with openssl commit.
>> 
>> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
>> debug3: mm_request_send entering: type 0 [preauth]
>> debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth]
>> debug3: mm_request_receive_expect entering: type 1 [preauth]
>> debug3: mm_request_receive entering [preauth]
>> debug3: mm_request_receive entering
>> debug3: monitor_read: checking request 0
>> debug3: mm_answer_moduli: got parameters: 1024 2048 2048
>> debug3: mm_request_send entering: type 1
>> debug2: monitor_read: 0 used once, disabling now
>> debug3: mm_choose_dh: remaining 0 [preauth]
>> *debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]*
>> debug1: monitor_read_log: child log fd closed
>> debug3: mm_request_receive entering
>> debug1: do_cleanup
>> debug3: PAM: sshpam_thread_cleanup entering
>> debug1: Killing privsep child 1837
> 
> Similar symptoms on 9.3-p37 when trying to connect with putty from a Win
> 7 station.
> 
> Using cygwin's openssh client doesn't trigger the issue.

Can you please try the attached patch, which I also attached to PR
207783?  I think this will solve the crashes.

It should be enough to rebuild secure/lib/libcrypto, and install it.

-Dimitry


fix-pr207783-1.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Newer clang than comes with install?

[Dimitry Andric]

On 04 Mar 2016, at 15:53, Kevin P. Neal  wrote:
> 
> On Fri, Mar 04, 2016 at 02:22:26PM +, Brooks Davis wrote:
>> On Thu, Mar 03, 2016 at 08:45:05AM -0500, kpn...@pobox.com wrote:
>>> I notice on 10.2 we're using "FreeBSD clang version 3.4.1". But there are
>>> bugs in this version of clang that I'm having trouble with.
>>> 
>>> Is compiling a newer (say, 3.7.1) version of clang to target FreeBSD
>>> supported? I have no desire to replace any of the libraries, just the
>>> compiler itself. Is that supposed to work _without_ going through the
>>> ports/pkgs system?
>>> 
>>> IOW, can I just download from llvm.org the clang+llvm source, compile
>>> it on FreeBSD, and then use it safely?
>> 
>> It should.  The ports don't include many patches.
> 
> Yeah, I was just looking at the patches we do include. One of them it looks
> like causes some of the llvm.org-provided includes to not be installed.
> 
> I'm not sure I can, well, not install them because I also need to use the
> same install to do cross compiles. A quick check shows that those includes
> are used when targetting cross and native.
> 
> Am I correct about the include files?

I am not entirely sure what you mean, but if you mean that we don't
install a number of internal clang headers which conflict with FreeBSD
system headers, then yes.


> And, if so, are there plans to
> upstream patches so the llvm.org includes will work out of the box for
> FreeBSD-hosted-and-targetted compiles?

It is on my TODO list, but not very much near the top.  The first thing
is to get the 3.8.0 release imported now.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Newer clang than comes with install?

[Dimitry Andric]

On 03 Mar 2016, at 14:45, kpn...@pobox.com wrote:
> 
> I notice on 10.2 we're using "FreeBSD clang version 3.4.1". But there are
> bugs in this version of clang that I'm having trouble with.

Which specific bugs are those?


> Is compiling a newer (say, 3.7.1) version of clang to target FreeBSD
> supported? I have no desire to replace any of the libraries, just the
> compiler itself. Is that supposed to work _without_ going through the
> ports/pkgs system?
> 
> IOW, can I just download from llvm.org the clang+llvm source, compile
> it on FreeBSD, and then use it safely?

Sure.  You can also download pre-compiled versions from llvm.org, if you
want.  Though if you can settle for a pre-compiled version, installing
it through pkg(1) is probably much easier.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: STABLE clang planned update MFC path (3.4.1 STABLE, 3.7.0, CURRENT)

[Dimitry Andric]

On 11 Oct 2015, at 14:05, Piotr Kubaj  wrote:
> 
> AFAIK if there had been such plans, they were dropped long ago. The
> reasoning it can't be done (at least for now) is that versions 3.5.0+
> require C++11-capable stack and that would break upgrades from 9-STABLE
> (if the user still uses GCC, as is by default). So, LLVM in stable/10
> will probably be upgraded when stable/9 goes EOL.

If stable/10 had clang 3.5 or higher, you could still upgrade from
stable/9.  It would only require you to do the upgrade in two steps:

* Rebuild and reinstall your stable/9 world using WITH_CLANG,
  WITH_CLANG_IS_CC, and WITH_LIBCPLUSPLUS.  This will install clang
  3.4.1 and libc++, and make clang the default compiler.
* Checkout stable/10 (or even head), and build/install it in the regular
  fashion.

I am personally not against merging newer llvm/clang versions into
stable/10.  But the "silent agreement" has always been that you could
upgrade easily from the latest stable/X to stable/X+1, and the above
two-step process breaks that, or at least makes it more complicated.

Last but not least, note that this would only apply to the architectures
that *can* actually build clang 3.4.1 and libc++ on stable/9.  This is
currently limited to x86, little-endian arm and powerpc (64 bit, I'm
unsure about 32 bit).

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Strange USB behavior

[Dimitry Andric]

On 23 Apr 2015, at 01:54, fate fat...@gmail.com wrote:
 Strange USB behavior on Gigabyte BRIX GB-BXA8-5545.
 Need number of connect - disconnect cycles before usb subsystem
 recognize devices.
 
 Apr 19 02:09:01 brix kernel: ugen0.2: vendor 0x0409 at usbus0 (disconnected)
 Apr 19 02:09:05 brix kernel: usb_alloc_device: Failure selecting
 configuration index 0:USB_ERR_TIMEOUT, port 4, addr 1 (ignored)
 Apr 19 02:09:05 brix kernel: ugen0.2: vendor 0x0409 at usbus0
 Apr 19 02:09:07 brix kernel: ugen0.2: vendor 0x0409 at usbus0 (disconnected)
 Apr 19 02:18:15 brix kernel: usb_alloc_device: Failure selecting
 configuration index 0:USB_ERR_TIMEOUT, port 4, addr 1 (ignored)
 Apr 19 02:18:15 brix kernel: ugen0.2: vendor 0x0409 at usbus0
 Apr 19 02:18:17 brix kernel: ugen0.2: vendor 0x0409 at usbus0 (disconnected)
 Apr 19 02:18:21 brix kernel: usb_alloc_device: Failure selecting
 configuration index 0:USB_ERR_TIMEOUT, port 4, addr 1 (ignored)
 Apr 19 02:18:21 brix kernel: ugen0.2: vendor 0x0409 at usbus0
 Apr 19 02:18:23 brix kernel: ugen0.2: vendor 0x0409 at usbus0 (disconnected)
 Apr 19 02:18:27 brix kernel: usb_alloc_device: Failure selecting
 configuration index 0:USB_ERR_TIMEOUT, port 4, addr 1 (ignored)
 Apr 19 02:18:27 brix kernel: ugen0.2: vendor 0x0409 at usbus0
 Apr 19 02:18:29 brix kernel: ugen0.2: vendor 0x0409 at usbus0 (disconnected)
 Apr 19 02:18:36 brix kernel: usb_alloc_device: Failure selecting
 configuration index 0:USB_ERR_TIMEOUT, port 4, addr 1 (ignored)
 Apr 19 02:18:36 brix kernel: ugen0.2: vendor 0x0409 at usbus0
 Apr 19 02:18:40 brix kernel: ugen0.2: vendor 0x0409 at usbus0 (disconnected)
 Apr 19 03:17:14 brix kernel: ugen0.2: vendor 0x0409 at usbus0
 Apr 19 03:17:15 brix kernel: uhub7: vendor 0x0409 product 0x005a,
 class 9/0, rev 2.00/1.00, addr 1 on usbus0
 Apr 19 03:17:15 brix kernel: uhub7: 4 ports with 4 removable, self powered
 Apr 19 03:17:17 brix kernel: ugen0.3: NEC at usbus0
 Apr 19 03:17:18 brix kernel: ugen0.4: Logitech at usbus0
 Apr 19 03:17:18 brix kernel: uhid0: Logitech USB Receiver, class 0/0,
 rev 2.00/5.00, addr 3 on usbus0
 Apr 19 03:17:19 brix kernel: ugen0.5: Logitech at usbus0
 Apr 19 03:17:19 brix kernel: ukbd0: Logitech Logitech Illuminated
 Keyboard, class 0/0, rev 2.00/55.01, addr 4 on usbus0
 Apr 19 03:17:19 brix kernel: kbd1 at ukbd0
 Apr 19 03:17:19 brix kernel: uhid1: Logitech Logitech Illuminated
 Keyboard, class 0/0, rev 2.00/55.01, addr 4 on usbus0
 Apr 19 03:17:20 brix kernel: ugen0.6: C-Media Electronics Inc. at usbus0
 Apr 19 03:17:20 brix root: Unknown USB device: vendor 0x06f8 product
 0x2101 bus uhub7
 Apr 19 03:17:20 brix kernel: uhid2: C-Media Electronics Inc. XPS
 SOUND BAR USB, class 0/0, rev 1.10/1.00, addr 5 on usbus0
 Apr 19 03:17:20 brix kernel: uhid3: NEC PA271W, class 0/0, rev
 1.10/0.01, addr 2 on usbus0
 Apr 19 03:17:20 brix kernel: ums0: Logitech USB Receiver, class 0/0,
 rev 2.00/5.00, addr 3 on usbus0
 Apr 19 03:17:20 brix kernel: ums0: 16 buttons and [XYZT] coordinates ID=0
 Apr 19 03:17:20 brix kernel: uaudio0: C-Media Electronics Inc. XPS
 SOUND BAR USB, class 0/0, rev 1.10/1.00, addr 5 on usbus0
 Apr 19 03:17:20 brix kernel: uaudio0: Play: 48000 Hz, 2 ch, 16-bit
 S-LE PCM format, 2x8ms buffer.
 Apr 19 03:17:20 brix kernel: uaudio0: Play: 44100 Hz, 2 ch, 16-bit
 S-LE PCM format, 2x8ms buffer.
 Apr 19 03:17:20 brix kernel: uaudio0: No recording.
 Apr 19 03:17:20 brix kernel: uaudio0: No MIDI sequencer.
 Apr 19 03:17:20 brix kernel: pcm1: USB audio on uaudio0
 Apr 19 03:17:20 brix kernel: uaudio0: HID volume keys found.
 Apr 19 03:18:32 brix kernel: ugen0.2: vendor 0x0409 at usbus0 (disconnected)
 Apr 19 03:18:32 brix kernel: uhub7: at uhub0, port 4, addr 1 (disconnected)

Is this a Haswell Brix?  I have something similar on my Haswell box, at boot 
time it goes:

Timecounter TSC-low frequency 1247142608 Hz quality 1000
Root mount waiting for: usbus1 usbus0
uhub0: 13 ports with 13 removable, self powered
Root mount waiting for: usbus1 usbus0
uhub1: 3 ports with 3 removable, self powered
Root mount waiting for: usbus1 usbus0
ugen1.2: vendor 0x8087 at usbus1
uhub2: vendor 0x8087 product 0x8000, class 9/0, rev 2.00/0.04, addr 2 on 
usbus1
uhub2: 8 ports with 8 removable, self powered
usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_TIMEOUT
Root mount waiting for: usbus0
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_TIMEOUT
Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed, 
USB_ERR_IOERROR
Root mount waiting for: usbus0
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at 

Re: Problem building world (amd64) this morning

[Dimitry Andric]

On 10 Apr 2015, at 21:32, Michael Grimm trash...@odo.in-berlin.de wrote:
 
 Dimitry Andric d...@freebsd.org wrote:
 
 On 10 Apr 2015, at 20:55, Michael Grimm trash...@odo.in-berlin.de wrote:
 
 I can confirm that. r281288 compiles without failing, r281289 fails.
 
 I've tried all possible ways of reproducing this problem, but it always
 works for me.  Can somebody who experiences the problem please do a
 clean build using script(1), and post the full build log somewhere?
 Preferably a make buildworld without -j, so commands are not
 interspersed.
 
 Compilation at r281289 is on its way. I'll send you a link after completion.

Thanks, but you can stop that compilation now. :)  I finally managed to
reproduce the problem, and it turns out I also had to MFC r272814 and
r272815, which I have done in r281382.  That should really fix it
properly... Sorry for the breakage.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Build failed in Jenkins: FreeBSD_stable_10 #1336

[Dimitry Andric]

On 06 Apr 2015, at 09:41, Craig Rodrigues rodr...@crodrigues.org wrote:
 
 On Sun, Apr 5, 2015 at 4:45 AM, Dimitry Andric d...@freebsd.org wrote:
 
 --- aslcompilerparse.c ---
 yacc: f - maximum table size exceeded
 *** [aslcompilerparse.c] Error code 2
 
 Strangely, this worked fine for me when making a universe on our
 reference stable/10 machine.  Is this particular Jenkins slave still at
 FreeBSD 10.1-RELEASE?
 
 
 Yes, that's right.

I've committed a fix in r281110.  This ensures a fresh copy of yacc is
built during bootstrap-tools.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Build failed in Jenkins: FreeBSD_stable_10 #1336

[Dimitry Andric]

On 05 Apr 2015, at 11:51, jenkins-ad...@freebsd.org wrote:
 
 See https://jenkins.freebsd.org/job/FreeBSD_stable_10/1336/changes
...
 --- aslcompilerparse.c ---
 yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y
 yacc: 89 shift/reduce conflicts.
 --- sbin.depend__D ---
 --- depend_subdir_nvmecontrol ---
 echo nvmecontrol: 
 https://jenkins.freebsd.org/job/FreeBSD_stable_10/ws/obj/builds/FreeBSD_stable_10/tmp/usr/lib/libc.a
.depend
 --- usr.sbin.depend__D ---
 --- dtparser.y.h ---
 ln -f dtparserparse.h dtparser.y.h
 --- depend_subdir_amd ---
 === usr.sbin/amd (depend)
 --- depend_subdir_acpi ---
 --- aslcompilerparse.c ---
 yacc: f - maximum table size exceeded
 *** [aslcompilerparse.c] Error code 2

Strangely, this worked fine for me when making a universe on our
reference stable/10 machine.  Is this particular Jenkins slave still at
FreeBSD 10.1-RELEASE?

I suspect that it is missing r277086, which increases yacc's MAXTABLE.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Will ASAN MFC to 10-STABLE?

[Dimitry Andric]

On 04 Apr 2015, at 23:30, Kevin Bowling kevin.bowl...@kev009.com wrote:
 
 I believe the last bits needed to try clang's ASAN feature is the clang-rt 
 stuff.  Will this MFC with a clang 3.5 or 3.6 MFC?

It depends on whether we will ever MFC the most recent version of clang
to stable/10.  Since clang 3.5.0 and later require C++11 support, doing
this will make it more difficult to upgrade from 9.x to 10.x, and not
everybody agrees that it is worth the trouble.

Once 9.x is EOL (expected at the end 2016), it might cease to be an
issue, though. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Will ASAN MFC to 10-STABLE?

[Dimitry Andric]

On 05 Apr 2015, at 00:19, Kevin Bowling kevin.bowl...@kev009.com wrote:
 
 On 4/4/2015 3:11 PM, Dimitry Andric wrote:
 On 04 Apr 2015, at 23:30, Kevin Bowling kevin.bowl...@kev009.com wrote:
 
 I believe the last bits needed to try clang's ASAN feature is the clang-rt 
 stuff.  Will this MFC with a clang 3.5 or 3.6 MFC?
 
 It depends on whether we will ever MFC the most recent version of clang
 to stable/10.  Since clang 3.5.0 and later require C++11 support, doing
 this will make it more difficult to upgrade from 9.x to 10.x, and not
 everybody agrees that it is worth the trouble.
 
 Once 9.x is EOL (expected at the end 2016), it might cease to be an
 issue, though. :-)
 
 -Dimitry
 
 Do you know if the clang-rt stuff will function with clang 3.4 or were there 
 changes in the compiler to accommodate FreeBSD?

The sanitizer libraries are part of compiler-rt, and the version which
is compatible with clang 3.4 does not yet have full FreeBSD support.  I
don't think it is feasible to backport newer versions of these to
accommodate an older clang version.


 Wondering if we could try and add just the clang-rt libraries since the end 
 of 2016 is a long time away :)

No, that is not easily done.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Trying to clone a ZFS drive, can't get ashift=12

[Dimitry Andric]

On 01 Apr 2015, at 06:30, Daniel Eischen deisc...@freebsd.org wrote:
 
 I have an Oracle (nee Sun) X4-2 server with identical 300GB SAS
 drives.  I did an MBR ZFS install from FreeBSD 10.1-RELEASE CD
 and have it updated to p6:
...
  # zpool create -o cachefile=/tmp/newpool.cache bootpoolNew label/boot0
  # zdb -U /tmp/newpool.cache | grep ashift
  ashift: 9
 
 What gives?  How do I get it to use 4k?

sysctl vfs.zfs.min_auto_ashift=12

And also put that in your /etc/sysctl.conf.  I don't know why it isn't
the default yet... :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: nc (netcat) in 10.1 breaks after upgrade from 9.3

[Dimitry Andric]

On 29 Mar 2015, at 22:53, Miroslav Lachman 000.f...@quip.cz wrote:
 
 nc (netcat) in 10.1 behaves differently than it was before upgrade and breaks 
 our scripts for monitoring services.
 
 For example, following command works in FreeBSD 8.4 and 9.3
 
 echo stats | nc localhost 11211
 
 But it hangs in 10.1 at the END and never finishes.
 
 It must be changed to:
 
 echo stats | nc -N localhost 11211
 
 Is it intentional?

Yes, this was introduced by upstream:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/nc/netcat.c#rev1.111

Don't shutdown nc(1)'s network socket when stdin closes. Matches *Hobbit*'s
original netcat and GNU netcat; revert to old behaviour with the new -N flag
if needed.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: runtime linker on 9.x/i386: clang vs. gcc

[Dimitry Andric]

On Oct 14, 2013, at 18:22, Mikhail T. mi+t...@aldan.algebra.com wrote:
 I'm seeing a strange problem with clang-compiled binaries on 9.x/i386 system. 
 Here it is: if a shared library A needs a symbol provided by a shared library 
 B, libA will fail to load into a process even if the executable is linked 
 with libB. The only fix (work-around?) is to relink libA to explicitly depend 
 on libB. A temporary work-around is to use LD_PRELOAD to list all of the 
 necessary libBs...
 
 One example of this is reported in ports/180473 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/180473 -- the 
 libprldap6.so refuses to load because of the symbols it needs from 
 libnspr4.so. For some reason, the fact, that -lnspr4 is linked into the 
 executable (seamonkey or thunderbird), is not sufficient... As the ticket 
 suggests, using gcc46 (Mozilla rejects gcc-4.2.x nowadays) instead of clang 
 solves the problem (though an even better solution is in place since this 
 weekend).
 
 Another example is xorg-server, which, for me, can not load some of the 
 drivers because they complain of missing symbols:
 
   (EE) Failed to load /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: 
 /opt/lib/xorg/modules/drivers/vboxvideo_drv.so: Undefined symbol 
 DRIFinishScreenInit
 
 The DRIFinishScreenInit is provided by libdri.so, which the server also 
 loads... But, somehow, that is not sufficient. Rebuilding vboxvideo_drv.so 
 (provided by emulators/virtualbox-ose-additions 
 http://www.freshports.org/emulators/virtualbox-ose-additions) with the 
 stock cc (gcc-4.2.1) resolves the linking problem -- even if Xorg executable 
 and the libdri.so remain clang-compiled.
 
 I am not prepared to argue, whether that's a right or wrong behavior -- 
 but it certainly is inconsistent, because it is only manifested on i386 and 
 only when the compiler is clang.
 
 Any thoughts?


There are many possibilities here, and you might be running into
multiple different problems, but the X.org failures look familiar to me.

There is a problem when clang does tail-call optimization on i386 with
PIC in effect, and it emits GOT relocations for the tail-called
functions, instead of PLT relocations.  In some scenarios, such as with
the way X.org does lazy dynamic linking, this can cause problems.  See
also http://llvm.org/PR15086 (which I unfortunately did not get much
response on).

For now, a workaround is to recompile the affected .so files with
-fno-optimize-sibling-calls (if you are optimizing).  This is also the
approach taken for the X.org ports, see
http://svnweb.freebsd.org/ports?view=revisionrevision=312583 for the
diff.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: runtime linker on 9.x/i386: clang vs. gcc

[Dimitry Andric]

On Oct 14, 2013, at 22:42, Mikhail T. mi+t...@aldan.algebra.com wrote:
 10/14/13 4:31 PM, Dimitry Andric написав(ла):
 There is a problem when clang does tail-call optimization on i386 with
 PIC in effect, and it emits GOT relocations for the tail-called
 functions, instead of PLT relocations.  In some scenarios, such as with
 the way X.org does lazy dynamic linking, this can cause problems.  See
 also 
 http://llvm.org/PR15086
  (which I unfortunately did not get much
 response on).
 
 Ouch... That seems like a show-stopper for clang-adoption... At least, on 
 i386.

Well, the scenario is very difficult to reproduce, at least when I tried
it.  You must have a very specific way of dynamically loading objects,
and you must load them in the wrong order, or the problem will not
occur.  Normally linked .so's do not have this problem at all.  So
hardly a showstopper, 10.0 is being released with clang as we speak. :-)


 For now, a workaround is to recompile the affected .so files with
 -fno-optimize-sibling-calls (if you are optimizing).
 
 Maybe, our clang (both src/ and ports/) should be compiled with that being in 
 effect by default on i386?

For the specific cases where it occurs (as far as I knew until know,
only certain X.org drivers) it might be enough to just use
-fno-optimize-sibling-calls.  If this problem occurs more often, I will
see if I can make it the default for i386-with-PIC.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Trouble building/upgrading 9-stable

[Dimitry Andric]

On Oct 9, 2013, at 01:39, Johannes Totz johan...@jo-t.de wrote:
 I'm having trouble upgrading a system running 9-stable to a new revision. 
 buildworld always dies with an internal compiler error during 
 lib/clang/libllvminstcombine.
...
 /usr/src/lib/clang/libllvminstcombine/../../../contrib/llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp:1649:
  internal compiler error: in memory_address_length, at 
 config/i386/i386.c:13897

Since the tinderboxes for stable/9 are green, it is most likely your machine 
has a hardware problem.  You should at least run two or three full passes of 
memtest on your machine: this type of error typically occurs when data in RAM 
gets corrupted.

If you can't find any hardware problems, you could try to switch off building 
clang, using WITHOUT_CLANG in your src.conf.  However, if your hardware cannot 
be trusted, all bets are off... :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: devel/llvm33: failed to compile due to CLOCK_PROCESS_CPUTIME_ID issue

[Dimitry Andric]

On Sep 5, 2013, at 23:46, Oliver Pinter oliver.p...@gmail.com wrote:
 On 9/5/13, O. Hartmann o.hartm...@walstatt.org wrote:
 On a laptop, running FreeBSD 9.2-PRERELEASE #0 r255170: Tue Sep  3
 11:54:29 CEST 2013 amd64, compiling/updating port devel/llvm33 fails
 with the error shown below.
 
 The port is at llvm-3.3_2 and is supposed to be updated to
 llvm-3.3_4.
 
 On FreeBSD 10.0-CURRENT there is no problem compiling the port.
 
 [...]
 llvm[1]: Compiling Signals.cpp for Release build
 In file included from Process.cpp:85:
 /usr/ports/devel/llvm33/work/llvm-3.3.src/lib/Support/Unix/Process.inc:75:23:
 error: use of undeclared identifier 'CLOCK_PROCESS_CPUTIME_ID' if
 (::clock_gettime(CLOCK_PROCESS_CPUTIME_ID, TS) == 0) ^
 1 error generated.
 gmake[1]: ***
 [/usr/ports/devel/llvm33/work/llvm-3.3.src/lib/Support/Release/Process.o]
 Error 1 gmake[1]: *** Waiting for unfinished jobs gmake[1]: Leaving
 directory `/usr/ports/devel/llvm33/work/llvm-3.3.src/lib/Support'
 gmake: *** [all] Error 1
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/181817

This is because David Xu MFC'd his time.h changes to stable/9, but did not 
merge r245428, for some reason.  There was quite a large window where -current 
was broken in this respect.

I will merge the fix to stable/9 tonight, but I don't think it will make it 
into 9.2-RELEASE, so we will still need a workaround for the port, for the life 
of 9.2. :-(

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: devel/llvm33: failed to compile due to CLOCK_PROCESS_CPUTIME_ID issue

[Dimitry Andric]

On Sep 6, 2013, at 13:16, Dimitry Andric d...@freebsd.org wrote:
 On Sep 5, 2013, at 23:46, Oliver Pinter oliver.p...@gmail.com wrote:
 On 9/5/13, O. Hartmann o.hartm...@walstatt.org wrote:
 On a laptop, running FreeBSD 9.2-PRERELEASE #0 r255170: Tue Sep  3
 11:54:29 CEST 2013 amd64, compiling/updating port devel/llvm33 fails
 with the error shown below.
 
 The port is at llvm-3.3_2 and is supposed to be updated to
 llvm-3.3_4.
 
 On FreeBSD 10.0-CURRENT there is no problem compiling the port.
 
 [...]
 llvm[1]: Compiling Signals.cpp for Release build
 In file included from Process.cpp:85:
 /usr/ports/devel/llvm33/work/llvm-3.3.src/lib/Support/Unix/Process.inc:75:23:
 error: use of undeclared identifier 'CLOCK_PROCESS_CPUTIME_ID' if
 (::clock_gettime(CLOCK_PROCESS_CPUTIME_ID, TS) == 0) ^
 1 error generated.
 gmake[1]: ***
 [/usr/ports/devel/llvm33/work/llvm-3.3.src/lib/Support/Release/Process.o]
 Error 1 gmake[1]: *** Waiting for unfinished jobs gmake[1]: Leaving
 directory `/usr/ports/devel/llvm33/work/llvm-3.3.src/lib/Support'
 gmake: *** [all] Error 1
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/181817
 
 This is because David Xu MFC'd his time.h changes to stable/9, but did not 
 merge r245428, for some reason.  There was quite a large window where 
 -current was broken in this respect.
 
 I will merge the fix to stable/9 tonight, but I don't think it will make it 
 into 9.2-RELEASE, so we will still need a workaround for the port, for the 
 life of 9.2. :-(

Note: the workaround I've used in head is 
http://svnweb.freebsd.org/changeset/base/250616 .  This simply does 
-DCLOCK_PROCESS_CPUTIME_ID=15 on the command line of lib/Support/Process.cpp, 
which is ugly, but works fine, unless somebody changes the define again. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: devel/llvm33: failed to compile due to CLOCK_PROCESS_CPUTIME_ID issue

[Dimitry Andric]

On Sep 6, 2013, at 13:16, Dimitry Andric d...@freebsd.org wrote:
 On Sep 5, 2013, at 23:46, Oliver Pinter oliver.p...@gmail.com wrote:
 On 9/5/13, O. Hartmann o.hartm...@walstatt.org wrote:
...
 /usr/ports/devel/llvm33/work/llvm-3.3.src/lib/Support/Unix/Process.inc:75:23:
 error: use of undeclared identifier 'CLOCK_PROCESS_CPUTIME_ID'
...
 This is because David Xu MFC'd his time.h changes to stable/9, but did not 
 merge r245428, for some reason.  There was quite a large window where 
 -current was broken in this respect.
 
 I will merge the fix to stable/9 tonight, but I don't think it will make it 
 into 9.2-RELEASE, so we will still need a workaround for the port, for the 
 life of 9.2. :-(

Fortunately, re@ gave me permission to merge it into releng/9.2 (see r255308), 
so the change will make it into 9.2-RELEASE!

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Clang 3.3 libc++ problem on 9-STABLE

[Dimitry Andric]

On Jul 10, 2013, at 18:28, J David j.david.li...@gmail.com wrote:
 On Wed, Jul 10, 2013 at 5:53 AM, Dimitry Andric d...@freebsd.org wrote:
 
 I missed one additional patch, which I imported in r253042.
 
 
 Yes, I pulled that rev into my -STABLE and rebuilt and it is fine now.

I merged the patch to stable/9 in r253192.

-Dimitry

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

Re: strange stable/9 buildworld failure

[Dimitry Andric]

On Jul 11, 2013, at 19:19, Andriy Gapon a...@freebsd.org wrote:
 on 11/07/2013 19:43 Andriy Gapon said the following:
 
 buildword was run as make -j8 buildworld and the it mysteriously failed like 
 this:
 
 sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.80
 /usr/obj/usr/src/tmp/usr/lib
 sh /usr/src/tools/install.sh -l s liblwres.so.80
 /usr/obj/usr/src/tmp/usr/lib/liblwres.so
 1 error
 *** [libraries] Error code 2
 
 
 I could not find any actual error message in the build log.
 /usr/obj was cleaned out before the build.
 
 
 I was able to reproduce this exact failure 3 times in a row.
 Running buildworld without -j allowed the build to proceed further.
 Please note that my current userland is at (quite old) r248369, also stable/9.

Hi Andriy,

Can you please post the complete build log somewhere?  Maybe there is
something unexpected going wrong which does not show a clear error
message?

-Dimitry

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

Re: Clang 3.3 libc++ problem on 9-STABLE

[Dimitry Andric]

On 2013-07-10 00:50, J David wrote:

With SVN version r253119, we are seeing strange errors from iostream while
attempting to use the new clang 3.3 with libc++ on 9-STABLE.

...

/tmp/example-fet9b9.o: In function `std::__1::basic_ostreamchar,
std::__1::char_traitschar  std::__1::operator
std::__1::char_traitschar (std::__1::basic_ostreamchar,
std::__1::char_traitschar , char const*)':
example.cc:(.text._ZNSt3__1lsINS_11char_traitsIcRNS_13basic_ostreamIcT_EES6_PKc[_ZNSt3__1lsINS_11char_traitsIcRNS_13basic_ostreamIcT_EES6_PKc]+0x4b0):
undefined reference to `.LBB1_29'
clang++: error: linker command failed with exit code 1 (use -v to see
invocation)


Sorry, this was my mistake in importing the fixes needed for llvm PR
16038.  I missed one additional patch, which I imported in r253042.

I will merge it to stable/9 on July 11th.

-Dimitry

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

Re: make buildworld is now 50% slower

[Dimitry Andric]

[redirecting to the correct mailing list, freebsd-stable@ ...]

On Jul 5, 2013, at 10:53, Daniel Braniss da...@cs.huji.ac.il wrote:
 after today's update of 9.1-STABLE I noticed that make build[world|kernel] are
 taking conciderable more time, is it because the upgrade of clang?
 and if so, is the code produced any better?
 
 before:
 buildwordl:26m4.52s real 2h28m32.12s user 36m6.27s sys
 buildkernel:   7m29.42s real 23m22.22s user 4m26.26s sys
 
 today:
 buildwordl:   34m29.80s real 2h38m9.37s user 37m7.61s sys
 buildkernel:15m31.52s real 22m59.40s user 4m33.06s sys

Ehm, your user and sys times are not that much different at all, they
add up to about 5% slower for buildworld, and 1% faster for build kernel.
Are you sure nothing else is running on that machine, eating up CPU time
while you are building? :)

But yes, clang 3.3 is of course somewhat larger than 3.2.  You might
especially notice that, if you are using gcc, which is very slow at
compiling C++.

In any case, if you do not care about clang, just set WITHOUT_CLANG= in
your /etc/src.conf, and you can shave off some build time.

-Dimitry

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

Re: Phantom nulls in usbdevs.h during 9-STABLE kernel build

[Dimitry Andric]

On Jul 4, 2013, at 04:43, J David j.david.li...@gmail.com wrote:
 We are seeing strange problems building the kernel on 9-STABLE.  The
 problem is intermittent and will go away if we build enough times in a row
 without making any changes.
 
 
 The problem seems to be that the usbdevs.h file (which appears to be
 automatically generated) gets random NULL bytes in it.
...
 On the second failure posted below I took a hex dump of the usbdevs.h file.
 I don't see any NULLs at the target location, which is an empty line.
 (Just 0a 0a for the empty line.)  In fact there are no nulls anywhere in
 the file.

So the actual file does *not* have any NUL characters in it?  What
happens if you run e.g. sha1(1) over it a million times?

If there are NUL characters, there might be a bug in the awk script that
generates usbdevs.h.  If there are no NUL characters, and you get a
random failure each time, there might be a bug in clang.  But did you
mean you also saw it with gcc?

-Dimitry

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

Re: Phantom nulls in usbdevs.h during 9-STABLE kernel build

[Dimitry Andric]

On Jul 4, 2013, at 18:02, J David j.david.li...@gmail.com wrote:
...
 Yes, I am pretty sure we have seen this with gcc as well because one of the 
 first machines that started doing this doesn't have the CLANG options in 
 make.conf.  I will try to reproduce that to be absolutely sure, but that may 
 take several hours.

One other thing: which type of file system are you using for /usr/obj, or 
wherever you pointed $MAKEOBJDIRPREFIX?

-Dimitry

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

Re: sshd didn't run after upgrade to FreeBSD 8.4

[Dimitry Andric]

On Jun 20, 2013, at 02:24, Kimmo Paasiala kpaas...@gmail.com wrote:
...
 Ok, this is crazy. If you put one space after the VersionAddendum
 keyword you get exactly what you want, an empty VersionAddendum
 string. If there's no space but a newline right after the
 VersionAddendum keyword, sshd(8) complains about the line and refuses
 to start. So this is ok (without the single quotes, they are just to
 show the endings of the lines):
 
 'VersionAddendum '
 
 But this is not:
 
 'VersionAddendum'
 
 What are the OpenSSH devs thinking?


I assume they did not take this scenario into account at all.  The
VersionAddendum setting had been a custom FreeBSD addition for some
time, and was not available at all in upstream OpenSSH.  When upstream
decided to add it, they did not specifically care about backwards
compatibility with (until that time) non-standard configuration files...

-Dimitry

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

Re: include/c++/v1 still in BSD.include.dist as well as in obsolete_files

[Dimitry Andric]

On Jun 18, 2013, at 21:03, Kevin Oberman rkober...@gmail.com wrote:
 When I run make check-old, the /usr/include/c++/v1 and v1/ext directories
 are listed as old, but they are still present in BSD.include.dist, so are
 recreated every time I installworld.
 
 Could these directories be removed from BSD.include.dist, as I am pretty
 sure that they ARE obsolete.

They are not obsolete, as they are part of libc++, but I don't think it
is already possible to have parts of mtree files depend on WITH_XXX
settings.  So we can either remove the directories (but not the files)
from ObsoleteFiles.inc, or attempt to amend mtree so it can handle
conditional parts.

Brooks, any idea if NetBSD's mtree supports that feature? :-)

-Dimitry

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

Re: Error in make buildkernel `

[Dimitry Andric]

On Jun 10, 2013, at 14:04, Willem Jan Withagen w...@digiware.nl wrote:
 I'm trying to build a stable kernle on a freshly build 8.4-Stable i386
 system.
 
 And I get:
 MAKE=make sh /usr/srcs/src9/src/sys/conf/newvers.sh GENERIC
 /usr/local/bin/svnversion
 cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs
 -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
 -Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I.
 -I/usr/srcs/src9/src/sys -I/usr/srcs/src9/src/sys/contrib/altq -D_KERNEL
 -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
 -finline-limit=8000 --param inline-unit-growth=100 --param
 large-function-growth=1000  -mno-align-long-strings
 -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float
 -ffreestanding -fstack-protector -Werror  vers.c
 ctfconvert -L VERSION -g vers.o
 linking kernel.debug
 ld:/usr/srcs/src9/src/sys/conf/ldscript.i386:66: syntax error
 *** Error code 1

You must run make kernel-toolchain first.  Alternatively, run make
buildworld, but that is more work.

-Dimitry

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

Re: Error in make buildkernel `

[Dimitry Andric]

On Jun 10, 2013, at 20:39, Willem Jan Withagen w...@digiware.nl wrote:
 Op 10 jun. 2013 om 19:27 heeft Dimitry Andric d...@freebsd.org het volgende 
 geschreven:
 On Jun 10, 2013, at 14:04, Willem Jan Withagen w...@digiware.nl wrote:
 I'm trying to build a stable kernle on a freshly build 8.4-Stable i386
 system.
 
 And I get:
 MAKE=make sh /usr/srcs/src9/src/sys/conf/newvers.sh GENERIC
 /usr/local/bin/svnversion
 cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs
 -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
 -Wmissing-include-dirs -fdiagnostics-show-option   -nostdinc  -I.
 -I/usr/srcs/src9/src/sys -I/usr/srcs/src9/src/sys/contrib/altq -D_KERNEL
 -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
 -finline-limit=8000 --param inline-unit-growth=100 --param
 large-function-growth=1000  -mno-align-long-strings
 -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float
 -ffreestanding -fstack-protector -Werror  vers.c
 ctfconvert -L VERSION -g vers.o
 linking kernel.debug
 ld:/usr/srcs/src9/src/sys/conf/ldscript.i386:66: syntax error
 *** Error code 1
 
 You must run make kernel-toolchain first.  Alternatively, run make
 buildworld, but that is more work.
 
 I usually run buildworld from  crontab first, and then builkernel.
 But things might have gone wrong.

To explain this a bit more: FreeBSD 9.x and later have binutils 2.17.50,
FreeBSD 8.x has binutils 2.15.  The kernels for 9.x and later use a bit
of linker script syntax that is not understood by the older ld in 8.x,
so you cannot link the 9.x kernel with /usr/bin/ld on 8.x.

Therefore, you have to build the newer linker as part of buildworld, or
by using the kernel-toolchain target.

-Dimitry

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

Re: Serial terminal issues

[Dimitry Andric]

On Jun 4, 2013, at 23:32, Alban Hertroys haram...@gmail.com wrote:
 I can't seem to get my serial terminal to work with my new system.
...
 cat /boot.config 
 -D -S19200
 
 cat /boot/loader.conf 
 boot_multicons=YES
 boot_serial=YES
 comconsole_speed=19200
 console=comconsole,vidconsole

Does it work at 9600 baud?  Otherwise, check RTS/CTS, etc.

-Dimitry

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

Re: Command line not responding

[Dimitry Andric]

On May 17, 2013, at 19:56, Michael Gass mg...@csbsju.edu wrote:
 Running 9.0-Stable on an i386.
 
 Whenever I type a command at the prompt I get
 the output
 
 /usr/local/lib/libintl.so.9: Undefined symbol _ThreadRuneLocale
 
 and nothing else - the command will not run.

Are you running bash, by any chance?  Because bash is usually linked to
libintl, for its internationalized messages.

In any case, it looks like there is a mismatch between your libc.so, and
your ports.  Did you recently update your base system?


 Started to happen after trying to update the freetype2 port.
 Got an error msg while updating libXft-2.1.14.  From that point
 on I cannot use  the command line.

How did you update those ports?  Did you rebuild them, or install
precompiled binary packages?  If the latter, where exactly did you
retrieve those packages from?

-Dimitry

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

Re: make buildkernel for GENERIC 9-STABLE just hangs, no error (was svn commit: r249549 - in stable/9/sys: amd64/conf i386/conf)

[Dimitry Andric]

On Apr 17, 2013, at 17:41, Pedro Giffuni p...@freebsd.org wrote:
 On 04/17/13 03:29, Jeremy Chadwick wrote:
 On Tue, Apr 16, 2013 at 04:09:28PM +, Brooks Davis wrote:
 Author: brooks
 Date: Tue Apr 16 16:09:27 2013
 New Revision: 249549
 URL: http://svnweb.freebsd.org/changeset/base/249549
 
 Log:
   MFC (much delayed) 234504:
  Enable DTrace hooks in GENERIC.
 
 Modified:
   stable/9/sys/amd64/conf/GENERIC
   stable/9/sys/i386/conf/GENERIC
 Directory Properties:
   stable/9/sys/   (props changed)
 
 ...
 And here come the complaints, which warrant responses from key folks who
 are in the know:
 
 http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073132.html
 
 
 It looks like 9 days ago there was a change (r249243) that fixed
 issues on the userland ctf utilities, so you have to update your
 userland too if it's not recent (make buildworld works fine).

That was only a fix for certain DWARF attributes emitted by clang and/or
newer gcc's, which would cause ctfmerge to error out.

If ctfmerge is hanging, that is almost certainly another problem.  That
is, if it is really hanging, isn't it just very slow, maybe?  What
happens if the original poster lets it run for e.g. an hour?

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

Re: fusefs-kmod does not work on 8-STABLE?

[Dimitry Andric]

On 2013-04-16 08:14, Alexey Dokuchaev wrote:

On Mon, Apr 15, 2013 at 10:41:36PM -0400, Ryan Stone wrote:

On Fri, Apr 12, 2013 at 10:28 AM, Alexey Dokuchaev da...@nsu.ru wrote:

I've found the culprit: the problem is in this command of the build:

 ld -Bshareable  -d -warn-common -o hello.ko.debug hello.kld

I had put /usr/local/bin in my $PATH before /usr/bin for a reason I don't
currently recall, and have binutils-2.23.1 installed.  As a result, ld(1)
in the quoted line above was called from /usr/local/bin/ld, [...]


Is this for i386?  When compiling modules with newer versions of ld I had
to add the following flags to the ld invocation to get the module to work:


Yes, this is for i386.


-u __start_set_sysinit_set -u __start_set_sysuninit_set \
-u __start_set_sysctl_set -u __start_set_modmetadata_set \
-u __stop_set_sysinit_set -u __stop_set_sysuninit_set \
-u __stop_set_sysctl_set -u __stop_set_modmetadata_set


Hmm.  Adding these does help, indeed.  How did you come up with this list?
Is it documented anywhere, or just the result of careful readelf/objdump
examination?  Thanks!


These are module start/stop symbols, which get optimized away by newer
versions of binutils.  We fixed it in head when binutils 2.17.50 was
imported, here:

http://svn.freebsd.org/changeset/base/215137

This fix could probably also be used for stable/8.  It is most likely
too late to get into 8.4, though.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: gnutls compile issues

[Dimitry Andric]

On Apr 13, 2013, at 03:15, dparussa...@baysidegrp.com.au wrote:
 I am having issues compiling gnutls-2.12.23 on Freebsd 6.4 stable
 platform. Please find the following errors.
 
 Any help much appropriated.
 
 checking whether wchar.h uses 'inline' correctly... no
 configure: error: wchar.h cannot be used with this compiler (cc
 -std=gnu99 -O2 -fno-strict-aliasing -pipe -I/usr/local/include/p11-kit-1  
 -I/usr/local/include -fPIC -D_THREAD_SAFE).
 This is a known interoperability problem of glibc = 2.5 with gcc = 4.3 in
 C99 mode. You have four options:
  - Add the flag -fgnu89-inline to CC and reconfigure, or
  - Fix your include files, using parts of

 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b037a293a48718af30d706c2e18c929d0e69a621,
 or
  - Use a gcc version older than 4.3, or
  - Don't use the flags -std=c99 or -std=gnu99.


Let me start by saying 6.4 is totally unsupported, but you are most
likely aware of that. :-)

That said, I don't think 6.4 already had complete C99 support, so this
is probably why the configure script fails.  You can see the script
itself gives you a few hints for a workaround.  Since 6.4 is already
using a gcc version older than 4.3, and the fix your include files
hint is only valid for glibc, the best option is to make sure -std=c99
or -std=gnu99 is *not* used.

For example, if you are building this manually, try setting
ac_cv_prog_cc_c99=no in configure's environment, like so:

  ac_cv_prog_cc_c99=no ./configure

If you are building this from the port, try adding a line:

  CONFIGURE_ENV+= ac_cv_prog_cc_c99=no

in the port's Makefile.

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

Re: fusefs-kmod does not work on 8-STABLE?

[Dimitry Andric]

On Apr 12, 2013, at 16:28, Alexey Dokuchaev da...@nsu.ru wrote:
...
 I've found the culprit: the problem is in this command of the build:
 
ld -Bshareable  -d -warn-common -o hello.ko.debug hello.kld
 
 I had put /usr/local/bin in my $PATH before /usr/bin for a reason I don't
 currently recall, and have binutils-2.23.1 installed.  As a result, ld(1)
 in the quoted line above was called from /usr/local/bin/ld, which brought
 in all the weird things I was observing: failure of fusefs-kmod, failure
 of simple hello world KLD, link_elf: symbol blah undefined messages
 when loading snd_hda(4) and nvidia(4) drivers.
 
 How, does anyone have a clue why new ld(1) plays so badly with our system
 toolchain on 8.x (at least)?


Maybe because there is almost 10 years difference between those
implementations? :-)

In any case, to figure out what is different, just try linking the
kernel module with the system ld and the ports ld, and comparing
readelf -a output.

Or upload both module versions somewhere, so we can all have a look.

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