Default llvm-size output format berkeley (but also darwin) is useless on macOS

[therealprof]

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.

[llvmbot]

@llvm/issue-subscribers-tools-llvm-size

Author: Daniel Egger (therealprof)

I'm really amazed that no-one 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.