Pythran stories - mozilla

A Hidden Weakness

2025-05-29T00:00:00+02:00

This is the story of a bug hunt that lasted much longer than expected, but ended with the dearest of all treasures: knowledge.

Let's draw some context: the Android platform defines different API levels. Unsurprisingly, some symbols are only defined starting with a given API version. For instance, ASystemFontIterator_open is only available starting at API 29.

Unconditionally trying to use ASystemFontIterator_open while targeting an API older than 29 leads to a linker error (an undefined reference), which makes sense because the symbol, well, does not exist at that API level.

So a native application that wants to use this symbol can either refuse to run on older API, or use a combination of dlopen and dlsym to dynamically lookup for the symbol and provide a fallback if it does not exist. The latter approach is used on Fenix, the Android version of Firefox.

Introducing `__ANDROID_UNAVAILABLE_SYMBOLS_ARE_WEAK__`

As an alternative to the features from <dlfcn.h>, Android build system makes it possible to define -D__ANDROID_UNAVAILABLE_SYMBOLS_ARE_WEAK__, combine it with a compiler check through -Werror=unguarded-availability and a runtime check through __builtin_available. Here is an example:

// The header that defines ASystemFontIterator_open.
#include <android/system_fonts.h>

...

// Runtime check for API level
if (__builtin_available(android 29, *)) {
    /* Reference to the actual symbol. Does not fail at link time because an
       alternative weak definition is always provided by <android/system_fonts.h>*/
    auto *iterator = ASystemFontIterator_open();
    ...
}

There's a lot happening there, so let's dive in the wilderness of compiler extensions.

`<android/system_fonts.h>`

ASystemFontIterator_open is defined in <android/system_fonts.h> as:

ASystemFontIterator* _Nullable ASystemFontIterator_open() __INTRODUCED_IN(29);

The _Nullable attribute is an interesting topic, but it's a side quest we're not going to explore today. The macro function __INTRODUCED_IN(...) is defined in <android/versioning.h> as:

#define __INTRODUCED_IN(api_level) __BIONIC_AVAILABILITY(introduced=api_level)

And __BIONIC_AVAILABILITY is conditionally defined in the same header as:

#if defined(__ANDROID_UNAVAILABLE_SYMBOLS_ARE_WEAK__)
  #define __BIONIC_AVAILABILITY(__what, ...) __attribute__((__availability__(android,__what __VA_OPT__(,) __VA_ARGS__)))
#else
  #define __BIONIC_AVAILABILITY(__what, ...) __attribute__((__availability__(android,strict,__what __VA_OPT__(,) __VA_ARGS__)))
#endif

