Find the answer to your Linux question:
Results 1 to 10 of 10
We have a legacy linker/loader that uses libc5, and due to several factors we only have the binary and not the source. Yes, version control would have saved us from ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Apr 2009
    Posts
    5

    libc5 app running on kernel 2.6.25


    We have a legacy linker/loader that uses libc5, and due to several factors we only have the binary and not the source. Yes, version control would have saved us from our current problem... that is now in use for our full tool chain and product line, but this particular horse is long gone. This linker runs on a linux desktop (32 bit) PC, and produces code to run on a proprietary imbedded RISC CPU.

    This linker works when run on linux kernel 2.6.24, but with 2.6.25 (and 2.6.26) it fails with the message

    Virtual memory exceeded in `new'

    We had a similar problem with the corresponding legacy compiler, but with some research have discovered that the compiler problem was caused by the "brk randomization" in linux kernel 2.6.25. The workaround for that is to set a sysctl var and an environment var:

    /proc/sys/kernel/randomize_va_space = 0 or 1
    setenv MALLOC_TOP_PAD_ 536870912

    This, however, does not help the linker.

    I have found from using "ldd" that the linker has more shared library dependencies (the compiler only had the libc.so.5):

    libg++.so.27 => /usr/lib/libg++.so.27 (0xb7eca000)
    libstdc++.so.27 => /usr/lib/libstdc++.so.27 (0xb7e99000)
    libm.so.5 => /lib/libm.so.5 (0xb7e90000)
    libc.so.5 => /lib/libc.so.5 (0xb7dd3000)

    And I have read that I may have to install the libc5 version of libg++.so.27. I hesitate to do that since I dont know if that will override the latest libg++.so.27 and cause problems for non-libc5 apps.

    So, do I find and install the libc5 version of libg++.so.27, or is there some better way to disable brk randomization, or is there another difference between kernel 2.6.24 and 2.6.25 that is causing the linker problem?

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,755
    I take it that the libc5 is used by gcc? If so, you should be able to find the source to a deprecated/obsolete version in the FSF source trees. Check the FSF/GNU web site for that. They are pretty anal in keeping old release code available.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    Apr 2009
    Posts
    5
    Hi Rubberman,

    I am not sure what you mean. The source that is missing is the source to the proprietary linker/loader, FSF/GNU would not have that. And we already have the old libc5, so the legacy apps (the linker/loader and the compiler) load the libc.so.5 at runtime fine. The problem is that there is some incompatibility between libc5 and the newer linux kernels.
    Last edited by JimKleck; 04-28-2009 at 05:47 PM. Reason: fix typo

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,755
    Ok. Thanks. I misunderstood that you are using a proprietary linker/loader. So, you are using gcc to compile, but your own linker to create executables, correct?
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  6. #5
    Just Joined!
    Join Date
    Apr 2009
    Posts
    5
    Yes, that is correct. However, the gcc compiler has been modified to compile for our proprietary imbedded RISC CPU, and those mods (along with the linker source) have been lost.

    We are basically facing the choice of keeping a 2.6.24 kernel running (probably on a VM) for as long as we are using this RISC CPU, or finding a way to get the linker to run on newer kernels. I have already found a way to get the compiler to run on newer kernels, but even so there might be a better solution than the one I found (the details of which I mention in the original question). The problem with using the older kernel is that our engineers would not be able to do builds for the RISC on their local machine, they would have to log into the system with the older kernel (which could become swamped with src trees and become a bottleneck for builds).

  7. #6
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,755
    Since you lost the source code for this (man, what a bummer), have you thought about decompiling the library and assorted other stuff you no longer have the source for? I've done this in the past, though not on Linux systems. I understand there are some decent tools to accomplish that, and that purportedly produce reasonably readable code.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  8. #7
    Just Joined!
    Join Date
    Apr 2009
    Posts
    5
    I had not considered decompiling the linker (and subsequently recompiling with a modern toolchain). I think it would be a major effort, the symbol table has been stripped from the executable. I'll look around to see if there is an GNU decompiler, or do you have a recommendation?

  9. #8
    Just Joined!
    Join Date
    Apr 2009
    Posts
    5
    Hmm. A quick search reveals that optimized code does not decompile very nicely. I knew the engineer that wrote the linker and he was always pushing the optimization so I am certain that he optimized the linker to the max. Nice idea for a project, but I have got too much on my plate as it is.

  10. #9
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,755
    I've read something, somewhere lately (on another forum site, I think - possibly linux.com) about FOSS tools for doing this, but I don't personally know since I haven't needed to deal with this. My suggestion is to fire up our old friend, Mr. Google!
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  11. #10
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,755
    And FWIW, a good decompiler should be able to create reasonable names for the symbols, based upon their context. I know someone was talking about that on that other forum. Again, I didn't need to worry about it at the time, so I just "filed and forgot"... Sorry I cannot be of more help, but hopefully you can find what you need. Losing source for something like what you have is nothing less than a disaster for a company (I assume this is for your company). Somewhere, sitting in someone's desk, or in a mouldering piece of junk hidden in a closet somewhere, there is probably a floppy, zip drive, or hard drive with, if not the latest version, some version of the source that you could bootstrap from. If it is critical for the business, then recovering the source should be a major priority, IMHO.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •