Re: svn commit: r367304 - in head: share/man/man5 share/mk tools/build/options usr.bin usr.bin/clang usr.bin/clang/llvm-cxxfilt
On Wed, 4 Nov 2020 at 12:40, Dimitry Andric wrote: > > I think this guidance originates from the world of embedded systems, > where storage size is a more limiting factor than on recent desktop or > server class machines. On my desktops I won't care too much whether an > executable is 1M or 100MB, but on a small SD card things add up very > quickly! Indeed, although even there the lowest-capacity SD card available in the market keeps growing. Most of the tool chain is irrelevant for embedded systems and the size makes little difference, but there are some tool chain components that may be of interest. We don't expect Clang on a constrained target, but might want find size, or strings. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r367304 - in head: share/man/man5 share/mk tools/build/options usr.bin usr.bin/clang usr.bin/clang/llvm-cxxfilt
On 4 Nov 2020, at 17:38, Shawn Webb wrote: > > On Wed, Nov 04, 2020 at 11:26:51AM -0500, Ed Maste wrote: >> On Tue, 3 Nov 2020 at 14:57, Dimitry Andric wrote: >>> >>> Author: dim >>> Date: Tue Nov 3 19:57:28 2020 >>> New Revision: 367304 >>> URL: https://svnweb.freebsd.org/changeset/base/367304 >>> >>> Log: >>> Add WITH_LLVM_CXXFILT option to install llvm-cxxfilt as c++filt >> >> A previous argument against the LLVM versions of binutils replacements >> is that they were excessively large, but this does not look like a >> substantial problem here. LLVM's cxxfilt is indeed many times the size >> of ELF Tool Chain's, but still small enough that for a tool chain >> component it's not a concern, in my opinion. >> >> ELF Tool Chain: >> $ size obj/c++filt >> text databss dec hex filename >> 66966 1008 8400 76374 0x12a56 obj/c++filt >> >> LLVM: >> $ size obj/llvm-cxxfilt >>text databss dec hex filename >> 378138 1756 9165 389059 0x5efc3 obj/llvm-cxxfilt >> >> A remaining issue is that both nm and addr2line can also demangle C++ >> symbols. > > This brings a question: is there any guidance as to what FreeBSD > considers "too large of a component" for a toolchain component (or any > other various components, like src.git/stand)? I think this guidance originates from the world of embedded systems, where storage size is a more limiting factor than on recent desktop or server class machines. On my desktops I won't care too much whether an executable is 1M or 100MB, but on a small SD card things add up very quickly! That said, llvm-related tools such as llvm-ar or llvm-cxxfilt are pretty big, mainly because all of them are written in C++ with a lot of templates, and we link the llvm and clang .a files statically into them. It would save some space to stuff all those library files into a shared library, and link the tools against that, but the disadvantage is that it will take a *lot* of memory and CPU time to link that (huge) shared library. I experimented a little with that in the past, and it's very difficult to make it work on 32-bit systems. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: svn commit: r367304 - in head: share/man/man5 share/mk tools/build/options usr.bin usr.bin/clang usr.bin/clang/llvm-cxxfilt
On Wed, Nov 04, 2020 at 11:26:51AM -0500, Ed Maste wrote: > On Tue, 3 Nov 2020 at 14:57, Dimitry Andric wrote: > > > > Author: dim > > Date: Tue Nov 3 19:57:28 2020 > > New Revision: 367304 > > URL: https://svnweb.freebsd.org/changeset/base/367304 > > > > Log: > > Add WITH_LLVM_CXXFILT option to install llvm-cxxfilt as c++filt > > A previous argument against the LLVM versions of binutils replacements > is that they were excessively large, but this does not look like a > substantial problem here. LLVM's cxxfilt is indeed many times the size > of ELF Tool Chain's, but still small enough that for a tool chain > component it's not a concern, in my opinion. > > ELF Tool Chain: > $ size obj/c++filt >text databss dec hex filename > 66966 1008 8400 76374 0x12a56 obj/c++filt > > LLVM: > $ size obj/llvm-cxxfilt > text databss dec hex filename > 378138 1756 9165 389059 0x5efc3 obj/llvm-cxxfilt > > A remaining issue is that both nm and addr2line can also demangle C++ symbols. This brings a question: is there any guidance as to what FreeBSD considers "too large of a component" for a toolchain component (or any other various components, like src.git/stand)? I ask mostly out of curiousity. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: svn commit: r367304 - in head: share/man/man5 share/mk tools/build/options usr.bin usr.bin/clang usr.bin/clang/llvm-cxxfilt
On Tue, 3 Nov 2020 at 14:57, Dimitry Andric wrote: > > Author: dim > Date: Tue Nov 3 19:57:28 2020 > New Revision: 367304 > URL: https://svnweb.freebsd.org/changeset/base/367304 > > Log: > Add WITH_LLVM_CXXFILT option to install llvm-cxxfilt as c++filt A previous argument against the LLVM versions of binutils replacements is that they were excessively large, but this does not look like a substantial problem here. LLVM's cxxfilt is indeed many times the size of ELF Tool Chain's, but still small enough that for a tool chain component it's not a concern, in my opinion. ELF Tool Chain: $ size obj/c++filt text databss dec hex filename 66966 1008 8400 76374 0x12a56 obj/c++filt LLVM: $ size obj/llvm-cxxfilt text databss dec hex filename 378138 1756 9165 389059 0x5efc3 obj/llvm-cxxfilt A remaining issue is that both nm and addr2line can also demangle C++ symbols. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
