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

[Peter Dufault]

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 add CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION to my configuration;
- 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
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering

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