//tools/binary_size/supersize doesn't work well on Linux |
||||
Issue description
Creating a .size file via "tools/binary_size/supersize archive" on Linux isn't nearly as accurate/helpful as it is on Android.
There's much more noise in generated diffs and the symbol paths aren't working properly:
3644096 r@Group 3644096 {no path}
** merge strings (count=6)
4118368 d@0x7af87b0 474272 /tmp/lto-llvm-169e50.o
.L__unnamed_712
4413032 d@0x7a749f0 294664 /tmp/lto-llvm-169e50.o
.L__unnamed_1193
4675188 r@0x6934140 262156 /tmp/lto-llvm-169e50.o
kTextLayoutCodeProperties
4895944 r@0x64d3410 220756 /tmp/lto-llvm-169e50.o
net::kPreloadedHSTSData
5097192 d@0x794b650 201248 /tmp/lto-llvm-169e50.o
.L__unnamed_481
5288832 d@0x79b96f0 191640 /tmp/lto-llvm-169e50.o
.L__unnamed_211
5476696 d@0x7a14230 187864 /tmp/lto-llvm-169e50.o
,
May 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/47f9431d5a69ae9e81faa6472d8b5a188eb63242 commit 47f9431d5a69ae9e81faa6472d8b5a188eb63242 Author: agrieve <agrieve@chromium.org> Date: Wed May 03 18:41:04 2017 supersize: Tweak diff symbol matching for generated symbols E.g. CSWTCH.61 and CSWTCH.62 will now match as long as they are in the same object file. BUG= 708865 , 717550 Review-Url: https://codereview.chromium.org/2857153002 Cr-Commit-Position: refs/heads/master@{#469045} [modify] https://crrev.com/47f9431d5a69ae9e81faa6472d8b5a188eb63242/tools/binary_size/libsupersize/diff.py [modify] https://crrev.com/47f9431d5a69ae9e81faa6472d8b5a188eb63242/tools/binary_size/libsupersize/integration_test.py [modify] https://crrev.com/47f9431d5a69ae9e81faa6472d8b5a188eb63242/tools/binary_size/libsupersize/models.py
,
May 8 2017
More examples in bug 718888 . Some names found in the diff: + 10622) 4733437 (1900.8%) b@0x72ea7b0 168 /tmp/lto-llvm-2a2aff.o _ZN10extensionsL9g_factoryE.303474 + 10623) 4733437 (1900.8%) b@0x72ea860 172 /tmp/lto-llvm-2a2aff.o _ZN10extensionsL9g_factoryE.303498 + 10624) 4733437 (1900.8%) b@0x72ea978 4 /tmp/lto-llvm-2a2aff.o _ZZN12_GLOBAL__N_16GetKeyEvE9table_key.303731 + 10625) 4733437 (1900.8%) b@0x72eda50 8 /tmp/lto-llvm-2a2aff.o GetCoeffs.316376 + 10626) 4733437 (1900.8%) b@0x72ee734 4 /tmp/lto-llvm-2a2aff.o _ZN3gin12_GLOBAL__N_114g_wrapper_infoE.319492 + 10627) 4733437 (1900.8%) b@0x72f33e0 8 /tmp/lto-llvm-2a2aff.o _ZN5blinkL14g_constructorsE.345637 + 10628) 4733437 (1900.8%) b@0x72f4b80 16 /tmp/lto-llvm-2a2aff.o xsltTimestamp.startup + 10629) 4733437 (1900.8%) b@0x72f4b90 1001 /tmp/lto-llvm-2a2aff.o pretty_templ_match.dst + 10630) 4733437 (1900.8%) b@0x72f4f80 1 /tmp/lto-llvm-2a2aff.o xsltGenerateIdFunction.base_address + 10631) 4733437 (1900.8%) b@0x72f5440 778 /tmp/lto-llvm-2a2aff.o clip1.351274 - 10632) 4733365 (1900.7%) d@0x6d66ca0 -72 /tmp/lto-llvm-ec8278.o .L_ZTCN5blink22HTMLViewSourceDocumentE0_NS_12HTMLDocumentE.2 - 10633) 4733269 (1900.7%) d@0x6d66cf0 -96 /tmp/lto-llvm-ec8278.o .L_ZTCN5blink22HTMLViewSourceDocumentE0_NS_12HTMLDocumentE.3 - 10634) 4733197 (1900.7%) d@0x6d66d50 -72 /tmp/lto-llvm-ec8278.o .L_ZTCN5blink22HTMLViewSourceDocumentE0_NS_12HTMLDocumentE.4 - 10635) 4733187 (1900.7%) r@0x662a433 -10 /tmp/lto-llvm-ec8278.o _ZN12_GLOBAL__N_1L13kExpiresInKeyE.10011 - 10636) 4733155 (1900.7%) d@0x6d38db0 -32 /tmp/lto-llvm-ec8278.o .L_ZTVN12v8_inspector8protocol14DispatcherBase8CallbackE.0 From the above: - .L_ sometime exists, sometimes does not. - .### suffix often exists, and seems to break name demangling - .dst and .base_address looks suspicious. Maybe added by lto. - Object paths have a hash in them, but what is the hash of?
,
May 8 2017
Minor correction: .L is the prefix, not .L_
,
May 9 2017
,
May 12 2017
Another thing to fix here: there isn't a good way to detect the --tool-prefix to use for Linux since we don't record it anywhere (in Android we currently use $OUT/build_vars.txt). We should probably start recording this, and change the name to buildargs.properties.
,
May 15 2017
,
May 16 2017
Adding a couple of other things we need to fix (that may or may not be related): 1) Hitting "nm: *.o: File format not recognized" * Tried passing --tool-prefix third_party/binutils/Linux_x64/Release/bin/ and still hit the same error 2) Hitting "ELF file and .map file do not agree on section sizes."
,
May 17 2017
Part of c8 was wrong because I didn't realize my map file was stale. Going to close this bug out as obsolete and track work at issue 723798 .
,
May 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0f24feacbffe77af7d69f64e739c73d834fa19b4 commit 0f24feacbffe77af7d69f64e739c73d834fa19b4 Author: estevenson <estevenson@chromium.org> Date: Thu May 18 16:17:42 2017 Use a GN arg for controlling linker map file generation. Map files aren't generated on Linux by default now that linker map file generation is hooked into !use_lld ( https://crbug.com/716209 ). This CL adds a GN arg, enable_linker_map, that defaults to true for Android and makes it easy to generate map files on Linux. BUG= 717550 , 716209 Review-Url: https://codereview.chromium.org/2888623003 Cr-Commit-Position: refs/heads/master@{#472834} [modify] https://crrev.com/0f24feacbffe77af7d69f64e739c73d834fa19b4/build/toolchain/gcc_toolchain.gni [modify] https://crrev.com/0f24feacbffe77af7d69f64e739c73d834fa19b4/build/toolchain/toolchain.gni [modify] https://crrev.com/0f24feacbffe77af7d69f64e739c73d834fa19b4/tools/binary_size/diagnose_bloat.py |
||||
►
Sign in to add a comment |
||||
Comment 1 by agrieve@chromium.org
, May 3 2017