What opens stdout? printf() fails after rtems-tester printf() succeeds.

Peter Dufault dufault at hda.com
Tue Sep 24 21:28:55 UTC 2019

I've started testing the PowerPC MVME5500 "beatnik" BSP on the mainline.  I've run through the majority of the RTEMS tests, with some failures, but when I went to run any basic programs they do not produce any output.  They are obviously running, I can put in a "sleep(3)" and observe it, but no output.

I looked at what rtems-tester does and see it wraps "printf()" and friends.  I found that if:
- I used "rtems_test_printf()" that output via "rtems_test_printf()" works.

After that I tried this in my _POSIX_Init(), to see if file descriptor 1 was open:

  const char *hello="Hello to FD 1\r\n";
  size_t n = strlen(hello);
  size_t output;
  rtems_test_printf("rtems_test_printf %s: Hello...\n", __func__);
  if ( (output = write(1, hello, n)) != n) {
    printk("%s: write() returned %d not %d: %s\n", __func__,
    (int)output, (int)n, strerror(errno));

The output is:

rtems_test_printf _POSIX_Init: Hello...
_POSIX_Init: write() returned -1 not 15: Bad file number

So file descriptor 1 isn't opened.  What establishes the standard open file descriptors that isn't being called in my update?

I *think* I have the GDB stub working, I had to modify it to bring it up-to-date, but I'd rather see a console message like "GDB stub starting up..." before I go further.

Peter Dufault
HD Associates, Inc.      Software and System Engineering

This email is delivered through the public internet using protocols subject to interception and tampering.

More information about the devel mailing list