printf returning EOF

Keith Robertson kjrobert at
Mon Jan 30 23:12:19 UTC 2006

Joel Sherrill wrote:
> Keith Robertson wrote:
>> Hi all.
>> I'm in the process of porting rtems to a new bsp (gen405 dervied). 
>> However, whilst doing so I've encountered an error I've not seen before.
> Given that this is a new BSP, it ispossible that the memory layout
> isn't quite right and the mallocs during early newlib initialization
> and the first printf are failing.  Can you determine the memory
> ranges given to the RTEMS Workspace and to the C program heap?

Hi Joel.

Thanks for the pointer. I've checked this out, but fortunately (or
unfortunately for finding the problem :), I'm pretty sure the
heap/workspace are correct and functioning. I've appended the details
towards the bottom of this email to avoid cluttering it and scaring
people off.

I've found one other interesting symptom that might tweak something in
someone's mind. The following code successfully prints string1 from a
normal device write call, but fails to print anything from the printf
calls (they all return -1, EOF).

rtems_task Init(
   rtems_task_argument ignored
     int fd;
     extern int errno;
     FILE *fp;
     char string1[] = "   testing1 ... 1 ... 2 ... 3\n";
     char string2[] = "   testing2 ... 1 ... 2 ... 3\n";

     printf("Starting test\n");

     printf("Trying open()\n");
     fd = open("/dev/console", O_RDWR);
     if (fd < 1) {
         printf("open() returned an error (%d). errno = %d\n",
                fd, errno);
     } else {
         printf("Going to write() to /dev/console\n");
         write(fd, string1, strlen(string1));
     printf("open() done\n");

To clarify, the only output on the console from the above program is:
<begin console output>
    testing1 ... 1 ... 2 ... 3
<end console output>

A similar block of code that tries to print to /dev/console as a file
using fwrite produces nothing -- both from the fwrite and any printfs.

Anyone have any ideas what a successful open and write to /dev/console
but a failing printf and fopen/fwrite might imply?

Ideas/pointers greatly appreciated!


Heap/Workspace details:

bsp_pretasking_hook is calling bsp_libc_init with a heap start address
of: 0x31fb8 and size of: 0x80000 (ie end is: 0xb1fb8).

BSP_Configuration has the following state once bsp_start() has run
(gdb) p /x BSP_Configuration
$4 = {work_space_start = 0x7f3800, work_space_size = 0xc800,
   maximum_extensions = 0x1, microseconds_per_tick = 0x2710,
   ticks_per_timeslice = 0x32, maximum_devices =0x14,maximum_drivers=0x1,
   number_of_device_drivers = 0x1, Device_driver_table = 0x3025c,
   number_of_initial_extensions = 0x0, User_extension_table = 0x0,
   User_multiprocessing_table = 0x0, RTEMS_api_configuration = 0x31024,
   POSIX_api_configuration = 0x30ffc, ITRON_api_configuration = 0x0}

This bsp allocates the workspace at the top of ram down which is
currently set to 8 megs.  (There's 32 megs available on the board).

Here's the memory map from the gdb download:
(gdb) load
Loading section .vectors, size 0x1f04 lma 0x100
Loading section .text, size 0x2e218 lma 0x2010
Loading section .data, size 0xad8 lma 0x30228
Loading section .got, size 0x10 lma 0x30d00
Loading section .got2, size 0x190 lma 0x30d10
Loading section .fixup, size 0x4c lma 0x30ea0
Loading section .jcr, size 0x4 lma 0x30eec
Start address 0x2010, load size 200164

After jcr comes bss and then the aforementioned heap.

I'm pretty sure these are all valid addresses and aren't overlapping

A breakpoint on malloc seems to indicate that the first allocation (in
rtems_libio_init for the rtems_libio_iops) succeeds and returns a valid
address within the heap.

Thanks again,


More information about the users mailing list