Detecting Tests Which Don't Have Enough Workspace

[Joel Sherrill]

On 3/12/2015 1:33 PM, Gedare Bloom wrote:
> 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.
The script uses gdb to extract the value of two fields in Configuration.
The linker script variables are accessible if the names are known.

This is from psim:

(gdb) p &bsp_section_work_size
$3 = (<variable (not text or data), no debug info> *) 0xfd8140 ""

The symbol name varies mostly based on architecture but sometimes
We will have to take RAM_END (or RAM_START+RAM_SIZE) - WorkAreaBase
(or similar) and compare it.

More tedious to extract than painful.
>> + 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

-- 
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