Page-aligned executables (Was re: [9fans] Non-stack-based callingconventions) - Plan9

This is a discussion on Page-aligned executables (Was re: [9fans] Non-stack-based callingconventions) - Plan9 ; On Feb 18, 2008 3:38 AM, Anant Narayanan wrote: > Just as an observation (may not be related to the thread), all the > executable file formats that Linux currently supports, have page- > aligned sections in the file! (Now ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Page-aligned executables (Was re: [9fans] Non-stack-based callingconventions)

  1. Page-aligned executables (Was re: [9fans] Non-stack-based callingconventions)

    On Feb 18, 2008 3:38 AM, Anant Narayanan wrote:
    > Just as an observation (may not be related to the thread), all the
    > executable file formats that Linux currently supports, have page-
    > aligned sections in the file! (Now I know why hexdump always shows me
    > a bunch of zeros in-between).
    >
    > That means, all the loader really does is mmap the sections into the
    > right memory locations. What next, maybe also put in the BSS in the
    > file so you wouldn't have to allocate that either


    Ron mentioned that tidbit in his IWP9 talk about booting Plan 9 under
    lguest. Lguest (or was it another virtualizer?) uses mmap so it can
    load any arbitrary number of client kernels; 9l-produced ELF files
    break that model.

    > Hence, writing the loader for Plan 9's a.out proved to be a challenge.
    >
    > I ended up writing a user-space program that padded out the required
    > gap between TEXT and DATA before asking the kernel to execute it.
    > Suboptimal, but it works.
    >
    > If anyone has any ideas as to how I can improve the situation, i'll be
    > grateful.


    What's the context that you're building this loader for?

    --Joel

  2. Re: Page-aligned executables (Was re: [9fans] Non-stack-based callingconventions)

    On Feb 18, 2008 8:53 AM, Joel C. Salomon wrote:

    > Ron mentioned that tidbit in his IWP9 talk about booting Plan 9 under
    > lguest. Lguest (or was it another virtualizer?) uses mmap so it can
    > load any arbitrary number of client kernels; 9l-produced ELF files
    > break that model.


    And with the execute in place support (XIP) it gets more interesting,
    and worth understanding, for reasons I'll mention below.

    IF you have an ext2-based RAM file system, and XIP is compiled in,
    then you can do the following: instead of mmap'ing the file, ext2
    essentially says: "here's a pointer to the data you wanted, it's in
    memory, just use it, don't page it in because that would be a copy
    from memory to memory".

    Why's it matter? First, boot time speed. A talk I saw on a Linux-based
    car computer stated that their boot time goal was one second; Linux
    was only allowed a very small fraction of this time to be ready (200
    milliseconds IIRC); XIP made a difference between meeting the time
    goals and not meeting them. Second, memory: on a 32 MB node, you
    really don't want two copies of every binary.

    So it's interesting to think about whether Plan 9 could boot a node in
    200 ms on a StrongARM (500 mhz? I think so) or not. But I think XIP on
    a small RAM disk would not be impossible.
    ron

  3. Re: Page-aligned executables (Was re: [9fans] Non-stack-based callingconventions)

    On Feb 18, 2008 12:10 PM, ron minnich wrote:
    > And with the execute in place support (XIP) it gets more interesting,
    > and worth understanding, for reasons I'll mention below.


    On a related note, in 2002 Russ said he'd implemented, then commented
    out, an mmap implementation for Plan 9. See
    /n/sources/contrib/rsc/linuxemu/linuxemu.c for the code. To make it
    work in user-space you'd need user-controlled process creation (which
    we've discussed on this list before) along with some extensions to
    segattach functionality. Given the 'joys' of mmap over remote file
    systems, we *really* don't want it in Plan 9 as-is!

    --Joel

  4. Re: Page-aligned executables (Was re: [9fans] Non-stack-based callingconventions)

    On Feb 18, 2008 10:06 AM, Joel C. Salomon wrote:
    > Given the 'joys' of mmap over remote file
    > systems, we *really* don't want it in Plan 9 as-is!



    What are those "joys" of which you speak?

    Just about every Unix system in the world today (including linux) that
    does an exec over nfs does the equivalent of mmap (in the kernel, so
    you never see it) or explicitly (in the case of shared libraries).
    SunOS/Solaris has done it that way for 20 years now. It kinda works
    ....

    ron

  5. Re: Page-aligned executables (Was re: [9fans] Non-stack-based callingconventions)

    On Feb 18, 2008 1:12 PM, ron minnich asked:
    > On Feb 18, 2008 10:06 AM, Joel C. Salomon wrote:
    > > Given the 'joys' of mmap over [NFS], we *really* don't want it in Plan 9 as-is!

    >
    > What are those "joys" of which you speak?


    ....and then he answered his own question:
    > It kinda works


    --Joel

  6. Re: Page-aligned executables (Was re: [9fans] Non-stack-based callingconventions)

    On Feb 18, 2008 10:20 AM, Joel C. Salomon wrote:

    > ...and then he answered his own question:
    > > It kinda works



    good one :-)

    how about:
    "it works so well that nobody knows it is happening" :-)

    ron

  7. Re: Page-aligned executables (Was re: [9fans] Non-stack-based callingconventions)

    >> Hence, writing the loader for Plan 9's a.out proved to be a
    >> challenge.
    >>
    >> I ended up writing a user-space program that padded out the required
    >> gap between TEXT and DATA before asking the kernel to execute it.
    >> Suboptimal, but it works.
    >>
    >> If anyone has any ideas as to how I can improve the situation, i'll
    >> be
    >> grateful.

    >
    > What's the context that you're building this loader for?


    I'm building a sort of reverse linuxemu, call it plan9emu if you will.
    I want to be able to run plan 9 binaries on linux without any
    modification. I've gotten as far as catching the syscalls, but the
    binary still has to be modified (padded).

    --
    Anant

+ Reply to Thread