I think this may be due to my change which updated the sysroot image:

https://codereview.chromium.org/2755483002/

I am trying to confirm right now and see what the new initializer is.

+thakis, assuming it is the sysroot, how do you normally justify increasing the expectation?  Assuming we want to accept the regression do I manually change perf_expectations.json?

How can the sysroot add an initializer? And if it's really from there, can we fix instead?

We don't accept initializer regressions.

I'm was kinda assuming it was me because its quite a big change.  For example it updates the version of libstdc++.. so I was thinking it could have more subtle and far reaching effects like this.  I'm investigating now.

In the new runs I see the following lines in the output which seem inconsistent:

# Found 38 static initializers in 7 files.
...
RESULT nacl_helper-si: initializers= 8 files

In the old results:

# Found 39 static initializers in 7 files.
...
RESULT nacl_helper-si: initializers= 7 files

Yeah, I don't really understand where it got the "8 files" from... the sizes.py script (https://cs.chromium.org/chromium/build/scripts/slave/chromium/sizes.py) hasn't been changed in ages, so it's very strange for this to happen now...

So the output of dump-static-initializers.py basically remained the same (actually it was one less in the total number of initializers).

The issue is that the perf score is measured by using readelf -SW, and nothing to do with the output of dump-static-initializers.py.

The size of the init_array did grow by 8 bytes.  I'll attach both binaries if anyone is good an debugging this kind of thing help would be appreciated.

In the mean time the change as been reverted.

Thanks for investigating! This is a bit tricky and confusing. I wonder what we'll do when we reland the change? Will we have to update the perf expectations or the sizes script?

Looks like this is related to changes to crtbegin.* objects in the sysroot.  These objects got updated from 4.6 to 4.8.

By picking apart the contents of the .init_array section I found that the jessie version contains the following:

0000000000034ac0 frame_dummy
0000000000034700 _GLOBAL__sub_I_atomicops_internals_x86.cc
0000000000034800 _GLOBAL__sub_I_spinlock.cc
0000000000034820 _GLOBAL__sub_I_spinlock_internal.cc
00000000000348a0 _GLOBAL__sub_I_debugallocation_shim.cc
00000000000348b0 _GLOBAL__sub_I_memory_region_map.cc
00000000000348f0 _GLOBAL__sub_I_ic.cc
0000000000034920 _GLOBAL__sub_I_atomicops_internals_x86_gcc.cc

The difference is that frame_dummy is added to the beginning on the list.  I imagine something changed in gcc to do with frame_dummy and I will continue to investigate, but it looks like this isn't actually a new static constructor being added.

Adding mcgrathr@ who i'm sure will know these details.

I imagine the conclusion will be to update sizes.py to take frame_dummy into account in some way when counting initializers. 

The new crtbegin.o uses .init_array to get frame_dummy called, while the old one used the .init section.  There has been no change to the number of initialization functions that get called.  It's just that the one always called by every binary is now done in a way that is visible to the sizes.py script whereas before it was there but did not get counted.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/55844bc1348ddf628a1559a2ed4532fe6f614478

commit 55844bc1348ddf628a1559a2ed4532fe6f614478
Author: sbc <sbc@chromium.org>
Date: Wed Mar 22 18:21:59 2017

Update linux static initializer check in sizes.py

Newer versions of gcc put "frame_dummy" in the .init_array
when it was previously called from _init.  Since sizes.py
uses the size of the .init_array to determine the number
of static initializers we need to take this extra element
into account.

BUG= 701478 

Review-Url: https://codereview.chromium.org/2765983002
Cr-Commit-Position: refs/heads/master@{#458807}

[modify] https://crrev.com/55844bc1348ddf628a1559a2ed4532fe6f614478/infra/scripts/legacy/scripts/slave/chromium/sizes.py