svn commit: r367304 - in head: share/man/man5 share/mk tools/build/options usr.bin usr.bin/clang usr.bin/clang/llvm-cxxfilt

[Dimitry Andric]

On 4 Nov 2020, at 17:38, Shawn Webb <shawn.webb at hardenedbsd.org> wrote:
> 
> On Wed, Nov 04, 2020 at 11:26:51AM -0500, Ed Maste wrote:
>> On Tue, 3 Nov 2020 at 14:57, Dimitry Andric <dim at freebsd.org> 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   data    bss     dec       hex   filename
>>  66966   1008   8400   76374   0x12a56   obj/c++filt
>> 
>> LLVM:
>> $ size obj/llvm-cxxfilt
>>    text   data    bss      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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20201104/c8fafc7f/attachment.sig>