So in our case ASystemFontIterator_open is flagged either with __attribute__((__availability__(android,introduced=29)) or __attribute__((__availability__(android,strict,introduced=29)).

Let's write a simple C code containing only the following:

$ cat > a.c << EOF
void foo(void) __attribute__((__availability__(android,introduced=29)));
void bar(void) __attribute__((__availability__(android,strict,introduced=29)));
void foobar(void) {
  foo();
  bar();
}
EOF

Compile and inspect it:

$ clang --target=x86_64-linux-android21 -c a.c
a.c:5:3: error: 'bar' is unavailable: introduced in Android 29 android
    5 |   bar();
      |   ^
a.c:2:6: note: 'bar' has been explicitly marked unavailable here
    2 | void bar(void) __attribute__((__availability__(android,strict,introduced=29)));
      |      ^
1 error generated.

ok, so the strict keyword implies a compilation error if we reference that symbol while targeting a lower version. Good. Let's remove it:

$ cat > b.c << EOF
void foo(void) __attribute__((__availability__(android,introduced=29)));
void foobar(void) {
  foo();
}
EOF
$ clang --target=x86_64-linux-android21 -c b.c
$ nm b.o
                 w foo
0000000000000000 T foobar
$ readelf -s b.o

Symbol table '.symtab' contains 5 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS b.c
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    2 .text
     3: 0000000000000000    11 FUNC    GLOBAL DEFAULT    2 foobar
     4: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND foo

No compilation error, even though the symbol foo is marked as available only for more recent API. Instead we end up with a symbol foo marked as WEAK (w) and UND (for undefined). Calling this symbol is equivalent to dereferencing a nullptr and ends up with a segfault. Not super safe!

`-Werror=unguarded-availability`

Fortunately, Clang provides a dedicated warning -Wungarded-availability, turned into an error through -Werror=unguarded-availability. This flag enables static checking for calls that would resolve into calling undefined weak reference because of an __availability__ mismatch.

Indeed in our case:

$ clang --target=x86_64-linux-android21 -c b.c -Werror=unguarded-availability
b.c:3:3: error: 'foo' is only available on Android 29 or newer [-Werror,-Wunguarded-availability]
    3 |   foo();
      |   ^~~
b.c:1:6: note: 'foo' has been marked as being introduced in Android 29 here, but the deployment target is Android 21
    1 | void foo(void) __attribute__((__availability__(android,introduced=29)));
      |      ^
b.c:3:3: note: enclose 'foo' in a __builtin_available check to silence this warning
    3 |   foo();
      |   ^~~
1 error generated.

Let's follow the compiler hint and guard our execution:

$ cat > c.c << EOF
void foo(void) __attribute__((__availability__(android,introduced=29)));
void foobar(void) {
  if (__builtin_available(android 29, *))
    foo();
}
EOF
$ clang --target=x86_64-linux-android21 -c c.c -Werror=unguarded-availability

No error, and indeed a guard is generated, as shown by the intermediate compiler representation:

$ clang --target=x86_64-linux-android21 -S -emit-llvm c.c -Werror=unguarded-availability
...
define dso_local void @foobar() #0 {
  %1 = call i32 @__isOSVersionAtLeast(i32 29, i32 0, i32 0) #2
  %2 = icmp ne i32 %1, 0
  br i1 %2, label %3, label %4

3:                                                ; preds = %0
  call void @foo()
  br label %4

4:                                                ; preds = %3, %0
  ret void
}

The function __isOSVersionAtLeast is part of the compiler runtime and its implementation performs a costly check at first call, memoize the result and then just reads the memoized result, which is quite fast.

The Actual Quest

This was a long detour before we reach our archenemy: the Firefox build system. In a situation similar to the one described above, we indeed end up with a weak symbol for ASystemFontIterator_open in the object file, but when creating a shared library, the symbol is just marked as undefined, and on system with recent API, the __isOSVersionAtLeast check passes but the guarded symbol is undefined and everything went kaboom.

I'll spare you the detail I took to verify that the libandroid.so we use is the right one, it has the right symbol which should supersedes the weak definition of ASystemFontIterator_open if it were marked as weak, but because it's marked undefined, it's just not there. Why would that happen?

Then I carefully compared the symbols between my object file from the Firefox build system, and the one from my minimal reproducer above. And I ended up with these two lines:

0000000000000000     0 NOTYPE  WEAK   HIDDEN   UND ASystemFontIterator_open

0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND foo

They look the same. But, wait, HIDDEN? Why would, ASystemFontIterator_open, a symbol that comes from a system header, be marked as HIDDEN? I quickly double-checked and there was no -fvisibility=hidden on the compiler invocation.

But there was something else.

A simple flag that looked innocent.

-include config/gcc_hidden.h

And in that very single file:

$ cat config/gcc_hidden.h
/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */

/* Begin all files as hidden visibility */
#pragma GCC visibility push(hidden)

Et voilà, Firefox defaults to building with hidden visibility, this impacts the weak symbols generated as a consequence of __attribute__((__availability__(android,introduced=29))) and we can indeed reproduce the issue:

$ cat > d.c << EOF
#pragma GCC visibility push(hidden)
void foo(void) __attribute__((__availability__(android,introduced=29)));
void foobar(void) {
  foo();
}
EOF
$ clang --target=x86_64-linux-android21 -c d.c
$ readelf -s d.o | grep -E '\<foo\>'
4: 0000000000000000     0 NOTYPE  WEAK   HIDDEN   UND foo
$ clang -shared d.o -o libfoo.so
$ nm libfoo.so | grep -E '\<foo\>'
$ objdump -S libfoo.so
...
0000000000000320 <foobar>:
 320:        55                      push   %rbp
 321:        48 89 e5                mov    %rsp,%rbp
 324:        e8 d7 fc ff ff          call   0 <_init-0x224>
 329:        5d                      pop    %rbp
 32a:        c3                      ret
...

the call to foo got turned into a call to 0. Even on more recent platforms, a 0 stays a 0, the weak reference trick no longer works.

The Fix

As usual, the fix is very small, compared to the amount of work required to find it. In our case we can temporarily change the default visibility when including android system headers, as in:

#pragma GCC visibility push(default)
#include <android/system_fonts.h>
#pragma GCC visibility pop

As it's often the case, the journey is the real reward. But getting Bug 1966309 fixed is also not bad ;-)

Acknowledgments

Thanks goes to Olivia Hall for providing initial help with Android platform details.

Trivial Auto Var Init Experiments

2023-12-19T00:00:00+01:00

-ftrivial-auto-var-init=[pattern|zero|uninitialized] is a compiler flag that controls how the stack is initialized before any value is initialized to it. The default is uninitialized: no initialisation is done, reading from an uninitialized location of the stack yields whatever value lies there at that point. This is Undefined Behavior in both C and C++. It makes stack allocation a O(1) operation, which is nice, but it also is (a) a common source of programming errors (b) a potential security issue.

As a countermeasure, the modes pattern and zero have been introduced. The former sets stack slots to hard-coded patterns, depending on the type (integral, floating point, pointer…) of the associated stack-allocated variables, the latter justs sets the stack to zero. Both operation make stack allocation a O(n) operation. The idea between the two modes is that setting stack slots to zero is faster, but setting them to a pattern is more likely to exhibit failing behavior.

Comparing the Approach with Address Sanitizer

Let's consider a very simple program that reads data from stdin and dumps it to stdout, using a small buffer.

#include <stdio.h>

int main() {
  char buffer[2048];
  size_t n;
  do {
    n = fread(buffer, 1, sizeof(buffer), stdin);
    fwrite(buffer, 1, n , stdout);
  } while(n);
  return 0;
}

When compiled with clang -O2 -S -emit-llvm -o- the function entry block, expressed in LLVM IR, is:

%1 = alloca [2048 x i8], align 16
call void @llvm.lifetime.start.p0(i64 2048, ptr nonnull %1) #3
br label %2

The first instruction allocates memory on the stack, and that's it.

If we compile it with clang -O2 -S -emit-llvm -o- -ftrivial-auto-var-init=zero, the prologue becomes (note the extra llvm.memset to zero):

%1 = alloca [2048 x i8], align 16
call void @llvm.lifetime.start.p0(i64 2048, ptr nonnull %1) #4
call void @llvm.memset.p0.i64(ptr noundef nonnull align 16 dereferenceable(2048) %1, i8 0, i64 2048, i1 false), !annotation !3
br label %2

When passing -ftrivial-auto-var-init=pattern we keep the llvm.memset, but zero has been turned into a pattern (0xAA):

%1 = alloca [2048 x i8], align 16
call void @llvm.lifetime.start.p0(i64 2048, ptr nonnull %1) #4
call void @llvm.memset.p0.i64(ptr noundef nonnull align 16 dereferenceable(2048) %1, i8 -86, i64 2048, i1 false), !annotation !3
br label %2

In both cases, the llvm.memset call is annotated with some metadata that help tracking its origin.

!3 = !{!"auto-init"}

The call to llvm.memset is directly followed by a call to fread that may only partially write the buffer, so there is no way for the compiler to get rid of it, even if the subsequent fwrite will never access uninitialized slots.

An important point is that on that particular code, -ftrivial-auto-var-init=zero/default doesn't have any other impact on the code. In particular no memory read or write is being instrumented.

By contrast, using -fsanitize=memory leads to the following function prologue, that contains both a memset of the whole buffer and the xoring of every loaded address with 87960930222080 (actually 0x500000000000). So it's strictly slower, especially as it impacts elements of the inner loop (whenever stdout and stdin are loaded in memory.

  %buffer = alloca [2048 x i8], align 16
  call void @llvm.lifetime.start.p0(i64 2048, ptr nonnull %buffer) #5
  %0 = ptrtoint ptr %buffer to i64
  %1 = xor i64 %0, 87960930222080
  %2 = inttoptr i64 %1 to ptr
  call void @llvm.memset.p0.i64(ptr noundef nonnull align 16 dereferenceable(2048) %2, i8 -1, i64 2048, i1 false)
  %_msld = load i64, ptr inttoptr (i64 xor (i64 ptrtoint (ptr @stdin to i64), i64 87960930222080) to ptr), align 8
  %_mscmp17.not = icmp eq i64 %_msld, 0
  br i1 %_mscmp17.not, label %4, label %3, !prof !3
3:
  call void @__msan_warning_noreturn() #6
  unreachable
4:
  %5 = load ptr, ptr @stdin, align 8, !tbaa !4
  %call6 = call noundef i64 @fread(ptr noundef nonnull %buffer, i64 noundef 1, i64 noundef 2048, ptr noundef %5)
  %cmp7 = icmp eq i64 %call6, 2048
  br i1 %cmp7, label %while.body, label %while.end

Compiler Optimization

The astute reader would have noticed that in the original C code, there were two stack variables: buffer and n. Looking at the output of clang without optimization, we can see both being allocated and initialized in the function prologue

%1 = alloca i32, align 4
%2 = alloca [2048 x i8], align 16
%3 = alloca i64, align 8
store i32 0, ptr %1, align 4
call void @llvm.memset.p0.i64(ptr align 16 %2, i8 -86, i64 2048, i1 false), !annotation !4
store i64 -6148914691236517206, ptr %3, align 8, !annotation !4
br label %4

The store is being optimized out by the compiler (thanks to a following write) to save the result of fread. That's great news! It means that the front-end compiler (here Clang) can generate initialisation for every stack variable, and let the optimizer (here LLVM) get rid of the redundant initialisation.

Lowering

When generating assembly code from the LLVM IR, the compiler faces a lot of choices, one of which being «should I turn a call to llvm.memset into a block of instructions, or into a call to libc's memset?». For large buffer it chooses the latter, but were the buffer smaller, a bunch of mov (or movaps, you get the idea) would be generated instead.

Evaluating Using `-ftrivial-auto-var-init=xxxx` on Firefox

As a security-hardening flag, -ftrivial-auto-var-init=xxxx has been considered as a default flag to build Firefox. But as noted above, it (may) have an impact on runtime performance. In here, we will focus on the impact on shippable Firefox Linux when running the Speedometer3 benchmark.

Following table summarizes the result we get with the three setups, on three different desktop targets (actual details are available for the pattern setting and for the zero setting.

Speedometer3 results dependeing on -ftrivial-auto-var-init setting
platform	default	pattern	zero
linux64	8.97	8.82	8.87
osx10-64	12.05	11.95	12.01
win10-64	12.64	12.46	12.47

A 1% regression on performance is not a trade off we are ready to make anytime soon. Can we do better?

Spotting the culprit

LLVM has a reporting mechanism that helps tracking down the behavior of the optimizer. In particular, it can report any instruction that ends up with an !{!"auto-init"} annotation at the end of the optimization pipeline, using the -Rpass-missed=annotation-remarks flag. On our toy example from the first section, we get:

$ clang cat.c -O2 -S -o- -ftrivial-auto-var-init=zero -Rpass-missed=annotation-remarks
cat.c:4:8: remark: Call to memset inserted by -ftrivial-auto-var-init. Memory operation size: 2048 bytes.
 Written Variables: <unknown> (2048 bytes). [-Rpass-missed=annotation-remarks]

That's pretty nice to spot inserted instructions that end up not being optimized, but as one can expect from a codebase as large as Firefox's, it generates too much information.

Fortunately we can combine this with profile information, through -fdiagnostics-hotness-threshold=auto, to sort out the most impactful insertion, and analyze the result.

So the methodology becomes:

Compile Firefox with -ftrivial-auto-var-init=zero and -fprofile-generate.
Train Firefox on Speedometer3 to gather profile information.
Recompile Firefox with -ftrivial-auto-var-init=zero, -fprofile-use, -Rpass-missed=annotation-remarks and -fdiagnostics-hotness-threshold=auto, logging the result.
Do something smart (?) with the result.

Applied to our toy program, this summarizes into:

$ clang cat.c -O2 -o cat.generate -ftrivial-auto-var-init=zero -fprofile-generate
$ ./cat.generate < cat.c
$ llvm-profdata merge *.profraw -o merged.profdata
$ clang cat.c -O2 -o cat.generate -ftrivial-auto-var-init=zero -fprofile-use=merged.profdata -Rpass-missed=annotation-remarks -fdiagnostics-hotness-threshold=auto
cat.c:4:8: remark: Call to memset inserted by -ftrivial-auto-var-init. Memory operation size: 2048 bytes.
 Written Variables: <unknown> (2048 bytes). (hotness: 1) [-Rpass-missed=annotation-remarks]
     4 |   char buffer[2048];
       |        ^

When applying the above to Firefox, we spotted a few recurring situation I'm going to cover in the following section.

Recurring Nightmare

Bonus point if you get the reference to the MTG emblematic card.

SmallVector and Friends

It is a common optimization to provide data types that preallocates some memory, aiming at stack allocation, and switching to heap allocation depending on the usage. In the LLVM codebase those are SmallVector, SmallString, SmallPtrSet etc. Similar performance-oriented data structures can be found in the Firefox codebase in the form of nsAutoCString or AutoTArray. These data types provide an interesting challenge wrt. trivial auto var init: they typically are performance oriented data structure whose buffer is not going to be used right away. It is very unlikely that the compiler can optimize out the initialization of this buffer! Consider the following:

// copy a C string into a nsAutoCStringN
nsAutoCStringN<128> line(buffer.c_str());

Depending on the runtime size of buffer, the pre-allocated buffer of line is going to be either partially filled, totally filled or unused in favor of stack allocation. Only in the second case is it valid to get rid of the full initialization... And there is no way the compiler could handle that statically.

In some cases it is possible to avoid using these data structures (see Bug 1850948)

Initialization within a Loop

It is quite common to declare stack variables to the stricter scope needed. It improves locality (from a code review point of view) and it avoids exposing variable content to other code portion. However, the interaction with -ftrivial-auto-var-init is not negligible. Consider the following code that reads info from /proc/self/maps:

while (std::getline(maps, line)) {
  [...]
  char modulePath[PATH_MAX + 1] = "";
  ret = sscanf(line.c_str(),
                 "%lx-%lx %6s %lx %*s %*x %" PATH_MAX_STRING(PATH_MAX)
                 "s\n",
                 &start, &end, perm, &offset, modulePath);
  [...]
}

-ftrivial-auto-var-init has the (expected!) effect of adding a memset inside the loop, to initialize modulePath. The allocation itself is going to be moved in the function prologue, but not the initialisation. This turns a O(1) instruction into a O(n×m) one, where n is the size of the buffer and m is the number of loop iteration. Not ideal.

The trivial (but manual) fix here is to rewrite the code as follow:

char modulePath[PATH_MAX + 1];
while (std::getline(maps, line)) {
  [...]
  modulePath[0] = 0;
  ret = sscanf(line.c_str(),
                 "%lx-%lx %6s %lx %*s %*x %" PATH_MAX_STRING(PATH_MAX)
                 "s\n",
                 &start, &end, perm, &offset, modulePath);
  [...]
}

This is not strictly equivalent though: if the loop is never entered, we still pay for one initialisation, and the k^th iteration can see the content of previous iteration's buffer. We applied a similar patch for Bug 1850951

Empty Class

Every object that may have its address taken must have a size of at least one byte. Even if it doesn't have any members. That would be the case of the following class:

#include <cstdio>
struct Holder {
    Holder() { puts("enter"); }
    ~Holder() { puts("exit"); }
    void log() const;
};
void foo() {
    Holder h;
    h.log();
}

Now let's imagine the compiler doesn't have access to Holder::log() implementation. Or maybe it has access to it but it cannot inline it. Because it is a member function, it takes an (implicit) reference to this as first parameter. So the address of the object is taken. So its size becomes one, and -ftrivial-auto-var-init makes sure this padding byte is initialized. After all, that's stack memory! Here is the LLVM bitcode output by the compiler from the above snippet after clang++ -S -emit-llvm -O2 -ftrivial-auto-var-init=pattern -o- a.cpp -fno-exceptions (passing -fno-exceptions just to avoid the extra clutter). We can see the extra store i8 -86, ptr %1, align 1, !annotation !3 that's not wanted, and the ptr noundef nonnull align 1 dereferenceable(1) %1 as first parameter of call void @_ZNK6Holder3logEv, i.e. void @Holder::log() const.

define dso_local void @_Z3foov() local_unnamed_addr #0 {
  %1 = alloca %struct.Holder, align 1
  call void @llvm.lifetime.start.p0(i64 1, ptr nonnull %1) #4
  store i8 -86, ptr %1, align 1, !annotation !3
  %2 = tail call i32 @puts(ptr noundef nonnull dereferenceable(1) @.str)
  call void @_ZNK6Holder3logEv(ptr noundef nonnull align 1 dereferenceable(1) %1) #4
  %3 = call i32 @puts(ptr noundef nonnull dereferenceable(1) @.str.1)
  call void @llvm.lifetime.end.p0(i64 1, ptr nonnull %1) #4
  ret void
}

Can we help the compiler there? Actually we can, by informing it that Holder::log doesn't need any reference to this, while preventing it to be called without object attached:

#include <cstdio>
struct Holder {
    Holder() { puts("enter"); }
    ~Holder() { puts("exit"); }
    void log() const { return log_impl(); }
    private:
    static void log_impl();
};
void foo() {
    Holder h;
    h.log();
}

gets compiled into the expected:

define dso_local void @_Z3foov() local_unnamed_addr #0 {
  %1 = tail call i32 @puts(ptr noundef nonnull dereferenceable(1) @.str)
  tail call void @_ZN6Holder8log_implEv() #3
  %2 = tail call i32 @puts(ptr noundef nonnull dereferenceable(1) @.str.1)
  ret void

This approach has been used in Bug 1844520.

Manual Check

At some point in the process, I decided to flag the top 100 variables reported as initialized and hot with the attribute __attribute__((uninitialized)), which has the effect of preventing any extra initialisation code to be inserted by -ftrivial-auto-var-init. I was very hopeful with that approach, as I was expecting this attribute to significantly decrease the impact of auto-initialisation on performance. Unfortunately the opposite happened: almost no speed improvement. This tells us that the performance impact is not due to a few hotspot but spread across the whole codebase. So the whole idea of handling every situation one after the other is unlikely to be enough! How depressing.

Let's still have a look at a final situation.

Value Semantic

Maybe as an inheritance of C, maybe as an inheritance of C++98, we often see interfaces that use pass-by-reference as a way to return extra values. For instance in the following code doStuff returns false in case of error, and true and sets result in case of success.

#include <cstdio>
bool doStuff(char*& result);
void foo() {
  char* res;
  if(doStuff(res))
    puts(res);
}

From the compiler point of view, there is no guarantee that res has been initialized with doStuff. And doing so would mean being able to couple value and control-flow, something compilers are not always very good at.

I've asked myself how we could inform the compiler about this behavior. It turns out LLVM does have attribute to specify interaction of parameters wrt. memory, through memory(...). For instance, according to the language reference one can use memory(argmem: read, inaccessiblemem: write) to specify that

May only read argument memory and only write inaccessible memory.

But there is no way to state that the function must write to the location. And even with that piece of information, we would have to state the write is only done if the return value is true.

One option though would be to return an std::optional. In that case the problem of initializing the return value is deferred to std::optional. In turn std::optional needs to initialize its inner members, so we're only moving the problem.

This is, however, quite close to the situation we had with data structures that preallocate memory: no normal usage of the data structure should lead to an access of the uninitialized memory, and those data structures are critical enough to trade security for performance. What about flagging them with a specific attribute that would bypass the trivial initialisation mechanism? I actually submitted a patch to implement that, only to realize that the right approach would be to allow setting the attribute on class members, which turns out to be trickier than expected. But if we could do this, we would impact the whole codebase by only adding a few attributes, which is much more rewarding than mechanically tracking hotspots.

Concluding Words

So in the end, there was no straight-forward fix to prevent the performance regression caused by -ftrivial-auto-var-init, and Firefox is probably not going to move there anytime soon. How disappointing?

But let's be positive! In the process of trying to decrease the performance impact of -ftrivial-auto-var-init on Firefox codebase, I grabbed a better understanding of the original problem and how clang approaches it. I also came up with a methodology to track the performance impact and iteratively improve the situation. And I shared that knowledge with you, and there is value in it, isn't there?

Acknowledgments

The author would like to thank Frederik Braun , Tom Ritter, Sylvestre Ledru and Tyson Smith for the proofreading of this post and the fruitful discussion we've been having on that topic.

-Wglobal-constructors

2023-10-02T23:00:00+02:00

#include <iostream>
#include <unordered_set>
#include <string>

const std::unordered_set<std::string> primary_colors = {"red", "green", "blue"};

int main(int argc, char const ** argv) {
    char const * color = argc > 1 ? argv[1] : "pink";
    return primary_colors.count(color) ? 0 : 1;
}

Let's compile and run the snippet above:

$ clang++ --version
clang version 14.0.5 (Fedora 14.0.5-2.fc36)
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ clang++ colors.cpp -O2 -o colors && ./colors green && echo ok
ok

Let's be a bit more pedantic and turn all warnings on:

$ clang++ colors.cpp -Wall -O2 -o colors && ./colors green && echo ok
ok

No, I meant really pedantic (so that you don't waste your time trying: -pedantic doesn't find anything else)

$ clang++ colors.cpp -Weverything -O2 -o colors && ./colors green && echo ok
 colors.cpp:5:56: warning: initialization of initializer_list object is incompatible with C++98 [-Wc++98-compat]
 const std::unordered_set<std::string> primary_colors = {"red", "green", "blue"};
                                                        ^~~~~~~~~~~~~~~~~~~~~~~~
 colors.cpp:5:39: warning: declaration requires an exit-time destructor [-Wexit-time-destructors]
 const std::unordered_set<std::string> primary_colors = {"red", "green", "blue"};
                                       ^
 colors.cpp:5:39: warning: declaration requires a global destructor [-Wglobal-constructors]
 3 warnings generated.
 ok

Now that's what I needed for my intro: -Wglobal-constructors (let's forget about C++98, right?). -Wexit-time-destructors is a subset of -Wglobal-constructors, so let's focus on global constructors.

