Detecting Tests Which Don't Have Enough Workspace

Gedare Bloom gedare at gwu.edu
Thu Mar 12 18:33:58 UTC 2015


On Thu, Mar 12, 2015 at 2:26 PM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
>
> On 3/12/2015 12:45 PM, Gedare Bloom wrote:
>> On Thu, Mar 12, 2015 at 1:41 PM, Joel Sherrill
>> <joel.sherrill at oarcorp.com> wrote:
>>> Hi
>>>
>>> Many BSPs can link a test but don't actually have enough memory
>>> to run the test. They will fail in the first few lines when the requested
>>> memory for the RTEMS work area is not available. I hacked together
>>> a script which adds together the code, data, bss, work space and
>>> stack space requested. If this exceeds physical memory on the board,
>>> then the test will fail.  It is possible to come close and still run out of
>>> memory during initialization (e.g. malloc, etc) but this approach could
>>> detect some tests which will fail by inspecting them on the host.
>>>
>>> This is a shell script but would be better built into the rtems-tools
>>> and using the gdb/mi. Combined with information on the
>>> available memory on the target, we could throw out some obvious
>>> failure cases without touching hardware.
>>>
>>> Thoughts?
>>>
>> Would it be worthwhile to instrument our build (post-link) to do
>> something like this?
> I think it is worth doing something with this.   We need to know a few
> things about a BSP to do this in the general case:
>
You could start by just printing a warning based on assumptions,
caveat emptor. You might be able to snoop some of the relevant info
from the link script if that is accessible.

> + Is code loaded into RAM? If not, it doesn't need to be taken into account.
> + How much RAM is there?
> + In some cases, the program may not load at offset 0 of RAM and there
>    could be a reserved area. One case is m68k BSPs which sometimes load
>   at 0x3000 or 0x4000 to leave space for a ROM monitor.  We could ignore
>   this factor and just take a hit when it is run.
>
> But it definitely could avoid running some tests which are guaranteed to
> fail.  Consider this output:
>
> $ sh ../rtsize v850
> ./v850-rtems4.11/c/v850sim/testsuites/fstests/fsdos*/*.exe
> 216338
> ./v850-rtems4.11/c/v850sim/testsuites/fstests/fsdosfsformat01/fsdosfsformat01.exe
> 1259536
> ./v850-rtems4.11/c/v850sim/testsuites/fstests/fsdosfsname01/fsdosfsname01.exe
>
> There is only 1MB RAM for the simulator. The second test is doomed. It
> will not run. The first may run.
>
>>> ===============================
>>> #! /bin/sh
>>>
>>> if [ $# -le 2 ] ; then
>>>   echo "Usage: $0 ARCH EXE ..."
>>>   exit 1
>>> fi
>>>
>>> ARCH=$1
>>> shift
>>>
>>> target=${ARCH}-rtems4.11
>>> type ${ARCH}-rtems4.11-size >/dev/null 2>&1
>>> if [ $? -ne 0 ] ; then
>>>   echo "${ARCH} does not appear to have RTEMS 4.11 tools installed"
>>>   exit 1
>>> fi
>>>
>>>
>>> extract_size()
>>> {
>>>   ( echo "p Configuration.work_space_size" ; \
>>>     echo "quit" ) | ${target}-gdb ${exe} 2>&1 | grep "\$1" | \
>>>   cut -d'=' -f2
>>> }
>>>
>>> for exe in $*
>>> do
>>>  image_size=`${target}-size ${exe} | tail -1 | cut -f4`
>>>  wkspace_size=`extract_size Configuration.work_space_size`
>>>  stackspace_size=`extract_size Configuration.stack_space_size`
>>>
>>>  #echo ${image_size} ${wkspace_size} ${stackspace_size}
>>>
>>>  total=`echo ${image_size} ${wkspace_size} + ${stackspace_size} + p | dc`
>>>  echo ${total} ${exe}
>>> done
>>>
>>> exit 0
>>>
>>> ===============================
>>>
>>> --
>>> Joel Sherrill, Ph.D.             Director of Research & Development
>>> joel.sherrill at OARcorp.com        On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>> Support Available                (256) 722-9985
>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



More information about the devel mailing list