dejagnu
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: honoring gcc test stack size


From: Joel Sherrill
Subject: Re: honoring gcc test stack size
Date: Tue, 12 Feb 2008 17:11:36 -0600
User-agent: Thunderbird 2.0.0.9 (X11/20071115)

Hans-Peter Nilsson wrote:
Date: Tue, 12 Feb 2008 15:47:14 -0600
From: Joel Sherrill <address@hidden>

I investigated one failure: pr20621-1.x3

You mean gcc/testsuite/gcc.c-torture/execute/pr20621-1.c at -O3?
From the looks of it, it would take about 2*0x4000*4 bytes stack.

grrr... that means it needs even more than 128K.
and discovered that it is using a LOT

#define LOT ?
Well... it is a relative term but when it comes to task stacks
in RTEMS, I tend to think of 2-8K.  A full executable with
termios console can be <32K code statically linked with
all drivers

Code size for a full application with web server, telnetd,
and ftpd with our ported BSD stack is usually 250-400K
code space.
of stack.  I don't know what the stack
size limit parameter you gave me is supposed
to do.

Have a look at the source and the test-cases. ;)
Hint: gcc/testsuite/lib/gcc.exp:gcc_target_compile.
Apparently gcc/testsuite/gcc.c-torture/execute/pr20621-1.c
doesn't use it.  I guess it should.

This is beyond my comfort zone right now.  I am trying
to digest what we have done so far so I can move on to the
other targets. :)
I increased the init task's stack to 128K
and that one passed.

Aha, so a LOT < 128K! :)

:)  Well it is a configurable number so if making it bigger runs
more tests, then so be it.

I remember griping about glibc's printf using 64K stack over
10 years ago.
I'm still counting bytes and cycles unfortunately.  It keeps me
honest.
(I know, I've been there too, some time ago.
Though these days a MB is "meh".)

ahhh MB...
brgds, H-P
--joel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]