Indeed we are creating a const unordered set named colors, but the initialization code has to happen at some point. None of its constructors is flagged as constexpr so the initialization happens at startup, before the call to the main function.

Why is it worth a warning? The clang manual is not very talkative on the subject, and the commit introducing the feature is not super helpful either, but it's getting better. We can guess the reasons: it can cause bugs (think Static Initialization Order Fiasco) and performance problems (increased startup time).

Warming up

The variable colors is a set that doesn't change in size after initialization. Back in the days I designed a small header-only C++ library called frozen that provides à la Python frozen containers that match the standard library interface, let's use this:

#include <iostream>
#include <cstring>
#include "frozen/unordered_set.h"
#include "frozen/string.h"

using namespace frozen::string_literals;

constexpr frozen::unordered_set<frozen::string, 3> primary_colors = {"red"_s, "green"_s, "blue"_s};

int main(int argc, char const ** argv) {
  frozen::string color = argc > 1 ? frozen::string(argv[1], std::strlen(argv[1])) : "pink"_s;
    return primary_colors.count(color) ? 0 : 1;
}

Changing a few namespaces, swapping a few headers and add some string literals and a container size, and we're done:

$ clang++ frozen_colors.cpp -Wall -Wglobal-constructors -O2 -o frozen_colors && ./frozen_colors green && echo ok
ok

