448003 - Z/mZ values are off by 100 on OS X

Status: RESOLVED FIXED

(MailNews Core :: Build Config, defect)

Description

[David Ascher (:davida)]

According to the tinderbox page as of right now, Z for OS X is Z:1.56GB, which is a tad high, and about 100x what it is on Linux.

Comment 1

[Philippe M. Chiasson (:gozer)]

Hrm, just stole verbatim the stuff from SeaMonkey, does it also look 100x what it should be, sure looks like it to me:

From SeaMonkey's tinderbox tree:

"Linux comm-central build" Z:17.2MB
"MacOSX 10.4 comm-central build" Z:2.27GB

Comment 2

[Mark Banner (:standard8)]

I've a feeling its calculating it off the wrong directory/data, i.e. including all object files or something. I just haven't worked out where its doing that, or where we need to poke it.

Comment 3

[Philippe M. Chiasson (:gozer)]

Attachment: Teach nm_wrap_osx.pl to skip over absolutely addressed symbols

I think I've found what the source of the excessive bloat is. Looking at codesize-base.log, I noticed a symbol that is reported as taking *lots* of space:
$> grep -E 'trampoline_size' codesize-base.log
21ffffd8        DATA    STATIC  libplc4.dylib   A       UNDEF:libplc4.dylib:A   trampoline_size
20ffffd8        DATA    STATIC  libplds4.dylib  A       UNDEF:libplds4.dylib:A  trampoline_size
1fffffd8        DATA    STATIC  libnspr4.dylib  A       UNDEF:libnspr4.dylib:A  trampoline_size

$> perl -le'print 0x21ffffd8 + 0x20ffffd8 + 0x1fffffd8'
1660944264

That's a whopping 1.66Gb!

On top of that, trampoline_size is the only symbol marked as A (absolute address) and isn't coming from mozilla code, but is something introduced by OSX/gcc, apparently on 10.4 and not 10.5

A possible solution is to teach nm_wrap_osx.pl how to skip over such symbols, since we can't figure out their sizes anyways. Plus, looks like trampoline_size is the only one at this time, and it only appears in 3 different libraries.

Comment 4

[(not currently active) Ted Mielczarek]

Comment on attachment 332894 [details] [diff] [review]
Teach nm_wrap_osx.pl to skip over absolutely addressed symbols

Seems reasonable.

Comment 5

[Mark Banner (:standard8)]

Checked in Changeset id 16554:4312421f534b

Comment 6

[Philippe M. Chiasson (:gozer)]

Attachment: Symbol types should be matched case-insensitive

Symbol types are upper or lower case depending on their visibility. Upper-case is public, lower-case is private. In our case, we should match on either, so match case-insensitively.

Comment 7

[Mark Banner (:standard8)]

(In reply to comment #6)
> Created an attachment (id=333230) [details]
> Symbol types should be matched case-insensitive

Checked in changeset id 16576:0178bad8d3fe

Comment 8

[Philippe M. Chiasson (:gozer)]

As it seems to have solved SeaMonkey's problem too, I think this is now the correect fix.