Default llvm-size output format berkeley (but also darwin) is useless on macOS #86644
Description
I'm really amazed that I couldn't find any complaints about this, especially since the LLVM toolchain is used by default on macOS.
When using llvm-size on macOS, it uses the berkeley format which renders something like:
__TEXT __DATA __OBJC others dec hex
10289152 32768 0 4296048640 4306370560 100ae0000
with absurdly large total sizes, which are of course not true.
Switching to darwin format, it immediately becomes clear what the issue is:
Segment __PAGEZERO: 4294967296
Segment __TEXT: 10289152
Section __text: 7112552
Section __stubs: 1596
Section __gcc_except_tab: 429400
Section __const: 1418776
Section __unwind_info: 197152
Section __eh_frame: 1111852
total 10271328
Segment __DATA_CONST: 704512
Section __got: 1080
Section __const: 696352
total 697432
Segment __DATA: 32768
Section __data: 15232
Section __thread_vars: 960
Section __thread_data: 112
Section __thread_bss: 1456
Section __common: 8872
Section __bss: 592
total 27224
Segment __LINKEDIT: 376832
total 4306370560
The huge PAGEZERO segment (which of course is all virtual) is added to the file size, rendering the output of llvm-size almost completely useless.
The only format yielding a useful and correct result is sysv
section size addr
__text 7112552 4294984960
__stubs 1596 4302097512
__gcc_except_tab 429400 4302099108
__const 1418776 4302528512
__unwind_info 197152 4303947288
__eh_frame 1111852 4304144440
__got 1080 4305256448
__const 696352 4305257528
__data 15232 4305960960
__thread_vars 960 4305976192
__thread_data 112 4305977152
__thread_bss 1456 4305977264
__common 8872 4305978752
__bss 592 4305987624
Total 10995984
... which is not great.