Great! No warning, job done! Job done? Let's double check the binary and run:

$ nm -C frozen_colors | grep _GLOBAL__
0000000000401070 t _GLOBAL__sub_I_frozen_colors.cpp

That's a bit suspicious, let's have a look at this symbol:

$ objdump -C -S --disassemble=_GLOBAL__sub_I_frozen_colors.cpp frozen_colors
[...]
0000000000401070 <_GLOBAL__sub_I_frozen_colors.cpp>:
  401070:   50                      push   %rax
  401071:   bf 3d 40 40 00          mov    $0x40403d,%edi
  401076:   e8 d5 ff ff ff          call   401050 <std::ios_base::Init::Init()@plt>
  40107b:   bf 60 10 40 00          mov    $0x401060,%edi
  401080:   be 3d 40 40 00          mov    $0x40403d,%esi
  401085:   ba 08 20 40 00          mov    $0x402008,%edx
  40108a:   58                      pop    %rax
  40108b:   e9 b0 ff ff ff          jmp    401040 <__cxa_atexit@plt>
  [...]

Ah ah, <iostream>. The header was included out of habit in the example (totally by accident, not hand-crafted at all), and it didn't get reported by clang because it comes from a system header. Removing the useless header is indeed enough to get rid of the last global constructor of our toy program (note that we no longer have any destructor at exit either). And now that we have set the basics, let's start…

