This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stderr with ARM not working


I wrote a longish email explaining libgloss and AngelSWI kernels and
stderr, which I included at the end of this message 'cause it might
still be interesting reading, when I realised your question was
actually asking why newlib/libc/sys/arm and libgloss/arm are out of
sync. I don't know why they're out of sync, but the plan is to remove
newlib/libc/sys/arm and replace it entirely with libgloss on arm. To
do that now, add the --disable-newlib-supplied-syscalls when
configuring newlib.

On 4/7/06, Michael Ambrus <ambrmi09@yahoo.com> wrote:
...
> Questions:
>
> * Is there a reason for not handling stderr in the
> libc-version (or maybe it is, but I just don't see
> it)?

There is no reason. newlib/libc/sys/arm and libgloss/arm are out of sync.

> * When would one use libgloss instead of libc?

Preferably all the time.

> * How can one distinguish between between the two
> without recompiling newlib?

You will need to recompile newlib using --disable-newlib-supplied-syscalls.

Cheers,
Shaun

[my original explanation of stderr and AngelSWI follows]

On *nix (read Linux, BSD, et cetera), stdin is file descriptor (fd) 0,
stdout is fd 1, and stderr is fd 2. On AngelSWI, the standard fds are
not defined so succinctly. stdin is defined as the fd returned when
opening ":tt" for reading, and stdout is defined as the fd returned
when ":tt" is opened for writing. The standard does not define stderr.
libgloss used to simply send the stderr data to stdout.

I had written a custom kernel that used the AngelSWI (RDP actually)
syscall protocol -- since then I also used Redboot briefly, and have
since switched to the Linux syscall protocol. The lack of stderr
annoyed me, and so I (embraced and) extended the AngelSWI protocol to
define stderr as the fd returned when opening ":tt" for appended
writing. My hope was that a typical AngelSWI implementation would use
the standard behaviour of returning a stdout fd, while my kernel could
return a stderr fd.

So, libc is not the issue; however, your AngelSWI kernel is. Which
kernel are you using?

Cheers,
Shaun

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]