On 26/02/2019 00:03, Joel Sherrill wrote:
> OPERATION_COUNT is usually the number of objects (e.g. tasks,
semaphores,
> etc) created so it is the maximum object count. For example,
tm03 has this:
>
>
https://git.rtems.org/rtems/tree/testsuites/tmtests/tm03/system.h#n29
>
> |#define CONFIGURE_MAXIMUM_TASKS (3 + OPERATION_COUNT) |
>
>
> So when Sebastian changed this, it went from a run-time to a
link time failure.
>
Ah ok, it is nice to see the error on these targets at link time.
Yes, the space for fixed count objects (not unlimited) is now allocated
by the linker. So, an INTERNAL_ERROR_TOO_LITTLE_WORKSPACE changed into a
linker error.
> The intent of OPERATION_COUNT was to be able to scale the timing
tests down
> to the hardware platform. Dropping OPERATION_COUNT to 10 for
these BSPs
> will resolve almost all of the tm and psxtm linking issues from
what I can tell.
What about a way to set this value in the `.tcfg` files and then
provide it on
the command line as a compile option?
This would be awesome! OPERATION_COUNT is an area where our old
build system person didn't want to tread. Much like the entire tcfg
system.
Yes, moving the test suite specific OPERATION_COUNT from the bsp.h to
the *.tcfg would be good. However, I would like to resolve the build
errors as soon as possible. So, change the patch to define
OPERATION_COUNT to 10 and adjust the *.tcfg accordingly?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