Digging Into Firefox's global constructor

There's still a lot of C++ code in Firefox's codebase. Statistically, there should be at least a dozen global constructors in it. A dozen? Hundreds! This Bug tracks the various attempt to remove some of them, the rest of this article is just a collection of the various situation in which global constructors have been successfully removed so far.

Bye bye, `<iostream>`

Using the example above, we can adopt a very simple strategy to detect all compilation units that include <iostream>:

objdump -C -d dist/bin/libxul.so > libxul.S  # cache this call as it takes a lot of time
nm -C dist/bin/libxul.so | awk '/_GLOBAL__/ { print $3 }' | while read sym ; do grep $sym libxul.S -A8 | grep -q std::ios_base::Init && echo $sym; done

Then depending on the situation, we can decide what to do with the headers:

Keep it. Required if std::cout or std::cerr (or std::clog!) are used
Replace it by <istream> or <ostream>, when only that part of the API is needed, typically when only std::ostream or std::istream are used.
Remove it. This header is often included for debugging purpose and one forgets to remove it. Including myself ;-)

I've done so in Bug 1855955, but also in Bug 1854575 which was very satisfying because it removed the include from a google protobuf file, which was included in 33 compilation units! The patch also got accepted in the upstream protobuf repo.

Let it go, `<frozen/*.h>`

It is very common to have small hash tables to store data mapping, and the Firefox codebase typically have those:

storing mapping between string and enums, a very common pattern;
storing an allow list (well, of a single element…)
storing an array with a lot of holes as a map which is more memory efficient.

All these commits have not landed yet, but I'm very happy to revive this classic I developed 5 years ago.

Hello, `constexpr`

The firefox code base uses C++17, so constinit is not a thing, but constexpr variables must be immediately initialized which implies no global constructor.

Sometimes, just setting the constructor and/or the declaration as constexpr is enough. Easy!

Many time the variable is a static const global std::string in the Firefox code base. They can be replaced by the internal nsLiteralCString class or by an std::string_view depending on the code they need to interact with. In both cases we save the runtime initialization of the string while keeping the nice encapsulation. We've done so in Bug 1854969 and Bug 1854490.

Special mention to Bug 563351 where making a constructor constexpr and declaring a single variable as a constexpr variable got rid of a global constructor for a static variable declared in a header, thus in all files including that header.

Bug 1854410 was somehow similar: static variables in a header. This time the object could not be made constexpr, but moving the initialization to the implementation file and having external variables decreased the overall number of duplication.

Measuring the Impact

Theoretically, these change should impact:

