#484 BOOTIMAGE_LOAD_ADDRESS problems on fedora core 4

confirmed
closed
nobody
GC (93)
8
2012-09-21
2005-06-20
jeremy singer
No

Default BOOTIMAGE_LOAD_ADDRESS for IA32 is
0x43000000.
On fedora core 4 with gcc 4, shared libraries are
mapped to this address, causing rvm to fall over early
in booting.
I hacked BOOTIMAGE_LOAD_ADDRESS
to 0x47000000 and everything seems to work OK again.

Discussion

  • Dave Grove
    Dave Grove
    2005-06-20

    Logged In: YES
    user_id=1215435

    Figuring out where to put the bootimage has always been a
    glass jaw of Jikes RVM. The basic issue is that we don't
    support relocating the bootimage after it has been written,
    so it has to be nailed down to some region of the virtual
    address space. We have some platform specific guesses on
    good address ranges in the various rvm/config/* files, but
    they do tend to change across platforms as various dlls get
    mapped in to the address space.

    In the older memory managers there were technical reasons
    why we need to nail the bootimage at a relatively low
    address range. With some of the recent changes in MMTk, I
    think (Steve B am I right??) that it would be possible for
    us to push them to a more middle-of-the-road address range
    that maybe would be less likely to cause conflicts with
    other shared libraries w/o losing any performance.

     
  • Ian Rogers
    Ian Rogers
    2005-06-21

    Logged In: YES
    user_id=308843

    Just a thought...

    The ldd command will describe library dependencies and tell
    you their load address. For example:

    bash> ldd JikesRVM
    linux-gate.so.1 => (0xffffe000)
    libdl.so.2 => /lib/libdl.so.2 (0x4003a000)
    libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4003e000)
    libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40051000)
    libm.so.6 => /lib/tls/libm.so.6 (0x4010e000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40131000)
    libc.so.6 => /lib/tls/libc.so.6 (0x40139000)
    /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

    we can parse the ldd output to determine the highest address
    for a shared library, we can then add on a guess as to that
    library's size (or just add on its file size...), we can
    then test to see that this is below the boot image load
    address. If the address isn't below we can print out a
    message telling users how to modify their RVM config,
    otherwise we do nothing. It wouldn't slow the jbuild process
    massively IMO. What do you think?

    Regards,

    Ian

     
  • Dave Grove
    Dave Grove
    2005-06-29

    Logged In: YES
    user_id=1215435

    This would be a nice addition. Telling the user that we
    know something is wrong at buildtime would be much better
    than randomly crashing at runtime.

     
  • Ian Rogers
    Ian Rogers
    2005-06-30

    Logged In: YES
    user_id=308843

    An example of the script needed to generate a compilation
    error for the boot image load address:

    for i in `ldd JikesRVM grep -v "linux-gate"
    if [ `echo "ibase=16; $i > $BOOTIMAGE_LOAD_ADDRESS" bc`
    == "1" ]; then
    echo "Boot image load address error please edit
    $RVM_TARGET_CONFIG and modify the BOOTIMAGE_LOAD_ADDRESS to
    have a value that is greater than 0x$i";
    exit 1;
    fi;
    done

    it just needs testing on the various architectures and
    possibly having some size added onto the library locations
    represented by $i in the loop above. I'll try and have
    another look when I get time.

    Regards,

    Ian

     
  • Dave Grove
    Dave Grove
    2005-07-13

    Logged In: YES
    user_id=1215435

    I think this is becoming a must fix defect before the next
    release.

     
  • Dave Grove
    Dave Grove
    2005-07-14

    Logged In: YES
    user_id=1215435

    Based on information from the mailing lists (see thread
    http://sourceforge.net/mailarchive/forum.php?thread_id=7728240&forum_id=43937).
    I changed the i686-pc-linux-gnu to the values

    export BOOTIMAGE_LOAD_ADDRESS=0x4c0000000
    export MAXIMUM_MAPPABLE_ADDRESS=0xb0000000

    This should handle the problem for now, but a more robust
    solution is required to automatically detect this problem
    for users.

     
  • Dave Grove
    Dave Grove
    2005-07-14

    Logged In: YES
    user_id=1215435

    The ldd scripts that were used to detect this are one
    checking approach. Works well for the .so that make up the
    VM and core libraries.

    A general solution for appliction-specific native code would
    probably involve extending VM_DynamicLibrary determine the
    address range into which it has (or even better is about to)
    load a dyanamic library and coordinate with MMTk to verify
    that the address range is available. A simple variant of
    this is to simply detect a problem and exit with a useful
    diagnostic method. A more ambitious variant would be to
    attempt to dynamically adjust the virtual address ranges
    used by MMTk (in some wild and crazy version, even
    triggering a GC to evacuate the problem region if it is
    actively in use) to accomodate the dynamic library.

     
  • jeremy singer
    jeremy singer
    2005-08-18

    patch to jconfigure, extends jbuild.linkBooter to check BOOTIMAGE_LOAD_ADDRESS against .so files linked with JikesRVM

     
  • jeremy singer
    jeremy singer
    2005-08-18

    Logged In: YES
    user_id=1051895

    I have incorporated Ian Rogers' little script that checks
    the JikesRVM object file against .so file address ranges,
    using the ldd utility. The appropriate check gets run at the
    end of jbuild.linkBooter script, so I modified jconfigure to
    generate the additional code.

    This patch has been tested on JikesRVM cvs head, with both
    host and target set as IA32.

     
  • jeremy singer
    jeremy singer
    2005-08-18

    Logged In: YES
    user_id=1051895

    sorry, previous diff was not against cvs head jconfigure -
    latest uploaded patch fixes this :-)

     
  • jeremy singer
    jeremy singer
    2005-08-18

    jconfigure patch against cvs head

     
    Attachments
  • Ian Rogers
    Ian Rogers
    2005-08-18

    Logged In: YES
    user_id=308843

    This looks good! Should it be submitted to the patch page to
    get integrated? There's an assumption that ldd, bc, grep and
    sed are in the PATH. There may also be issues that need
    solving for cross-compilation. Possibly people doing these
    builds can help debug this.

    Ian

     
  • Dave Grove
    Dave Grove
    2005-08-24

    Logged In: YES
    user_id=1215435

    Yep. Please either add the contribution statement as a
    comment here, or create a new patch tracker and add the
    patch and statement there.

    thanks,

    --dave