Re: [Bug 223383] pathconf querying for posix_falloc not supported on freebsd [devel/llvm*'s lld's are also broken by this for zfs and need updating]

[Mark Millard]

[ devel/llvm* also have the issue in their
lld 's.]

On 2017-Nov-7, at 4:43 PM, bugzilla-noreply at freebsd.org wrote:

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223383
> 
> --- Comment #7 from commit-h...@freebsd.org ---
> A commit references this bug:
> 
> Author: emaste
> Date: Wed Nov  8 00:39:04 UTC 2017
> New revision: 325523
> URL: https://svnweb.freebsd.org/changeset/base/325523
> 
> Log:
>  MFC r325420: lld: accept EINVAL to indicate posix_fallocate is unsupported
> 
>  As of r325320 posix_fallocate on a ZFS filesystem returns EINVAL to
>  indicate that the operation is not supported. (I think this is a strange
>  choice of errno on the part of POSIX.)
> 
>  PR:   223383, 223440
>  Reported by:  Mark Millard
>  Sponsored by: The FreeBSD Foundation
> 
> Changes:
> _U  stable/11/
>  stable/11/contrib/llvm/lib/Support/Unix/Path.inc
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Context a zfs file system.]

>From /usr/src/UPDATING:

20171106:
The naive and non-compliant support of posix_fallocate(2) in ZFS
has been removed as of r325320.  The system call now returns EINVAL
when used on a ZFS file.  Although the new behavior complies with the
standard, some consumers are not prepared to cope with it.
One known victim is lld prior to r325420.


The issue is not limited to the system clang's
associated lld. 

Here is an attempt to use clang++50, implicitly using
its associated lld:

# clang++50 -v exception_test.cc
clang version 5.0.0 (tags/RELEASE_500/final)
Target: x86_64-portbld-freebsd12.0
Thread model: posix
InstalledDir: /usr/local/llvm50/bin
 "/usr/local/llvm50/bin/clang-5.0" -cc1 -triple x86_64-portbld-freebsd12.0 
-emit-obj -mrelax-all -disable-free -main-file-name exception_test.cc 
-mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose 
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -v -dwarf-column-info 
-debugger-tuning=gdb -resource-dir /usr/local/llvm50/lib/clang/5.0.0 
-internal-isystem /usr/include/c++/v1 -fdeprecated-macro 
-fdebug-compilation-dir /root/c_tests -ferror-limit 19 -fmessage-length 200 
-fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option 
-fcolor-diagnostics -o /tmp/exception_test-baadc9.o -x c++ exception_test.cc
clang -cc1 version 5.0.0 based upon LLVM 5.0.0 default target 
x86_64-portbld-freebsd12.0
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/v1
 /usr/local/llvm50/lib/clang/5.0.0/include
 /usr/include
End of search list.
 "/usr/local/llvm50/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 
--hash-style=both --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o 
/usr/lib/crtbegin.o -L/usr/lib /tmp/exception_test-baadc9.o -lc++ -lm -lgcc 
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed 
/usr/lib/crtend.o /usr/lib/crtn.o
/usr/local/llvm50/bin/ld: error: cannot open output file a.out: Invalid argument
clang-5.0: error: linker command failed with exit code 1 (use -v to see 
invocation)


https://svnweb.freebsd.org/ports/head/devel/?dir_pagestart=1000

does not yet suggest updates to devel/llvm* 's for
the issue.

===
Mark Millard
markmi at dsl-only.net

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

Re: bootonly release target not creating etc/ssh/

[Herbert J. Skuhra]

On Thu, 09 Nov 2017 18:55:52 +0100,
Roger Pau Monné  wrote:
> 
> Hello,
> 
> Since recently it seems like the bootonly release make target doesn't
> create the etc/ssh directory. I've usually done:
> 
> # make buildworld
> # make buildkernel
> # make -C release ftp
> # make -C release bootonly
> # cp  release/bootonly/etc/ssh/
> 
> But the ssh directory doesn't seem to exist anymore. Is this expected?

Hi,

on my system the files are no longer in $SRCPATH/release but in
/usr/obj/$SRCPATH/$TARGET.$TARGET_ARCH/release:

$ ls -l 
/usr/obj/usr/home/herbert/source/freebsd/head/src/amd64.amd64/release/bootonly/etc/ssh
total 54
-rw-r--r--  1 root  wheel  553185 10 Nov 00:26 moduli
-rw-r--r--  1 root  wheel1780 10 Nov 00:26 ssh_config
-rw-r--r--  1 root  wheel3359 10 Nov 00:26 sshd_config


Not sure if this is expected, a bug or PBKAC. :)

--
Herbert
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: make -C weirdness

[Ilya A . Arkhipov]