Code size, as the initialization code is no longer needed;
Startup time, as less code is executed at startup;
Lookup time (in the case of frozen structures) because frozen::unordered_(set|map) use perfect hashing, and frozen::(set|map) use branch-less partitioning.

Point 1. may be balanced by the increase in data size (after all, the constexpr-initialized data structure must live somewhere). It turns out that in the case of firefox, the resulting libxul.so is smaller by a dozen of kB after all the above changes.

Unfortunately, Point 2. and 3. are within the measurement noise on my setup.

Factually, those are not tremendous result, but let's not forget Point 4.: Things have been learnt in the process, and shared through this write up ;-)

Acknowledgment

Thanks to Sylvestre Ledru and Paul Adenot for proof-reading this post, and to all the reviewers of the above patches!

Shrinking a Shared Library

2023-06-23T00:00:00+02:00

Recently, I've submitted a patch that shaves ~2.5MB on one of the core Firefox library, libxul.so. The patch is remarkably simple, but it's a good opportunity to dive into some techniques to shrink binary size.

Generic Approach

We'll use the libz library from the official zlib as an example program to build. In this series, we use revision 1.2.13, sha1 04f42ceca40f73e2978b50e93806c2a18c1281fc.

The compiler used is clang 14.0.5, the linker used is lld.

Compilation Levels

Let's start with the obvious approach and explore the effect of the various optimization levels -O0, -O1, -Oz, -O2 and -O3.

The size program list section sizes and total size of binary files, that's perfectly suited to our needs. We will dive into its detailed output later.

for opt in -O0 -O1 -O2 -O3 -Oz
do
        rm -rf _build
        mkdir _build
        (cd ./_build ; LDFLAGS=-fuse-ld=lld CFLAGS=$opt CC=clang ../configure && make) 1>/dev/null
        size -A _build/libz.so | awk -v cflag=$opt '/Total/ { printf "%8s: %8d\n", cflag, $2 }'
done

Impact of optimization level on binary size for libz.so
CFLAGS	size
-O0	141608
-O1	88164
-O2	99532
-O3	101644
-Oz	81006

Unsurprisingly -Oz yields the smaller binaries. , and -O0 performs a direct translation which uses a lot of space. Performing basic optimizations as -O1 does generally lead to code shrinking because the optimized assembly is more dense, and it looks like some of the optimization added by -O2 generate more instructions (Could be the result of inlining or loop unrolling). -O3 trades even more binary size for performance (could be the result of function specialization or more aggressive inlining).

Link Time Optimization

Interestingly, using the various flavor of -flto also have an effect on the binary size:

$ LDFLAGS=-fuse-ld=lld\ -flto=full CFLAGS=-Oz\ -flto=full CC=clang ../configure && make && size -A libz.so
[...]
Total                    80971

$ LDFLAGS=-fuse-ld=lld\ -flto=full CFLAGS=-O2\ -flto=full CC=clang ../configure && make && size -A libz.so
[...]
Total                   102868

$ LDFLAGS=-fuse-ld=lld\ -flto=thin CFLAGS=-Oz\ -flto=thin CC=clang ../configure && make && size -A libz.so
[...]
Total                    82096

$ LDFLAGS=-fuse-ld=lld\ -flto=thin CFLAGS=-O2\ -flto=thin CC=clang ../configure && make && size -A libz.so
[...]
Total                   102464

Again, nothing surprising: having access to more information (through -flto=full) gives more optimization space than -flto=thin which (slightly) trades performance of the generated binary for memory usage of the actual compilation process. A trade-off we do not need to make for zlib but it's another story for big project like Firefox.

A Note on Stripping

It's very common to compile a code with debug information:

$ LDFLAGS=-fuse-ld=lld\ -flto=full CFLAGS=-Oz\ -g\ -flto=full CC=clang ../configure && make && size -A libz.so
[...]
.debug_loc               89689       0
.debug_abbrev             1716       0
.debug_info              33472       0
.debug_ranges             3744       0
.debug_str                5422       0
.debug_line              29136       0
Total                   244152

The impact of debug information on code size is significant. We can compress them using dwz for a minor gain:

$ dwz libz.so && size -A libz.so
[...]
.debug_loc               89689       0
.debug_abbrev             1728       0
.debug_info              27563       0
.debug_ranges             3744       0
.debug_str                5422       0
.debug_line              29136       0
Total                   238255

We usually do not ship debug info as part of a binary, yet we may want to keep minimal ones:

$ LDFLAGS=-fuse-ld=lld\ -flto=full CFLAGS=-Oz\ -gline-tables-only\ -flto=full CC=clang ../configure && make && size -A libz.so
[...]
Total                   113441

The usual approach though is to separate debug information from the actual binary (e.g. through objcopy --only-keep-debug) then stripping it:

$ strip libz.so && size -A libz.so
[...]
Total                   80755

It even removes some extra bytes (by shrinking the section .gnu.build.attributes)!

Specializing the Binary

For a given scenario, we may be ok with removing some of the capability of the binary in exchange for smaller binaries.

Removing `.eh_frame`

The complete result of the best setup we have (let's forget about stripping), CFLAGS=-Oz\ -flto=full, is:

$ size -A libz.so
libz.so  :
section                  size    addr
.note.gnu.build-id         24     624
.dynsym                  2616     648
.gnu.version              218    3264
.gnu.version_d            420    3484
.gnu.version_r             48    3904
.gnu.hash                 712    3952
.dynstr                  1478    4664
.rela.dyn                 768    6144
.rela.plt                1056    6912
.rodata                 17832    7968
.eh_frame_hdr            1076   25800
.eh_frame                7764   26880
.text                   44592   38752
.init                      27   83344
.fini                      13   83372
.plt                      720   83392
.data.rel.ro              352   88208
.fini_array                 8   88560
.init_array                 8   88568
.dynamic                  432   88576
.got                       32   89008
.data                       0   93136
.tm_clone_table             0   93136
.got.plt                  376   93136
.bss                        1   93512
.gnu.build.attributes     288       0
.comment                  110       0
Total                   80971

We can get rid of some bytes by removing support for stack unwinding:

$ LDFLAGS=-fuse-ld=lld\ -flto=full\ -Wl,--lto-O2 CFLAGS=-Oz\ -flto=full\ -fno-unwind-tables\ -fno-exceptions\ -fno-asynchronous-unwind-tables\ -fomit-frame-pointer CC=clang ../configure && make && size -A libz.so
[...]
libz.so  :
section                  size    addr
.note.gnu.build-id         24     624
.dynsym                  2616     648
.gnu.version              218    3264
.gnu.version_d            420    3484
.gnu.version_r             48    3904
.gnu.hash                 712    3952
.dynstr                  1478    4664
.rela.dyn                 768    6144
.rela.plt                1056    6912
.rodata                 17832    7968
.eh_frame_hdr              12   25800
.eh_frame                   4   25812
.text                   44592   29920
.init                      27   74512
.fini                      13   74540
.plt                      720   74560
.data.rel.ro              352   79376
.fini_array                 8   79728
.init_array                 8   79736
.dynamic                  432   79744
.got                       32   80176
.data                       0   84304
.tm_clone_table             0   84304
.got.plt                  376   84304
.bss                        1   84680
.gnu.build.attributes     288       0
.comment                  110       0
Total                   72147

We reduced the .eh_frame and .eh_frame_hdr sections at the expense of removing support for stack unwinding. Again, it's a trade-off but one we may want to make. Keep in mind the frame pointer and the exception frame are very helpful to debug a core file!

Specializing for a given usage

Now let's compile the example code minigzip.c (it's part of zlib source code) while linking with our shared library, and examine the used symbols:

