stdout and stderr are getting mixed up?
chrisj at rtems.org
Thu Jun 22 06:28:35 UTC 2017
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:
>>>>>> 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
>>>> 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.
> 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
> 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.
> 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.
More information about the users