43357 - integrate elf-dynstr-gc into *nix builds

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Chris Waterson]

Subject:      ~ 13% size reduction on Linux using elf-gc-dynstr
 Resent-Date: Wed, 21 Jun 2000 13:49:25 -0700 (PDT)
 Resent-From: [e-mail]
        Date: Wed, 21 Jun 2000 13:49:10 -0700
        From: "Lynch, Rusty" <[e-mail]>
          To: "'[e-mail]'" <[e-mail]>
          CC: "'[e-mail]'" <[e-mail]>

At the last footprint reduction meeting a new tool for stripping out
unneeded symbols out of shared libraries on Linux.  I went ahead an tried
out the utility.  After downloading and installing libelf-0.6.4-4 on my
RedHat 6.1 system, I was able to build and test elf-gc-dynstr.  The results
I see are very promising:

   * Mozilla wide optimized/stripped build ==> a little under 13%
     reduction
   * same binaries compressed ==> a little over 5%

I haven't done extensive test to verify none of the .so files are corrupted,
but i was able to startup the browser and surf for about 20 minutes without
any problems (before I moved on to other things.)  So, when can we get this
in the build? 

        -rusty

Comment 1

[Judson Valeski]

we have embedding clients that can benefit from this in a *huge* way.

Comment 2

[cls]

Work already in progress.  I must've missed a step though because I cannot get
it to work for me.  

../../dist/bin/elf-gc-dynstr ../../dist/bin/libmozjs.so
Couldn't GC any strings, exiting.
make: *** [install] Error 1

Comment 3

[rusty.lynch]

It looks like this is what happens on a 'c' shared library where we don't have 
any fluff to remove.  We could change the utility to return 0 in this case. 

Comment 4

[Brendan Eich [:brendan]]

That's right -- no fluff in libmozjs.so!

(Why didn't jwz and I fight harder for C?  Because we like playing cassandra? 
;-)

/be

Comment 5

[cls]

Attachment: Integrates elf-dynstr-gc into optimized builds under Linux

Comment 6

[alla]

Only the shared libraries in components/ will be minimized by this, and only if
the version symbol hack is used.

Comment 7

[Christopher Blizzard (:blizzard)]

Does anyone know if this works on architectures other than i386?

Comment 8

[alla]

Define works. It doesn't crash or do anything bad, but it doesn't do anything 
good either.

It needs some extra care and loving for each architecture that should be 
supported. (The GOT and PLT sections are architecture specific.)

To work in a cross-compiling environment (ie. fix up ppc binaries from an x86 
host) some endianness handling needs to be added too.

Comment 9

[cls]

Attachment: updated patch

Comment 10

[cls]

Here's an updated patch that only gc's the component libs and removes the
additional -lelf.  I also added NTO to the OS_TARGET filter.  

Comment 11

[Christopher Blizzard (:blizzard)]

I already removed the -lelf from the makefile, just FYI.

Comment 12

[Brendan Eich [:brendan]]

Someone give an r= and I'll a= so we can get this checked in.

/be

Comment 13

[cls]

At blizzard's suggestion, I tweaked the patch to be a configure option. 
--enable-elf-dynstr-gc will attempt to run elf-gc-dynstr on component libraries
if MOZ_COMPONENTS_VERSION_SCRIPT_LDFLAGS is also set.  

Comment 14

[Mike Kaply [:mkaply]]

This broke our OS/2 tinderbox. The second ELF statement in rules.mk should be in 
the else case for the OS/2 line.

I need to make this change, but there is noone around for approvals yet.

I am going to go ahead and do it and watch the tinderboxes.

I will be on IRC if there are any problems.

Comment 15

[cls]

There is no OS/2 case for that particular segment.  I think I see what the real
problem is...the shell being used doesn't support the : command.  Quick fix.

+ifeq ($(OS_ARCH),OS_2)
+ELF_DYNSTR_GC  = echo
+else
 ELF_DYNSTR_GC  = :
+endif

Comment 16

[Jon Granrose]

verified.

Comment 17

[Doug Turner (:dougt)]

Is there any reason why this is not on by default on linux opt builds?

Comment 18

[cls]

"It needs some extra care and loving for each architecture that should be 
supported. (The GOT and PLT sections are architecture specific.)"

Alex, has any further work been done for non-x86 platforms?

Comment 19

[alla]

I have not done any work on non x86 archs. But it will still work in the sense
that it will not break anything. Files not recognized as supported will be
ignored.