$ clang ../test/minigzip.c -o minizip -L. -lz
$ nm minizip | grep ' U '
                 U exit@GLIBC_2.2.5
                 U fclose@GLIBC_2.2.5
                 U ferror@GLIBC_2.2.5
                 U fileno@GLIBC_2.2.5
                 U fopen@GLIBC_2.2.5
                 U fprintf@GLIBC_2.2.5
                 U fread@GLIBC_2.2.5
                 U fwrite@GLIBC_2.2.5
                 U gzclose
                 U gzdopen
                 U gzerror
                 U gzopen
                 U gzread
                 U gzwrite
                 U __libc_start_main@GLIBC_2.34
                 U perror@GLIBC_2.2.5
                 U snprintf@GLIBC_2.2.5
                 U strcmp@GLIBC_2.2.5
                 U strlen@GLIBC_2.2.5
                 U strrchr@GLIBC_2.2.5
                 U unlink@GLIBC_2.2.5

In addition to symbols from the libc, it uses a few symbols from zlib. This doesn't cover the whole zlib ABI though. Let's shrink the library just for our usage using a version script that only references the symbols we want to use:

$ cat ../zlib.map
MYZLIB_1 {
    global:
                 gzclose;
                 gzdopen;
                 gzerror;
                 gzopen;
                 gzread;
                 gzwrite;
    local:
      *;
};

And pass this to the linker:

$ LDFLAGS=-fuse-ld=lld\ -flto=full\ -Wl,--gc-sections\ -Wl,--version-script,../zlib.map CFLAGS=-Oz\ -flto=full" -fno-unwind-tables -fno-exceptions -fno-asynchronous-unwind-tables -fomit-frame-pointer -ffunction-sections -fdata-sections"  CC=clang ../configure && make placebo && size -A libz.so
[...]
libz.so  :
section                  size    addr
.note.gnu.build-id         24     624
.dynsym                   576     648
.gnu.version               48    1224
.gnu.version_d             84    1272
.gnu.version_r             48    1356
.gnu.hash                  60    1408
.dynstr                   281    1468
.rela.dyn                 528    1752
.rela.plt                 336    2280
.rodata                 15320    2624
.eh_frame_hdr              12   17944
.eh_frame                   4   17956
.init                      27   22056
.fini                      13   22084
.text                   32608   22112
.plt                      240   54720
.data.rel.ro              272   59056
.fini_array                 8   59328
.init_array                 8   59336
.dynamic                  432   59344
.got                       32   59776
.tm_clone_table             0   63904
.got.plt                  136   63904
.bss                        1   64040
.gnu.build.attributes     288       0
.comment                  110       0
Total                   51496

The linker uses the visibility information to iteratively remove code that's never referenced.

Concluding Notes

Some of the remaining sections are purely informational. For instance:

$ objdump -s -j .comment libz.so

 0000 4743433a 2028474e 55292031 322e322e  GCC: (GNU) 12.2.
 0010 31203230 32323131 32312028 52656420  1 20221121 (Red
 0020 48617420 31322e32 2e312d34 2900004c  Hat 12.2.1-4)..L
 0030 696e6b65 723a204c 4c442031 342e302e  inker: LLD 14.0.
 0040 3500636c 616e6720 76657273 696f6e20  5.clang version
 0050 31342e30 2e352028 4665646f 72612031  14.0.5 (Fedora 1
 0060 342e302e 352d322e 66633336 2900      4.0.5-2.fc36).

That's just some compiler version information, we can safely drop them:

$ objcopy -R .comment libz.s
$ size -A libz.so
[...]
Total                   51386

We could probably shave a few extra bytes, but we already came a long way ☺.

Acknowledgments

Thanks to Sylvestre Ledru and Lancelot Six for proof-reading this post. You rock!

How unity builds crept into the Firefox Build System

2023-05-03T00:00:00+02:00

Unity Build

Unity builds, a.k.a. unified build or jumbo builds, is a technique that consists in concatenating several C or C++ files in one before invoking the compiler. This generally leads to faster compilation time in part because it aggregates the cost of parsing the same headers over and over.

It is one of the many approach one can use to reduce C++ software compilation time, alongside precompiled headers and C++20 modules.

It is not an obscure technique: it's officially supported by CMake through CMAKE_UNITY_BUILD (see https://cmake.org/cmake/help/latest/variable/CMAKE_UNITY_BUILD.html).

At some point, the Chromium project supported doing jumbo builds: https://chromium.googlesource.com/chromium/src.git/+/65.0.3283.0/docs/jumbo.md, even if it got rid of it afterward https://groups.google.com/a/chromium.org/g/chromium-dev/c/DP9TQszzQLI

It is also supported by the internal build system used at Mozilla. And the speedup is there, a unified build (the default) runs twice as fast as an hybrid build (--disable-unified-build) on my setup. As a side effect, in pre-LTO area, this also led to better performance as it makes more information available to the compiler.

Wait, did I write hybrid build and not regular build? As it turns out, under --disable-unified-build some parts of Firefox are still built in unified mode, because they require it, probably for historical reason.

