stdout and stderr are getting mixed up?

[Chris Johns]

On 22/06/2017 16:19, Sebastian Huber wrote:
> On 22/06/17 08:00, Chris Johns wrote:
> 
>> On 22/06/2017 15:48, Sebastian Huber wrote:
>>> On 22/06/17 07:29, Chris Johns wrote:
>>>> On 22/06/2017 15:20, Sebastian Huber wrote:
>>>>> On 22/06/17 07:14, Chris Johns wrote:
>>>>>
>>>>>>> If you need a proper log, then you have to ensure this at application level.
>>>>>>>
>>>>>> What about this post:
>>>>>>
>>>>>> https://groups.google.com/d/msg/comp.programming.threads/1-bU71nYgqw/HSfD8625QzkJ
>>>>>>
>>>>>>
>>>>>>
>>>>>> It would imply a line should not be broken up. I do not know.
>>>>> You have thread-local stdio streams in Newlib that use a common output
>>>>> device by
>>>>> default.
>>>>>
>>>> Is what we do acceptable standard behavior?
>>> I doubt that thread-local stdio streams are in line with POSIX/C.
>>>
>> We need to consider this and what we do. We have breakage here and with C++.
> 
> The Ada run-time is also broken. 

OK

> I don't think you can easily disable the
> thread-local stdio streams. Applications may rely on this feature.

I would like to first establish what is happening and why. Easy or hard is
relative and that depends on a number of factors.

> 
>>
>>>> The link I posted would suggest otherwise.
>>> It doesn't cite the POSIX standard. I don't know where this atomic printf()
>>> behaviour is defined.
>> Did you check the author's name?
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/flockfile.html ?
> 
> I think flockfile() is not supported by RTEMS. It could be supported since the
> Newlib internal locking is now enabled.

It may be a stop gap measure for those with portable code.

> 
> powerpc-rtems4.12-objdump -d
> ./powerpc-rtems4.12/c/qoriq_t4240rdb/cpukit/libcsupport/src/libcsupport_a-flockfile.o
> 
> 
> ./powerpc-rtems4.12/c/qoriq_t4240rdb/cpukit/libcsupport/src/libcsupport_a-flockfile.o:
> file format elf32-powerpc
> 
> 
> Disassembly of section .text.flockfile:
> 
> 00000000 <flockfile>:
>    0:   4e 80 00 20     blr
> 
>>
>>>>    RTEMS 4.9, 4.10, and 4.11 did not do
>>>> this so is this a regression?
>>> The original post compares the beatnik and pc386 BSPs. It compares an Epic
>>> implementation using the  Classic API with one using the POSIX API. I don't
>>> think there is a regression. I remember that the output of ticker was always
>>> mixed up with an interrupt driven console driver.
>>>
>> It is present on the Zynq (polled driver). A sample:
>>
>> rc.conf: /etc/n]o]t ipcoew:e rs.tpaetauks.:P isny:s mmoanx :g e2t8
>> 3v.a3l3u0e0:0 0p
>> orwce.rc.oVnifn::  iifoc oenrfriogr:
>>   LiOfGc:o nsftiagt ulso:0  siynsemto n1 2g7e.t0 .v0a.l1u en:e tpmoawsekr
>> .2V5i5n.:0 .i0o. 0e rurp
>>
>> It is a complete turn off for users if this happens. If what we do meets the
>> standards then we can at least have a case we can present. If it does not and we
>> then create requirements based on the standards what happens?
> 
> It boils down to if you want to keep the thread-local stdio streams or not.

I would like to understand what is happening and it is still not clear to me and
I do not have the time to investigate. I have not paid a lot of attention to
newlib's new locking support. I know cygwin does not suffer from the issues we
are seeing but that may mean little.

> For
> log output you could still use syslog() for example.

It is about porting code to RTEMS. For code written just for RTEMS the
discussion is different.

Chris