bootimage() - Minix

This is a discussion on bootimage() - Minix ; Hi, at exec_image() of bootimage.c the a_bss and a_stack are printed with some values and then, if the K_CLAIM flag is set, they become zero. But this is then wrong information. Christos...

+ Reply to Thread
Results 1 to 12 of 12

Thread: bootimage()

  1. bootimage()

    Hi,

    at exec_image() of bootimage.c the a_bss and a_stack are printed with some
    values and then, if the K_CLAIM flag is set, they become zero. But this is
    then wrong information.

    Christos



  2. bootimage.c (2)

    Hi,

    I tried to examine the memory location appearing after the banner, when the
    system is loaded:

    "cs ds text data bss stack"

    I placed a:

    getchar();

    before the comment:

    /* Check the kernel magic number. */

    in boothead.s

    and the monitor freezes to inspect the memory addresses.

    What I found strange is that the a_data, a_text, a_bss areas are not
    click_size aligned, as it should. I returned to the source and I saw that
    indeed the banner is printed before the areas get aligned.

    Christos



  3. bootimage.c (3)

    Hello again,

    I also think that the first of the following exec_image() instructions:

    ---
    a_bss+= a_data;
    n= align(a_bss, click_size);
    a_bss-= n;
    ---

    is unnecessary, since one of the previous instructions, the:

    ---
    if (!get_segment(&vsec, &a_data, &addr, limit)) return;
    ---

    left a_data zero


    Christos



  4. Re: bootimage.c (3)

    In article <1135269783.188769@athnrd02>,
    Christos Karayiannis wrote:
    >
    >is unnecessary, since one of the previous instructions, the:
    >
    >---
    >if (!get_segment(&vsec, &a_data, &addr, limit)) return;
    >---
    >
    >left a_data zero


    Look again. Get_segment() pads out the segment with zeros to a click
    boundary, and leaves the size negative by the amount of padding.
    --
    Kees J. Bot, Systems Programmer, Sciences dept., Vrije Universiteit Amsterdam

  5. Re: bootimage.c (3)

    Kees,

    did you notice that when the addr argument of get_segment() is not
    click_size aligned the bss space in exec_image() looses a click_size area?
    Hopefully the starting address is 0x800 or 0x10000.

    Christos



  6. Re: bootimage.c (3)

    In article <1135355998.107013@athnrd02>,
    Christos Karayiannis wrote:
    >
    >did you notice that when the addr argument of get_segment() is not
    >click_size aligned the bss space in exec_image() looses a click_size area?


    Which is why 'addr' is aligned to a click when the click size is
    obtained from the kernel. (It has to be, processes must be click
    aligned.) For the 386 version the servers are loaded at 1M, so you'd
    better not set the click size to 2M, or things will go horribly wrong.
    --
    Kees J. Bot, Systems Programmer, Sciences dept., Vrije Universiteit Amsterdam

  7. Re: bootimage.c (3)

    Kees,

    I am sorry to come back to this but I think that for a data area of 3 and
    1/2 click_size and for bss 3 click_size the bss area that gets zeroed is A B
    C, while it should be D C B and the half of A. The memory map looks like
    this:

    -------------
    bss 1 | A
    -------------
    bss 1 | B
    -------------
    bss 1 | C
    ------------- <------------------ addr
    1/2 | D
    ------------
    data 1/2 | E
    -------------
    data 1 | F
    -------------
    data 1 | G
    -------------
    data 1 | H
    -------------


    Christos



  8. Re: bootimage.c (3)

    also the last five instructions of get_segment(), except the return, seem
    not to be used in our case, where the processes are loaded, starting at a
    round position

    Christos



  9. Re: bootimage.c (3)

    In article <1135448443.360161@athnrd02>,
    Christos Karayiannis wrote:
    >
    >I am sorry to come back to this but I think that for a data area of 3 and
    >1/2 click_size and for bss 3 click_size the bss area that gets zeroed is A B
    >C, while it should be D C B and the half of A.


    The 'addr' variable in the exec_image() function is kept at a multiple
    of the click size. You have to look at the code with that in mind. So
    get_segment() reads a text or data segment into memory and then pads it
    out to the next click boundary with zeros. (The instructions you call
    useless in your other message.) This padding is subtracted from the
    size parameter taking it negative.

    So for the BSS part we first have to discount the padding to the DATA
    area:

    a_bss += a_data;

    Compute its size in a whole number of clicks:

    n= align(a_bss, click_size);

    Take those bytes from a_bss, leaving it negative by the amount of
    padding:

    a_bss-= n;

    Zero that area:

    raw_clear(addr, n);
    addr+= n;

    Now play the same game with the stack:

    a_stack+= a_bss;
    n= align(a_stack, click_size);

    addr+= n;

    The 'a_stack-= n' statement is finally one you can point out as useless.
    I guess I had to put it in for symmetry reasons, or I forgot to remove it.

    Maybe it would have been better to pad the segments out to a click
    explicitly a little later than these shenanigans, but I wrote it this
    way, and I can't remember needing much time to debug it, although it's
    been a while now.

    (Christmas vacation of 1991. Looking at the dates, I started on the
    bootblock and installboot on the 21st, rawfs library on the 23rd, and
    the monitor on the 27th. I know I came out with working code, so it
    must have been done on January 5. (Bootimage.c was split off boot.c
    a few weeks later.) I guess this is why I've never understood why
    people make such fuzz over the bootstrap. Anything you can code in two
    weeks and still have time for Xmas dinner can't be all that important.)
    --
    Kees J. Bot, Systems Programmer, Sciences dept., Vrije Universiteit Amsterdam

  10. Re: bootimage.c (3)

    >a_bss += a_data;
    >
    >Compute its size in a whole number of clicks:
    >
    >n= align(a_bss, click_size);
    >
    >Take those bytes from a_bss, leaving it negative by the >amount of
    >padding:
    >
    >a_bss-= n;
    >
    >Zero that area:
    >
    >raw_clear(addr, n);
    >addr+= n;
    >
    >Now play the same game with the stack:
    >
    >a_stack+= a_bss;
    >n= align(a_stack, click_size);
    >
    >addr+= n;


    Kees I understand all this, what I doubt is that since the 'while' loop
    reads in click_size quantum if we don't have a rounded amount, the addr (as
    found at the end of the 'while' loop) points above to the next rounded
    position and not to the end of the data segment, which is lower. In that
    case the raw_clear() that follows after the loop does misses the space from
    the end of data segment to the next aligned point. The problem in other
    words is that addr always points to a click_sized value, while it should
    point at the point where the data exactly end.

    I also said that the code after the 'while' seems not to be used because
    since the 'while' reads click_sized quantum and since we start from a
    rounded position there is nothing to align (the addr is already to a
    click_size aligned position). As for the bootstrapping code, I think you did
    a Herculean job in the X-mas vacations of 91 and also that the bootstrapping
    phase code is an important part of the Minix source

    Christos




  11. Re: bootimage.c (3)

    Kees, I see now that addr MUST be a multiple of click_size

    Christos



  12. Re: bootimage.c (3)

    In article <1135522848.788985@athnrd02>,
    Christos Karayiannis wrote:
    >
    >Kees I understand all this, what I doubt is that since the 'while' loop
    >reads in click_size quantum if we don't have a rounded amount, the addr (as
    >found at the end of the 'while' loop) points above to the next rounded
    >position and not ...


    I'm sorry to say that I stopped reading at this point. This kind of
    code is such that any little mistake is likely to lead to crash. The
    fact that Minix doesn't crash should tell you that the code is probably
    right and that you should look at it a little longer if you think you
    spot a mistake.

    I won't say that it's flawless, but any bug is probably more subtle than
    a click size padding error or something.
    --
    Kees J. Bot, Systems Programmer, Sciences dept., Vrije Universiteit Amsterdam

+ Reply to Thread