It's great to be able to do a unified build. It's not great to have a codebase that does not compile unless you have a unity build: static analyzers are not used to work on non-self contained sources (see https://github.com/clangd/clangd/issues/45), unity build implies a slight overhead during incremental builds. What makes it worse is that developer start to rely on unified build and get lazy in the way they develop.

Jumbo Build Creeps

In the following we assume a.cpp and b.cpp are jumbo built as

// jumbo.cpp
#include "a.cpp"
#include "b.cpp"

Let's have fun while collecting some of the cases found in the Firefox codebase while removing the unify build requirement.

Skipping includes

// a.cpp
#include <iostream>
void foo() {
  std::cout << "hello" << std::endl;
}

// b.cpp
void bar() {
  std::cout << "hello" << std::endl;
}

Indeed, why including a header when another compilation unit that comes before you in the unified build is including it?

Accessing static functions

// a.cpp
#include <iostream>
static void foo() {
  std::cout << "hello" << std::endl;
}

// b.cpp
void bar() {
  foo();
}

Isn't that a good property to be able to access a function that's meant to be private?

Trying to be smart with macro

// a.cpp
#include <iostream>
#define FOO 1

// b.cpp
#ifdef FOO
  #define BAR
#endif

Defining a macro in one compilation unit and have it affect another compilation unit has been a real nightmare.

Static templates

// a.cpp
#include <iostream>
template <typename T>
void foo(T const& arg) {
  std::cout << arg << std::endl;
}

// b.cpp
#include <iostream>
void bar(int i) {
  foo(i);
}

Isn't it great when you don't need to put your template definition in the header? Static visibility for templates :-).

Template specialization

// foobar.h
#ifndef FOOBAR_H
#define FOOBAR_H
#include <iostream>
template <typename T>
void foobar(T arg) {
  std::cout << arg << std::endl;
}
#endif

// a.cpp
#include "foobar.h"
template <>
void foobar<int>(int arg) {
  std::cout << "int: " << arg << std::endl;
}

// b.cpp
#include "foobar.h"
void bar(int i) {
  foobar(i);
}

This one is terrible, because it doesn't give any compile time error, but a runtime error :-/.

Leaking using namespace

// a.cpp
#include <iostream>
using namespace std;

void foo() {
  cout << "hello" << std::endl;
}

// b.cpp
#include <iostream>
void bar() {
  cout << "hello" << std::endl;
}

You can use symbols from namespace used from other compilation unit. That's exactly the same problem as leaking macro or static definitions: it breaks the compilation unit scope.

Putting function implementation in header

// foobar.h
#ifndef FOOBAR_H
#define FOOBAR_H
#include <iostream>
void foobar() {
  std::cout << "hello" << std::endl;
}
#endif

// a.cpp
#include "foobar.h"
void foo() {
  foobar();
}

// b.cpp
#include "foobar.h"
void bar() {
  foobar();
}

As each header is only included once, you can put your function definition in your header. Easy!

Putting constant initializer in implementation

// foobar.h
#ifndef FOOBAR_H
#define FOOBAR_H
struct foo {
static const int VALUE;
};
#endif

// a.cpp
#include "foobar.h"
const int foo::VALUE = 1;

// b.cpp
#include "foobar.h"
static_assert(foo::VALUE == 1, "ok");

The constant expression lacks its initializer.

Error about functions without a valid declarations get silented

// foobar.h
#ifndef FOOBAR_H
#define FOOBAR_H
void foo(int * ptr);
#endif

// a.cpp
#include "foobar.h"
void foo(const int * ptr) {
}

// b.cpp
#include "foobar.h"
void bar(const int * ptr) {
    return foo(ptr);
}

Invalid forward declaration but who cares, when the definition can be found and the compiler doesn't warn about unused forward declaration?

Unexpected aspect: less warnings

// a.cpp
static int foo = 0;

// b.cpp
#include "a.cpp"

Compiling a.cpp yields an unused warning, but not compiling b.cpp. So hybrid builds relying on #including multiple sources actually decrease the warning level.

Headers without include guard

// foobar.h
struct Foo {};

// a.cpp
#include "foobar.h"
void a(Foo&) {}

// b.cpp
void b(Foo&) {}

Fixing the missing include for b.cpp leads to type redefinition because the header is not guarded.

About the Firefox codebase

The removal of REQUIRES_UNIFIED_BUILD across the Firefox codebase was tracked under https://bugzilla.mozilla.org/show_bug.cgi?id=1626530. Since I focused on this, I've landed more than 150 commits, modifying more than 800 sources files. And it's now done, no more hard requirement of unified build, back to a normal situation.

Was it worth the effort? Yes: it prevents bad coding practices, and static analysis is now more useful compared to what it could do with unified builds.

And we're sure we won't regress as our CI now builds in both unified and non-unified mode!

Acknowledgments

Thanks to Paul Adenot for proof-reading this blog post and to Andi-Bogdan Postelnicu for reviewing most of the commits mentioned above.

Pythran stories - mozilla

A Hidden Weakness

Introducing __ANDROID_UNAVAILABLE_SYMBOLS_ARE_WEAK__

<android/system_fonts.h>

-Werror=unguarded-availability

The Actual Quest

The Fix

Acknowledgments

Trivial Auto Var Init Experiments

Comparing the Approach with Address Sanitizer

Compiler Optimization

Lowering

Evaluating Using -ftrivial-auto-var-init=xxxx on Firefox

Spotting the culprit

Recurring Nightmare

SmallVector and Friends

Initialization within a Loop

Empty Class

Manual Check

Value Semantic

Concluding Words

Acknowledgments

-Wglobal-constructors

Warming up

Digging Into Firefox's global constructor

Bye bye, <iostream>

Let it go, <frozen/*.h>

Hello, constexpr

Measuring the Impact

Acknowledgment

Shrinking a Shared Library

Generic Approach

Compilation Levels

Link Time Optimization

A Note on Stripping

Specializing the Binary

Removing .eh_frame

Specializing for a given usage

Concluding Notes

Acknowledgments

How unity builds crept into the Firefox Build System

Unity Build

Jumbo Build Creeps

Skipping includes

Accessing static functions

Trying to be smart with macro

Static templates

Template specialization

Leaking using namespace

Putting function implementation in header

Putting constant initializer in implementation

Error about functions without a valid declarations get silented

Unexpected aspect: less warnings

Headers without include guard

About the Firefox codebase

Acknowledgments

Introducing `__ANDROID_UNAVAILABLE_SYMBOLS_ARE_WEAK__`

`<android/system_fonts.h>`

`-Werror=unguarded-availability`

Evaluating Using `-ftrivial-auto-var-init=xxxx` on Firefox

Bye bye, `<iostream>`

Let it go, `<frozen/*.h>`

Hello, `constexpr`

Removing `.eh_frame`