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

[Joel Sherrill]

On Tue, Sep 24, 2019 at 4:29 PM Peter Dufault <dufault at hda.com> wrote:
>
> 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.

As a simple check, try "nm -g -n" on the executable and look at what's
in the Sysinit linker section. On psim hello,.exe, I see this:

001d660 D _Linker_set__Sysinit_begin
0001d660 D _Linker_set__Sysinit_bsp_work_area_initialize
0001d660 D __start_set_sysctl_set
0001d660 D __stop_set_sysctl_set
0001d664 D _Linker_set__Sysinit_bsp_start
0001d668 D _Linker_set__Sysinit__User_extensions_Handler_initialization
0001d66c D _Linker_set__Sysinit_rtems_initialize_data_structures
0001d670 D _Linker_set__Sysinit__RTEMS_tasks_Manager_initialization
0001d674 D _Linker_set__Sysinit__POSIX_Keys_Manager_initialization
0001d678 D _Linker_set__Sysinit__Thread_Create_idle
0001d67c D _Linker_set__Sysinit_rtems_libio_init
0001d680 D _Linker_set__Sysinit_rtems_filesystem_initialize
0001d684 D _Linker_set__Sysinit__Console_simple_Initialize
0001d688 D _Linker_set__Sysinit__IO_Initialize_all_drivers
0001d68c D _Linker_set__Sysinit__RTEMS_tasks_Initialize_user_tasks_body
0001d690 D _Linker_set__Sysinit_rtems_libio_post_driver
0001d694 D _Linker_set__Sysinit_end

It's the libio_post_driver one.

Another possibility based on my recollection of the mvme2100 is that
there are variants where some ports are missing or wired out strange
places. Given the file descriptor isn't there, I suspect that
/dev/console wasn't registered. That could mean the console driver
isn't in the build or it didn't see the device it wanted to register.

Check the linker set via nm first. That's easy.

--joel



> 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.
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel