printf returning EOF

[Ian Caddy]

Hi Keith,

This sounds like the sort of problem where the initialised data area is 
not being initialised.

printf and friends rely on chunks of inited data, being set and not 
being zero, so with the new BSP, you will need to ensure that your data 
is being copied into the correct running area by your startup code and 
while you are doing that also ensure that the BSS area is being 
initialised to zero.

Hope this helps.

regards,

Ian Caddy


Keith Robertson wrote:
> 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));
>         close(fd);
>     }
>     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!
> 
> Keith
> 
> P.S.
> 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
> anything...
> 
> 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,
> 
> Keith
> 
> 
> 
> 
> 
> 

-- 
Ian Caddy
Goanna Technologies Pty Ltd
+61 8 9221 1860