amd64/linux/redhat lib memory map for 32 bit apps (task_unmapped_base etc.)

From: Eric Taylor (et_at_rocketship1.com)
Date: 02/27/04

  • Next message: John Reiser: "Re: amd64/linux/redhat lib memory map for 32 bit apps (task_unmapped_base etc.)" 
    Date: Fri, 27 Feb 2004 03:54:43 GMT

    I finally got my hands on an amd64 bit system from redhat. I was hoping
    that "out of the box" the memory mapping would permit a large contiguous
    region of virtual memory. I was surprised (and disapointed) to find that
    there is no more contiguous memory for 32 bit apps under this amd64
    setup than on a regular system.

    I find that the program loads at the bottom, like before, the dynamic loader,
    ld-linux (the 32 bit one) loads at

    0x4000_0000

    While the libraries load at

    0xA000_0000

    Which means that the sbrk region is no bigger than on a 32 bit system.
    And with the loader loading where it does, it creates 3 regions of memory.

    So...

    Anybody know how to move the ld-linux.so up to 0xA000_0000 as well?

    Or, does anyone know how to build an app with this code linked static?

    We have been struggling with this problem for years now, and hoped the
    amd64 would make things better. If the ld-linux.so would only get out
    of the middle of the sbrk region we would be happy campers. We cannot
    yet build a true 64-bit app.

    One thing that is puzzling is that one can load a program using the loader:

    /lib/ld-linux.so [options] [user-program and args]

    and then the ld-linux.so loads in a different place, but unfortunately, not
    in a better place. It loads at 0x8000_0000 on 32 bit linux and at
    0x5666_0000 (approx) on 64 bit linux. (Again, I'm only talking about
    32 bit apps here). So, it is definately relocatable, but I can't figure out
    what makes it load in different places depending on how you start up.

    thanks
    Eric

  • Next message: John Reiser: "Re: amd64/linux/redhat lib memory map for 32 bit apps (task_unmapped_base etc.)"

    Relevant Pages

    • Re: Why a 64bit PC ?
      ... > I'm a programmer. ... 64-bit slows down apps, if anything, because pointers become larger. ... available and memory is not used as often. ... IA-32 apps running on AMD64 will run around the same speed, ...
      (comp.lang.asm.x86)
    • Re: Nocona [Intel 64-bit cpu timing]
      ... memory at 4.5GiB/sec. ... As in the case of the Nocona vs. AMD64. ... my Prescott when on a Pentium M. ... The Prescott tops out at probably around ...
      (sci.crypt)
    • Re: boot failed with gziped modules
      ... I have a live CD that has a GENERIC kernel and that loads some modules ... check the commit history (www.freshbsd.org doesn't allow the commit messages ... Is it only sys/boot and lib/libstand that are involved with loader? ... about a month ago the only other change I did was switch from i386 to amd64. ...
      (freebsd-current)
    • Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
      ... > I am not enough of a kernel level person or sysadmin to know for certain, ... And when you don't use it, we'd be able to use those zones for at least ... Now, for many loads, that's fine. ... are often a big part of the memory use. ...
      (Linux-Kernel)
    • Re: vm.kmem_size settings doesnt affect loader?
      ... If your machine has some small amount of memory, ... then you probably shouldn't be using ZFS. ... The i386 vs. amd64 argument is bogus, ... kernel code and absolutely no experience with kernel memory management. ...
      (freebsd-stable)