=?iso-8859-1?q?GCC_doesn=B4t_work_on_MINIX_3=2E1=2E3a?= - Minix

This is a discussion on =?iso-8859-1?q?GCC_doesn=B4t_work_on_MINIX_3=2E1=2E3a?= - Minix ; Hi to all, Ive a problem with gcc and Minix 3.1.3a (all packages installed) running on a P3 with 96 MB RAM. When i try to compile a source by using gcc or g++ i get this error: $gcc /home/source.c ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: =?iso-8859-1?q?GCC_doesn=B4t_work_on_MINIX_3=2E1=2E3a?=

  1. =?iso-8859-1?q?GCC_doesn=B4t_work_on_MINIX_3=2E1=2E3a?=

    Hi to all,

    Ive a problem with gcc and Minix 3.1.3a (all packages installed)
    running on a P3 with 96 MB RAM.

    When i try to compile a source by using gcc or g++ i get this error:
    $gcc /home/source.c

    pm_exec: exec_newmap failed: -12
    gcc: error trying to exec ./../libexec/gcc/i386-pc-minix/4.1.1/cc1:
    execv: Not enough core

    I tryed to set a larger amount of stack memory for gcc by using the
    command chmem but nothing changed...
    The same problem occours even with Minix stable version 3.1.2
    By contrast, ACK compiler works fine.

    Can someone tell me how to solve this problem?

    Thanks a lot! Hi!

    Maurizio Lombardi


  2. =?iso-8859-1?q?Re:_GCC_doesn=B4t_work_on_MINIX_3=2E1=2E3a?=


    > pm_exec: exec_newmap failed: -12
    > gcc: error trying to exec ./../libexec/gcc/i386-pc-minix/4.1.1/cc1:
    > execv: Not enough core
    >


    Ok, the problem is that PM process doesn't find an entry in the memory
    block free list big enough for gcc...
    Gcc requires ~33000 clicks but ~5000 clicks is the biggest hole the
    list contains on my PC (96 Mb of RAM).
    The only way to solve this problem seems to be to use a swap file....

    However i really don't think MINIX3 requires swap file to run gcc when
    something like 27 Mb of contiguous RAM are free!! (according to top).

    A little question: 1 click = 4kbytes?


  3. Re: GCC =?iso-8859-1?Q?doesn=B4t_work_on_MINIX_3.1.3a?=

    > A little question: 1 click = 4kbytes?

    Correct. This is found in include/minix/const.h:

    #if (CHIP == INTEL)
    #define CLICK_SIZE 4096 /* unit in which memory is allocated */
    #define CLICK_SHIFT 12 /* log2 of CLICK_SIZE */
    #endif

    Note that, when programming, you should use the value directly from
    this file, as it could be different in ports to other architectures.

  4. =?iso-8859-1?q?Re:_GCC_doesn=B4t_work_on_MINIX_3=2E1=2E3a?=


    Erik van der Kouwe ha scritto:

    > > A little question: 1 click = 4kbytes?

    >
    > Correct. This is found in include/minix/const.h:
    >
    > #if (CHIP == INTEL)
    > #define CLICK_SIZE 4096 /* unit in which memory is allocated */
    > #define CLICK_SHIFT 12 /* log2 of CLICK_SIZE */
    > #endif
    >


    Thanks.

    And so 33000 clicks are 33000*4096 byte = 135168000 byte = 128,9
    Mb !!!!!
    Gcc requires 128 Mb of free contiguous RAM to work????

    I can work with gcc on a linux PC with less then 32 Mb of RAM.
    There is something wrong for sure.

    Maurizio Lombardi


  5. Re: GCC =?iso-8859-1?q?doesn=B4t?= work on MINIX 3.1.3a


    Maurizio Lombardi wrote:

    > Erik van der Kouwe ha scritto:
    >
    >> > A little question: 1 click = 4kbytes?

    >>
    >> Correct. This is found in include/minix/const.h:
    >>
    >> #if (CHIP == INTEL)
    >> #define CLICK_SIZE 4096 /* unit in which memory is allocated */
    >> #define CLICK_SHIFT 12 /* log2 of CLICK_SIZE */
    >> #endif
    >>

    >
    > Thanks.
    >
    > And so 33000 clicks are 33000*4096 byte = 135168000 byte = 128,9
    > Mb !!!!!
    > Gcc requires 128 Mb of free contiguous RAM to work????
    >
    > I can work with gcc on a linux PC with less then 32 Mb of RAM.
    > There is something wrong for sure.
    >
    > Maurizio Lombardi


    Looks as if you should use chmem to set a smaller amount of memory on
    the executable. In an earlier post you wrote:

    > pm_exec: exec_newmap failed: -12
    > gcc: error trying to exec ./../libexec/gcc/i386-pc-minix/4.1.1/cc1:
    > execv: Not enough core


    > I tryed to set a larger amount of stack memory for gcc by using the
    > command chmem but nothing changed...


    Might it be, you actually changed the gcc memory size then? Perhaps to
    somthing you didn't actually want, because of a misunderstanding
    regarding the units involved?

    Regards -- Markus






  6. =?iso-8859-1?q?Re:_GCC_doesn=B4t_work_on_MINIX_3=2E1=2E3a?=


    > Might it be, you actually changed the gcc memory size then? Perhaps to
    > somthing you didn't actually want, because of a misunderstanding
    > regarding the units involved?
    >


    I tried to set differents values with chmem,
    but i modified the alloc_mem function of process manager
    and i can see that chmem doesn't affect at all the amount of memory
    gcc
    requires, it remains stable around 33000 clicks.

    Maurizio Lombardi


  7. =?iso-8859-1?q?Re:_GCC_doesn=B4t_work_on_MINIX_3=2E1=2E3a?=


    > I tried to set differents values with chmem,
    > but i modified the alloc_mem function of process manager
    > and i can see that chmem doesn't affect at all the amount of memory
    > gcc
    > requires, it remains stable around 33000 clicks.
    >


    Here the patch i wrote for /usr/src/servers/pm/alloc.c
    It shows how much memory a process was asking for if the request fail.
    If you have my same problem, you can use this patch to see
    that gcc requires too much RAM.

    How to apply the patch:

    #patch /usr/src/servers/pm/alloc.c patch
    #cd /usr/src/tools
    #make image
    #make install
    #shutdown

    Choose to run custom minix image

    *** alloc.c Mon Sep 10 10:47:58 2007
    --- final.c Mon Sep 10 10:48:58 2007
    ***************
    *** 70,80 ****
    --- 70,83 ----
    */
    register struct hole *hp, *prev_ptr;
    phys_clicks old_base;
    + int biggest_hole=0;

    do {
    prev_ptr = NIL_HOLE;
    hp = hole_head;
    while (hp != NIL_HOLE && hp->h_base < swap_base) {
    + if(hp->h_len>biggest_hole)
    + biggest_hole=hp->h_len;
    if (hp->h_len >= clicks) {
    /* We found a hole that is big enough. Use
    it. */
    old_base = hp->h_base; /* remember where it
    started */
    ***************
    *** 96,101 ****
    --- 99,105 ----
    hp = hp->h_next;
    }
    } while (swap_out()); /* try to swap some other
    process out */
    + printf("Requested memory: %d biggest hole:%d
    \n",clicks,biggest_hole);
    return(NO_MEM);
    }


  8. Re: GCC =?iso-8859-1?q?doesn=B4t?= work on MINIX 3.1.3a


    Maurizio Lombardi wrote:

    >> Might it be, you actually changed the gcc memory size then? Perhaps to
    >> somthing you didn't actually want, because of a misunderstanding
    >> regarding the units involved?
    >>

    >
    > I tried to set differents values with chmem,
    > but i modified the alloc_mem function of process manager
    > and i can see that chmem doesn't affect at all the amount of memory
    > gcc
    > requires, it remains stable around 33000 clicks.


    I wonder. Either you damaged alloc_mem or your chmem(1) attempts have
    not been successful. Have you reread the values from the executable
    using chmem, just for control?

    BTW: I find your approach questionable. Just earlier you wrote:

    > Gcc requires 128 Mb of free contiguous RAM to work????


    and then you admit you changed alloc_mem. Mightn't that be the
    problem? Try running gcc with an unmodified kernel first.

    Regards -- Markus


  9. Re: GCC =?iso-8859-1?Q?doesn=B4t_work_on_MINIX_3.1.3a?=

    > Here the patch i wrote for /usr/src/servers/pm/alloc.c
    > It shows how much memory a process was asking for if the request fail.
    > If you have my same problem, you can use this patch to see
    > that gcc requires too much RAM.


    GCC does not cause this allocation to be requested, the chmem value for
    it's binary does. Memory allocation in Minix cannot be changed after an
    executable has been started (that is, when the exec call is performed),
    so you must manually use chmem to change the value you see.

  10. =?iso-8859-1?q?Re:_GCC_doesn=B4t_work_on_MINIX_3=2E1=2E3a?=


    > I wonder. Either you damaged alloc_mem or your chmem(1) attempts have
    > not been successful. Have you reread the values from the executable
    > using chmem, just for control?
    >
    > BTW: I find your approach questionable. Just earlier you wrote:
    >
    > > Gcc requires 128 Mb of free contiguous RAM to work????

    >
    > and then you admit you changed alloc_mem. Mightn't that be the
    > problem? Try running gcc with an unmodified kernel first.
    >


    If you read the patch you can see i added just 4 lines of C code:

    1)+ int biggest_hole=0;
    2)+ if(hp->h_len>biggest_hole)
    3)+ biggest_hole=hp->h_len;
    4)+ printf("Requested memory: %d biggest hole:%d
    \n",clicks,biggest_hole);

    You can see by yourself: nothing special.

    >Try running gcc with an unmodified kernel first.


    I already did it.
    PS: Not the kernel, only PM process

    Maurizio Lombardi


  11. =?iso-8859-1?q?Re:_GCC_doesn=B4t_work_on_MINIX_3=2E1=2E3a?=


    > GCC does not cause this allocation to be requested, the chmem value for
    > it's binary does. Memory allocation in Minix cannot be changed after an
    > executable has been started (that is, when the exec call is performed),
    > so you must manually use chmem to change the value you see.



    Yes, your points are correct, thanks.

    Now i solved the problem:
    I was trying to use chmem on the wrong bin
    Problem is between screen and chair!
    I did:
    #chmem =value /usr/bin/gcc
    and
    #chmem =value /usr/bin/i386-minix-4.1.1
    It's wrong!

    The right path is:
    #chmem =value /usr/gnu/libexec/gcc/i386-pc-minix/4.1.1/cc1

    I didn't read with the needed attention the error:
    gcc: error trying to exec ./../libexec/gcc/i386-pc-minix/4.1.1/cc1:

    And so chmem will print:

    Stack+malloc area changed from 131Mb to [value].
    However i think the standard value of 131 Mb is really too high,
    6 Mb are sufficient.

    I have only a doubt, i was the only one with this problem?
    No one else saw the value was so high?

    Maurizio Lombardi


  12. Re: GCC =?iso-8859-1?q?doesn=B4t?= work on MINIX 3.1.3a


    Maurizio Lombardi wrote:

    >> I wonder. Either you damaged alloc_mem or your chmem(1) attempts have
    >> not been successful. Have you reread the values from the executable
    >> using chmem, just for control?
    >>
    >> BTW: I find your approach questionable. Just earlier you wrote:
    >>
    >> > Gcc requires 128 Mb of free contiguous RAM to work????

    >>
    >> and then you admit you changed alloc_mem. Mightn't that be the
    >> problem? Try running gcc with an unmodified kernel first.
    >>

    >
    > If you read the patch you can see i added just 4 lines of C code:
    >
    > 1)+ int biggest_hole=0;
    > 2)+ if(hp->h_len>biggest_hole)
    > 3)+ biggest_hole=hp->h_len;
    > 4)+ printf("Requested memory: %d biggest hole:%d
    > \n",clicks,biggest_hole);
    >
    > You can see by yourself: nothing special.


    I see, but how was I to know _before_ you postet your patch? At the
    best your initial statement was rather incomplete (see also the cc1
    vs. gcc question: If you had posted complete output, I'm sure someone
    would have pointed you to your misunderstanding, but since you posted
    conclusions, instead of evidence ...).

    Regards -- M


  13. =?iso-8859-1?q?Re:_GCC_doesn=B4t_work_on_MINIX_3=2E1=2E3a?=


    > I see, but how was I to know _before_ you postet your patch?


    ?
    In fact i posted the patch, and after i wrote "if you read the patch
    you can see it's nothing special".
    I don't see where the problem is.

    >At the
    > best your initial statement was rather incomplete (see also the cc1
    > vs. gcc question: If you had posted complete output, I'm sure someone
    > would have pointed you to your misunderstanding, but since you posted
    > conclusions, instead of evidence ...).


    -----------
    When i try to compile a source by using gcc ....
    $gcc /home/source.c
    I tried to set a larger amount of stack memory for gcc....
    -----------

    When i talk about gcc, i mean gcc and so /usr/gnu/bin/gcc
    I believe no one directly calls cc1 to compile C sources, even you.
    I admit only one thing: it was better to write
    "I tried to do #chmem =value /usr/gnu/bin/gcc"

    > but since you posted
    > conclusions, instead of evidence


    Are you sure?
    It is clear enough:

    >i can see that chmem doesn't affect at all
    >the amount of memory gcc
    >requires, it remains stable around 33000 clicks.


    Maurizio Lombardi


  14. Re: GCC =?iso-8859-1?q?doesn=B4t?= work on MINIX 3.1.3a


    Maurizio Lombardi wrote:

    >> I see, but how was I to know _before_ you postet your patch?

    >
    > ?
    > In fact i posted the patch, and after i wrote "if you read the patch
    > you can see it's nothing special".
    > I don't see where the problem is.


    Only that you posted the patch after _I_ posted the answer which you
    criticized to the effect that I (Markus) could have seen the patch is
    nothing special.

    >>At the
    >> best your initial statement was rather incomplete (see also the cc1
    >> vs. gcc question: If you had posted complete output, I'm sure someone
    >> would have pointed you to your misunderstanding, but since you posted
    >> conclusions, instead of evidence ...).

    >
    > -----------
    > When i try to compile a source by using gcc ....
    > $gcc /home/source.c
    > I tried to set a larger amount of stack memory for gcc....
    > -----------
    >
    > When i talk about gcc, i mean gcc and so /usr/gnu/bin/gcc
    > I believe no one directly calls cc1 to compile C sources, even you.
    > I admit only one thing: it was better to write
    > "I tried to do #chmem =value /usr/gnu/bin/gcc"
    >
    >> but since you posted
    >> conclusions, instead of evidence

    >
    > Are you sure?
    > It is clear enough:
    >
    >>i can see that chmem doesn't affect at all
    >>the amount of memory gcc
    >>requires, it remains stable around 33000 clicks.

    >


    (But you post what you conclude, not what you see: Only actual output
    can be seen, comprende?)

    Look, I'm not writing here to play this kind of games. There was
    nothing your original post about which chmem you did etc. Have it all
    your way: You're right and, ahem, Minix is defective and/or we're all
    idiots that we didn't solve your problem for you.

    Regards -- Markus






  15. =?iso-8859-1?q?Re:_GCC_doesn=B4t_work_on_MINIX_3=2E1=2E3a?=


    > Only that you posted the patch after _I_ posted the answer which you
    > criticized to the effect that I (Markus) could have seen the patch is
    > nothing special.


    I didn't criticized anyone, except myself.
    I didn't want to attack you in any way.

    > (But you post what you conclude, not what you see: Only actual output
    > can be seen, comprende?)


    Yes.

    >
    > Look, I'm not writing here to play this kind of games.


    Me too, and we can stop it here, because we are falling into a
    meaningless discussion.

    > There was
    > nothing your original post about which chmem you did etc.


    Yes, but if we want to be fussy you are not perfect too:
    You wrote:

    ------
    Looks as if you should use chmem to set a smaller amount of memory on
    the executable
    ------

    I did it, but you didn't say nothing about what and where is the
    executable you are talking about.

    > Have it all
    > your way: You're right


    I never said something like this.

    > and, ahem, Minix is defective and/or
    >


    I don't know where chmem stores the value you set about how much
    memory you want to assign to an executable, and i don't know if the
    default value for cc1 is set by the package mantainer.
    If it is set by package mantainer, _maybe_ the default value (131 Mb)
    is too high and it must be changed, else someone will come here again
    talking about the same problem.

    >we're all
    > idiots that we didn't solve your problem for you.


    I didn't want to say you or anyone else are idiots.

    Maurizio Lombardi


+ Reply to Thread