Re: CVS commit: src/external/mpl/dhcp
In article <12738.1529677...@splode.eterna.com.au>, matthew green wrote: > >why does dhclient link this way? at the very least, adding >a comment to the Makefile.inc would help, but i wonder if this >is not some artifact of old times we should remove, at least >for MKDYNAMICROOT=yes. Explained. christos
Re: CVS commit: src/external/mpl/dhcp
On 22.06.2018 17:05, Jason Thorpe wrote: > > >> On Jun 22, 2018, at 7:44 AM, matthew green wrote: >> >> meaning -- it uses libraries normally installed in /usr/lib but >> links them statically? >> >> those libraries should move to /lib. they're already part of >> the root fs (mostly). then all this stupid makefile and linking >> crap can go away, and your problem solved. > > Modulo the silliness of continuing to support /usr on a separate file system, > "what Matt said." > > -- thorpej > From a MKSANITIZER point of view we want to remove conflicts with libc and libpthread symbols. http://netbsd.org/~kamil/programs-baselibs-symbol-clash-2018-06-03-2.txt signature.asc Description: OpenPGP digital signature
re: CVS commit: src/external/mpl/dhcp
> Well, there is an ongoing discussion to phase out dhcp (dhclient) out of > the base system. i'm going to object to that -- while i prefer dhcpcd i've twice needed for temporary issues, and not having working networking while travelling (this was one case) is really not something we want to deal with ;) this is also irrelevant to the problem at hand. > It duplicates symbols from libraries in order to be usable without /usr > mounted. meaning -- it uses libraries normally installed in /usr/lib but links them statically? those libraries should move to /lib. they're already part of the root fs (mostly). then all this stupid makefile and linking crap can go away, and your problem solved. .mrg.
Re: CVS commit: src/external/mpl/dhcp
On 22.06.2018 16:18, matthew green wrote: > "Kamil Rytarowski" writes: >> Module Name: src >> Committed By:kamil >> Date:Thu Jun 21 11:02:48 UTC 2018 >> >> Modified Files: >> src/external/mpl/dhcp: Makefile.inc >> >> Log Message: >> Make building of dhcp compatible with MKSANITIZER >> >> Disable LD flags (-Wl,-Bstatic and -Wl,-Bdynamic) with enabled MKSANITIZER. >> These options are incompatible with the current design of sanitizers, >> because they cause duplication of symbols into programs and thus symbols >> from the interceptors from sanitizers cannot be linked. >> >> This change makes effectively mounting /usr required for dhcp programs like >> dhclient(8). > > why does dhclient link this way? at the very least, adding > a comment to the Makefile.inc would help, but i wonder if this > is not some artifact of old times we should remove, at least > for MKDYNAMICROOT=yes. > > > .mrg. > Well, there is an ongoing discussion to phase out dhcp (dhclient) out of the base system. It duplicates symbols from libraries in order to be usable without /usr mounted. dhcpcd doesn't need it. signature.asc Description: OpenPGP digital signature
re: CVS commit: src/external/mpl/dhcp
"Kamil Rytarowski" writes: > Module Name: src > Committed By: kamil > Date: Thu Jun 21 11:02:48 UTC 2018 > > Modified Files: > src/external/mpl/dhcp: Makefile.inc > > Log Message: > Make building of dhcp compatible with MKSANITIZER > > Disable LD flags (-Wl,-Bstatic and -Wl,-Bdynamic) with enabled MKSANITIZER. > These options are incompatible with the current design of sanitizers, > because they cause duplication of symbols into programs and thus symbols > from the interceptors from sanitizers cannot be linked. > > This change makes effectively mounting /usr required for dhcp programs like > dhclient(8). why does dhclient link this way? at the very least, adding a comment to the Makefile.inc would help, but i wonder if this is not some artifact of old times we should remove, at least for MKDYNAMICROOT=yes. .mrg.
Re: CVS commit: src/usr.bin/ldd
On 22.06.2018 15:38, matthew green wrote: > "Kamil Rytarowski" writes: >> Module Name: src >> Committed By:kamil >> Date:Thu Jun 21 10:41:46 UTC 2018 >> >> Modified Files: >> src/usr.bin/ldd/build: Makefile >> src/usr.bin/ldd/elf32: Makefile >> src/usr.bin/ldd/elf32_compat: Makefile >> src/usr.bin/ldd/elf64: Makefile >> >> Log Message: >> Disable SANITIZER for ldd(1) >> >> These utilities (elf32, elf32_compat, elf64, liblldb) share code with the >> ELF dynamic loader that is not being sanitized and its symbols are >> installed into sanitized programs (in particular __tls_get_addr()). >> >> Additionally libldd is used in rescue that is not expected to be sanitized >> as of today. > > i'm not sure i understand. ldd itself should be able to be > sanitized. even with shared code with ld.elf_so, this copy > shouldn't be doing anything but reading data and outputting > the various linkages found, but never executing anything not > in ldd binary itself. (this is unlike traditional ldd(1) > in most implementations, which often makes the dynamic > linker do the real work of ldd.) > > what's the specific issue? perhaps we can fix it.. > The first conflict is with __tls_get_addr(). This symbol could be renamed. I'm in the process of designing a macro to rename conflicting symbols, dedicated for programs in external/ and those reusing source code from non-stanitized libraries like libc. The current list of manual renames is specified here: http://netbsd.org/~kamil/patch-00055-rename-symbols-clash-with-sanitizers.txt Once I will get an installable release image under ASan, I will present the macro and we can reevaluate ldd(1). My current progress is being on the installboot(8) stage: http://netbsd.org/~kamil/mksanitizer-reports/0020-installboot-ffsv2.txt > > .mrg. > signature.asc Description: OpenPGP digital signature
Re: CVS commit: src/share/mk
On Fri, Jun 22, 2018 at 12:37:34PM +1000, matthew green wrote: > "Maya Rashish" writes: > > Module Name:src > > Committed By: maya > > Date: Wed Jun 20 02:15:13 UTC 2018 > > > > Modified Files: > > src/share/mk: sys.mk > > > > Log Message: > > Strip -Wsystem-headers from CXXFLAGS. > > > > GCC's C++ headers are not clean (yet). They are trying, but haven't got > > there > > yet. > > > > Necessary for including which uses . > > can you add a comment about this? the stripping is normally > about stuff that c++ frontend does not support, vs stuff that > breaks because of other issues. > > ie, the rest of them should always stay, but this one will > hopefully go away in the future. > > thanks. At least a few of them seem to be accepted by g++ and clang++: -ffreestanding -Wno-format-zero-length
Re: CVS commit: src/sys/arch
Le 20/06/2018 à 21:26, Jaromír Doleček a écrit : 2018-06-20 18:03 GMT+02:00 Maxime Villard : I haven't tested but looking at the code it seems to me that this part of your change breaks DAZ on native, and I don't see how it can help xsave on xen by the way Thanks, I'll change the conditional to avoid any potential change of behaviour for native. Your change was still wrong, and I've reverted it. It made no sense: no-xsave can't disable fxsave, because even if you don't call it in fpuinit_mxcsr_mask, it still gets called in the rest of the fpu code. I see on current-users@ that xen machines are crashing now; as I said already, there was a stack alignment problem there several months ago. Looking at the crash report, it's still the same problem it seems. No point adding nonsensical conditionals there, you just broke both native and xen. Also, your changes in XSAVE are still wrong to me, so please fix that correctly - as I said in my first email, the detection logic should be done in identcpu.c (unless there is a good reason for not doing so, which there doesn't seem to be), and you shouldn't enable FXSAVE if XSAVE is not supported because it may be that *neither* is supported. Maxime
