8 Replies Latest reply: Jul 15, 2011 11:30 AM by 853416 RSS

    linker memory use on 64-bit x86

    873209
      We have a strange problem with linking one of our C++ applications, built with SunStudio 12.1 on x86 64-bit. Currently we build it on Solaris 8 for sparc 32-bit, and on Solaris 10 for sparc 32-bit, sparc 64-bit, x86 32-bit and x86 64-bit platforms. We recently tried to upgrade the hardware for the VM farm running the VM for our Solaris 10 x86 build machine, and that meant we needed to apply a kernel patch (we were running Solaris 10 U3) to support the new CPU. The kernel patch brought with it a bunch of other Solaris packages including SUNWtoo which has the linker. The new version of the linker has a rapidly exploding memory use when compiling for x86 64-bit - it quickly exhausts all available memory and then core dumps - x86 32-bit builds are still ok.

      The version of ld we're running (as shown from "ld -V") after applying the patches is 5.10-1.489, prior to applying the patches is 5.10-1.482. If I copy ld (and required libld* shared objects) from the old install to the new install then I can link the application with no problems, but this means we have a hand-hacked build machine which means we can't put source + build tool versions into escrow for our customers. I found other versions of ld on other Solaris 10 machines we have, and verified that 5.10-1.497 and 5.10-1.500 also fail to link this application - only 5.10-1.482 succeeds.

      The application that fails uses templates very heavily and so has a very large number of symbols - I suspect this may be provoking something - but it is strange that the memory use of ld when linking the application used to be less than 200MB, and now ld appears to be insatiable. Also strange is that the problem only appears on x86 64-bit, but our Solaris 10 sparc build machine is still running ld 5.10-1.482 so it is possible that sparc 64-bit would also have a problem if we were to upgrade that machine.

      Does anyone have any ideas how I could resolve this? I have already tried re-arranging source code and various linker flags but without success.
        • 1. Re: linker memory use on 64-bit x86
          User12625414-Oracle
          What kernel patch was on the s10 x86 build system when ld worked and what patch did you install to bring ld up to 5.10-1.489?
          • 2. Re: linker memory use on 64-bit x86
            853416
            Could you try adding the compiler option "-xannotate=no" to your link line and seeing if the problem goes away? There is a new default feature in the Studio12.1 compiler, which is enabled on newer Solaris 10 systems.

            Also, when building your application, is it compiled without optimizations? Or, are you linking legacy object files built with a different/older compiler?

            Sheldon
            • 3. Re: linker memory use on 64-bit x86
              873209
              Thank you for the suggestions. The "-xannotate=no" compile option does not fix the problem. All optimisations are turned off, and all objects are built with the same compiler. Compile debug information is turned on. We do the compile and link as 2 steps - the link is linking a shared object but I have found that linking to an executable or shared object does not make the problem go away. Compile flags in our standard build are:
              -DHOST_CPU=amd64 -DHOST_amd64 -DHOST_PROD=SOLARIS10_X64 -DHOST_SOLARIS10_X64 -DHOST_FAM=SOLARIS -DHOST_SOLARIS -D_REENTRANT -DDEBUG=9 -DASSERT -verbose=template -instances=extern -KPIC -c -mt -m64 -KPIC -xmodel=medium +w2 -g -xs
              And the link flags are:
              +w -G -g -mt -m64 -KPIC -xmodel=medium

              Note that every other executable and shared object we build is ok, so there is something about this one which fails - which is why I suspect the number of symbols.
              • 4. Re: linker memory use on 64-bit x86
                873209
                The old system has kernel:
                $ pkginfo -l SUNWckr
                PKGINST: SUNWckr
                NAME: Core Solaris Kernel (Root)
                CATEGORY: system
                ARCH: i386
                VERSION: 11.10.0,REV=2005.01.21.16.34
                BASEDIR: /
                VENDOR: Sun Microsystems, Inc.
                DESC: core kernel software for a specific instruction-set architecture
                PSTAMP: on10-patch-x20051219173834
                INSTDATE: Jul 29 2006 18:01
                HOTLINE: Please contact your local service provider
                STATUS: completely installed
                FILES: 424 installed pathnames
                30 shared pathnames
                30 linked files
                39 directories
                292 executables
                48295 blocks used (approx)

                $


                The new system has kernel:
                $ pkginfo -l SUNWckr
                PKGINST: SUNWckr
                NAME: Core Solaris Kernel (Root)
                CATEGORY: system
                ARCH: i386
                VERSION: 11.10.0,REV=2005.01.21.16.34
                BASEDIR: /
                VENDOR: Sun Microsystems, Inc.
                DESC: core kernel software for a specific instruction-set architecture
                PSTAMP: on10ptchfeatx20090902230759
                INSTDATE: May 28 2011 22:35
                HOTLINE: Please contact your local service provider
                STATUS: completely installed
                FILES: 450 installed pathnames
                32 shared pathnames
                28 linked files
                41 directories
                311 executables
                59052 blocks used (approx)

                $
                • 5. Re: linker memory use on 64-bit x86
                  User12625414-Oracle
                  Thanks for the SUNWckr package info. However, I need the patch ids of the old and new kernel patches as they install more than just SUNWckr (including SUNWtoo as you mentioned in your original posting).
                  • 6. Re: linker memory use on 64-bit x86
                    873209
                    The uname -a results are:

                    Old build machine:
                    $ uname -a
                    SunOS asbm05 5.10 Generic_118855-14 i86pc i386 i86pc
                    $

                    New build machine:
                    $ uname -a
                    SunOS asbm55 5.10 Generic_141445-09 i86pc i386 i86pc
                    $

                    Unfortunately the new build machine is at a slightly newer patch level than the patch level that first failed to build (I am not the administrator of our build machines - so not sure what that patch level was). The build in question is still failing on the new build machine with the patch level currently installed.
                    • 7. Re: linker memory use on 64-bit x86
                      User12625414-Oracle
                      Thanks for the patch info.

                      I looked through the linker bugs for the s10 updates corresponding to these patches and later but couldn't find an obvious candidate.

                      Do you have an Oracle support contract? If so, I suggest you log a support call
                      (I look at problems in this area for Oracle so this issue may end up crossing
                      my desk).

                      If you run pstack and pmap run against your core files does that provide any
                      clues?

                      Can you reproduce the problem with the linker debugger options turned on?
                      That is:

                      LD_OPTIONS=-Dall,output=<pathname> cc ...

                      See the 'Debugging Aids' section of the Linker and Libraries Guide:
                      http://download.oracle.com/docs/cd/E19082-01/819-0690/chapter2-18/index.html for
                      more information.

                      How big are the input files and how big is ld when it core dumps?
                      • 8. Re: linker memory use on 64-bit x86
                        853416
                        I should have read your reply more carefully when I first saw it.

                        To check if "-xannotate=no" solves the link-time slowdown and memory consumption problem, you need to add this option to the LINK line (not just the compile line). Could you please check this?

                        Thanks,
                        Sheldon