01.11.2017, 22:17, "Sergey V. Dyatko" :
> Hi,
>
> Long time ago I wrote 2 simple aliases to my .cshrc:
>
> search_key make -C /usr/ports/ search key='!*' display=name,path,info
> search_name make -C /usr/ports/ search name='!*' display=port,path,info
>
> it works fine starting from 7-CURRENT IIRC.
> Today I tried to find some (existing) port and can't, for example:
> [tiger@laptop]:/>make -C /usr/ports/ search name=teeworlds
> display=name,path,info
> [tiger@laptop]:/>
> but
> [tiger@laptop]:/>cd /usr/ports/
> [tiger@laptop]:/usr/ports>make search name=teeworlds display=name,path,info
> Port: teeworlds-0.6.4_4
> Path: /usr/ports/games/teeworlds
> Info: Platform game featuring buggers equipped with
> weapons
>
> it is on 12.0-CURRENT r324493
> I missed something or it is a bug?
>
> --
> wbr, Sergey
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FYI: https://reviews.freebsd.org/D13019

-- 
With Best Regards,
Ilya A. Arkhipov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

bootonly release target not creating etc/ssh/

[Roger Pau Monné]

Hello,

Since recently it seems like the bootonly release make target doesn't
create the etc/ssh directory. I've usually done:

# make buildworld
# make buildkernel
# make -C release ftp
# make -C release bootonly
# cp  release/bootonly/etc/ssh/

But the ssh directory doesn't seem to exist anymore. Is this expected?

I expect also trying to launch sshd inside of that install is going to
cause trouble, but I cannot verify because I cannot finish building
the image.

Thanks, Roger.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: XBOX/i386 and xlint removal

[Ed Schouten]

[ +rink@ for XBOX/i386 ]

2017-11-09 14:52 GMT+01:00 Konstantin Belousov :
> Hello,
> I created two reviews to axe two features which I personally find of
> little use in modern FreeBSD.
>
> https://reviews.freebsd.org/D13015 xlint
> https://reviews.freebsd.org/D13016 XBOX/i386
>
> Reviews contain the explanations.  For xlint it is just an overdue, IMO.
> While for XBOX I do not have much opposition against supporting the
> obsoleted platforms, but the way the port was done pollutes the sources
> with too much #ifdefs.  Since people often do not want to care about i386
> together with amd64, additional hurdle only makes the things worse.
>
> Feel free to add yourself as reviewer.  I intend to commit the patches
> in a week, unless strong objections expressed by the time.

-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

clang crashes on "make -j4 buildkernel" at 12-CURRENT

[Lev Serebryakov]

 I'm trying to build new NanoBSD "firmware" and have semi-reproducable
clang crash.

 System is 12-CURRENT amd64 r325554, sources is 12-CURRENt r325594

 It is guest running on VirtualBox 5.2. Memory & CPU of host is Ok for sure.

 On "build kernel" stage with "make -j4" I get clang crash (output and
backtrace are at the end of this message).

  It is always at same place, so it doesn't look like random memory
error, but what is strange — "make -j1" works.

 Previous versions of FreeBSD didn't have this problem.

 Maybe, it is same problem as with lld and latest ZFS changes?

cc -target x86_64-unknown-freebsd12.0
--sysroot=/usr/obj/nanobsd/data/src/amd64.amd64/tmp
-B/usr/obj/nanobsd/data/src/amd64.amd64/tmp/usr/bin  -O2 -pipe
-fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-I/data/src/sys/netgraph/bluetooth/include
-I/data/src/sys/netgraph/bluetooth/drivers/ubt
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/nanobsd/data/src/amd64.amd64/sys/D2500CC/opt_global.h -I.
-I/data/src/sys -fno-common -g -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer
-I/usr/obj/nanobsd/data/src/amd64.amd64/sys/D2500CC   -MD
-MF.depend.ng_ubt.o -MTng_ubt.o -mcmodel=kernel -mno-red-zone -mno-mmx
-mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding
-fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Wno-error-shift-negative-value
-Wno-error-address-of-packed-member  -mno-aes -mno-avx
-std=iso9899:1999 -c
/data/src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c -o ng_ubt.o
Assertion failed: ((!RequiresNullTerminator || BufEnd[0] == 0) &&
"Buffer is not null terminated!"), function init, file
/data/src/contrib/llvm/lib/Support/MemoryBuffer.cpp, line 48.
cc: error: unable to execute command: Abort trap (core dumped)
cc: error: clang frontend command failed due to signal (use -v to see
invocation)
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on
LLVM 5.0.0svn)
Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
cc: 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.
cc: error: unable to execute command: Abort trap (core dumped)
cc: note: diagnostic msg: Error generating preprocessed source(s).
*** [ng_ubt.o] Error code 254

 Backtrace is

  * frame #0: 0x02dfa86a cc`thr_kill at thr_kill.S:3
