ninja&make/mac: Only pass -x for loadable_modules.

test/mac/strip/main.c

Index: test/mac/strip/main.c
===================================================================
--- test/mac/strip/main.c	(revision 0)
+++ test/mac/strip/main.c	(revision 0)
@@ -0,0 +1,11 @@
+// Copyright (c) 2013 Google Inc. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+static void the_static_function() {}
+void the_function() {}

[Mark Mentovai, 2013/09/13 16:09:05]

Without any stripping but with dead code stripping:

mark@cougar bash$ clang++ -arch i386 -O3 -fno-exceptions -fno-rtti t.cc -o t
-Wl,-dead_strip
mark@cougar bash$ nm t
00001000 T __mh_execute_header
00001fb0 T _main
         U dyld_stub_binder

Where did the_function go? It’s been dead-stripped! OK, that’s fine, you want to
make sure that the different build environments do dead code stripping the same
way, but now you can’t be sure if you’re testing symbol stripping or dead code
stripping. So you should add a variant of the function that won’t be stripped by
dead code stripping and call it too:

__attribute__((used)) void the_used_function() {}

and now nm shows

00001fa0 T __Z17the_used_functionv
00001000 T __mh_execute_header
00001fb0 T _main
         U dyld_stub_binder

[Nico, 2013/09/13 20:11:07]

Oh, you mean due to inlining. Done.

[Mark Mentovai, 2013/09/13 21:31:32]

Nico wrote:
Nope, not inlining, dead code stripping. Inlining might happen here but this
file still would have had a symbol for the_function because it defined it, and
some other file might have called it.

When the linker comes along, with dead-code stripping, it’ll see that the
function actually wasn’t called by another file, and drop it. Even before you
get to the point of stripping the symbol table, the_function would be removed.
After stripping, you won’t know if it was removed from the symbol table by
strip, or if the function text isn’t even present in the output anymore because
it was removed by dead code stripping.

Unless you say “__attribute__((used)).” Then the linker will say “oh, OK,
someone DOES use this” (maybe by loading the module and grabbing it out of the
symbol table) and leave it alone. Then, the function text is present in the
output, and if its symbol is gone it’s because strip got rid of it.

[Nico, 2013/09/13 21:41:07]

Since it's called it's not dead code without inlining, no?

[Mark Mentovai, 2013/09/13 21:50:35]

Nico wrote:
Oh, that’s what you meant by inlining. Yeah.

+

[Mark Mentovai, 2013/09/13 16:09:05]

Let’s also add a couple of more attributed functions to the mix:

__attribute__((visibility("hidden"))) void the_hidden_function() {}
__attribute__((visibility("default"))) void the_visible_function() {}

Either add variants with and without __attribute__((used)), or just add them
with __attribute__((used)) without worrying about going crazy with permutations.

[Mark Mentovai, 2013/09/13 16:09:05]

Can we get some non-text symbols too? A file-scope “extern const int”, “int”,
and “static int” would be nice.

[Nico, 2013/09/13 20:11:07]

I had that at first, but removed it again since it didn't seem to add much. I
can add them back if you want.

[Mark Mentovai, 2013/09/13 21:31:32]

Nico wrote:
Yeah.

[Nico, 2013/09/13 21:41:07]

Done.

+int main() {

[Mark Mentovai, 2013/09/13 16:09:05]

To make this test a little more realistic, let’s not call this “main” when we’re
not building the executable target. You can define some macro in the .gyp to be
the name of the function.

[Nico, 2013/09/13 20:11:07]

The non-executable targets use file.c, not main.c

+  the_function();
+  the_static_function();
+}
Property changes on: test/mac/strip/main.c
___________________________________________________________________
Added: svn:eol-style
   + LF