psxshm01 and psxshm02 fail on SPARC/erc32

Chris Johns chrisj at rtems.org
Thu Jan 26 23:06:05 UTC 2017


Sorry, dropped my phone and the email was sent. 

> On 26 Jan 2017, at 3:24 pm, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
> 
> 
> 
> On 26/01/17 00:04, Chris Johns wrote:
>>> On 25 Jan 2017, at 9:33 pm, Gedare Bloom <gedare at rtems.org> wrote:
>>> 
>>> On Wed, Jan 25, 2017 at 2:07 AM, Sebastian Huber
>>> <sebastian.huber at embedded-brains.de> wrote:
>>>> On 25/01/17 04:00, Gedare Bloom wrote:
>>>>>>> On Tue, Jan 24, 2017 at 7:25 PM, Joel Sherrill<joel at rtems.org>  wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, Jan 24, 2017 at 6:23 PM, Gedare Bloom<gedare at rtems.org>  wrote:
>>>>>>> 
>>>>>>>>> Yes. They should fail with MAP_FAILED until we get a proper mmap().
>>>>>>>>> This can be either detected, or the test can be augmented until we get
>>>>>>>>> mmap support for shm objects done.
>>>>>>>>> 
>>>>>>> When you say augmented, you mean with an implementation of the
>>>>>>> adapter layer you defined that uses malloc() and knows a few names?
>>>>>>> 
>>>>> I mean to ignore/expect the MAP_FAILED return from mmap and terminate
>>>>> gracefully.
>>>>> 
>>>> In case MAP_FAILED is currently the expected return value on all
>>>> architectures, then this should be expected by the test. When will there be
>>>> a proper mmap() implementation exist? What is a proper mmap() implementation
>>>> for RTEMS at all?
>>>> 
>>> Timeline is not certain. I hope within 2 months.
>>> 
>>>> I used mmap() on some GUI library to speed up the font initialization and
>>>> simply mapped read-only font files (IMFS memfiles) via mmap(). It would be
>>>> good to gather some use cases. I think Qt uses also mmap() for font files.
>>>> 
>>> I know that mmap'ing files was a use case before. I have old code from
>>> Chris to support it, and intend to extend/re-implement that support to
>>> also provide mmap support for shm objects.
>>> 
>> Why not tag the test as "excepted fail" in the .tcfg file for all archs? All testing frame works need to be updated to handle the new message at the start of the test and either report the excepted fail did fail or it passed, requiring we update the .tcfg file.
> 
> The tests output should be self-describing. For this we need a new test framework.

Did you try this and observe the output that indicates the expected fail state? The expect fail state should be printed in a manner external parsers can track it. 

The current test framework can handle this, and with a change to handle the "all" case as Joel observed is missing it should be enough to handle this case. 

I see another framework is a different topic. 

>> 
>> I prefer tests do not mask a failure when it exists and we should be or are in the process of fixing it.
>> 
>> Chris
> 
> The half finished test actually prevented a bug detection in the close operation:
> 
> https://git.rtems.org/rtems/commit/?id=090bdc7e9451467946463a2658adb9e777813f1c

Improving tests is important.

Chris





More information about the devel mailing list