frame #1: 0x02dfa83f cc`__raise(s=6) at raise.c:52
frame #2: 0x02dfa806 cc`abort at abort.c:77
frame #3: 0x02e2398a cc`__assert(func=,
file=, line=, failedexpr=) at
assert.c:51
frame #4: 0x02c1dbc0 cc`::getOpenFileImpl() [inlined] init
at MemoryBuffer.cpp:47
frame #5: 0x02c1dba7 cc`::getOpenFileImpl() [inlined]
MemoryBufferMMapFile at MemoryBuffer.cpp:216
frame #6: 0x02c1dba7 cc`::getOpenFileImpl() at
MemoryBuffer.cpp:369
frame #7: 0x02c1d806 cc`llvm::MemoryBuffer::getOpenFile(int,
llvm::Twine const&, unsigned long, bool, bool) at MemoryBuffer.cpp:415
frame #8: 0x00e5c8c1 cc`(anonymous
namespace)::RealFile::getBuffer(llvm::Twine const&, long, bool, bool) at
VirtualFileSystem.cpp:177
frame #9: 0x00e3e872
cc`clang::FileManager::getBufferForFile(clang::FileEntry const*, bool,
bool) + 146
frame #10: 0x00a08452 cc`::getBuffer() at SourceManager.cpp:98
frame #11: 0x005db4a7 cc`::getBuffer() at SourceManager.h:929
frame #12: 0x00768068
cc`clang::Preprocessor::EnterSourceFile(clang::FileID,
clang::DirectoryLookup const*, clang::SourceLocation) + 184
frame #13: 0x00774da7 cc`::HandleIncludeDirective() at
PPDirectives.cpp:2019
frame #14: 0x007709f7 cc`::HandleDirective() at
PPDirectives.cpp:966
frame #15: 0x00e4a376
cc`clang::Lexer::LexTokenInternal(clang::Token&, bool) + 4422
frame #16: 0x00e480d5 cc`clang::Lexer::Lex(clang::Token&) + 117
frame #17: 0x0073f1c2 cc`::Lex() at Preprocessor.cpp:751
frame #18: 0x004833fd cc`::RewriteIncludesInInput() at
InclusionRewriter.cpp:619
frame #19: 0x0040eaa2 cc`::ExecuteAction() at
FrontendActions.cpp:313
frame #20: 0x007d5bcc cc`::Execute() at FrontendAction.cpp:902
frame #21: 0x00d0faf1
cc`clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1217
frame #22: 0x0040b91e cc`::ExecuteCompilerInvocation() at
ExecuteCompilerInvocation.cpp:251
frame #23: 0x00400943 cc`::cc1_main() at cc1_main.cpp:221
frame #24: 0x00408f48 cc`main [inlined] ExecuteCC1Tool at
driver.cpp:306

Re: XBOX/i386 and xlint removal

[Warner Losh]

On Thu, Nov 9, 2017 at 6:52 AM, Konstantin Belousov 
wrote:

> Hello,
> I created two reviews to axe two features which I personally find of
> little use in modern FreeBSD.
>
> https://reviews.freebsd.org/D13015 xlint
> https://reviews.freebsd.org/D13016 XBOX/i386
>
> Reviews contain the explanations.  For xlint it is just an overdue, IMO.
> While for XBOX I do not have much opposition against supporting the
> obsoleted platforms, but the way the port was done pollutes the sources
> with too much #ifdefs.  Since people often do not want to care about i386
> together with amd64, additional hurdle only makes the things worse.
>
> Feel free to add yourself as reviewer.  I intend to commit the patches
> in a week, unless strong objections expressed by the time.
>

Thanks for the heads up.

Both of these items are ripe for removal. XBOX was doable back in the day
when one could still obtain the necessary hacking hardware to allow FreeBSD
to run on it. Today, that's become unobtainium for the most part. I looked
to get an XBOX running a couple of years ago, and at that time it was hard
to get the right stuff. Today, all hacking xbox stuff online is about the
newer xbox 360 or xbox one, which would be interesting projects too, but
have nothing to do with this code. In 2005, when I originally committed the
code, it was a simple thing to find. By 2010 it was hard and by 2015 it was
almost impossible. I had a XBOX that I got rid of a couple of years ago
because I couldn't find the modding kit that would allow it to run FreeBSD
easily. One can buy modded XBOXes on ebay still for ~$150-$200, but those
machines are marketed as retro gaming consoles...

The XBOX code itself isn't horrible. It shows some flaws in our ability to
do memory detection and prevent access to hardware that a problem. Some
cleanup in the area would theoretically be useful, but it would have been
useful a decade ago. Not so much today. The cruft is minor, but for a
platform that's even less useful to support than pc98 and that also is gone.

xlint hasn't been useful since before clang went into the tree. While I
have a small twinge of nostalgia for it, it's only a small twinge and it
too is past its freshness date.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

XBOX/i386 and xlint removal

[Konstantin Belousov]

Hello,
I created two reviews to axe two features which I personally find of
little use in modern FreeBSD.

https://reviews.freebsd.org/D13015 xlint
https://reviews.freebsd.org/D13016 XBOX/i386

Reviews contain the explanations.  For xlint it is just an overdue, IMO.
While for XBOX I do not have much opposition against supporting the
obsoleted platforms, but the way the port was done pollutes the sources
with too much #ifdefs.  Since people often do not want to care about i386
together with amd64, additional hurdle only makes the things worse.

Feel free to add yourself as reviewer.  I intend to commit the patches
in a week, unless strong objections expressed by the time.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"