Dumb Question - Linkcmds and Heap initialization

[Gedare Bloom]

I'll take the liberty of jumping in again, although I am not the
expert here (learning by doing! :)

On Wed, Mar 10, 2010 at 11:07 AM, Robert S. Grimes <rsg at alum.mit.edu> wrote:
> Hi Joel,
>
> 1. Yeah, there was an overlap between .text and .textrom.  FWIW, for my
> system, the executable file is loaded (i.e. sections placed, etc.) by
> MicroMonitor, and there isn't really any need to place .textrom at a
> specific location (i.e. into a physical EPROM), so I just removed the
> address and let it get placed after the rest of the sections.  Is my
> interpretation correct on the meaning of .textrom?
>
> 2. I removed the overlap, and now I get two calls to _Heap_Initialize (as
> evidenced by my printk traces):
>
>    _Heap_Initialize: heap:96CDC8, start:990000, size:1048576, page:8
>    _Heap_Initialize: heap:96C598, start:AA0000, size:4292214784, page:8
>
> Looks better, except that the size of the second call is clearly bogus.
> Indeed, immediately (in human terms) after the second call, the Heap Walker
> goes nuts as before while walking through the second heap.
>
> 3. Is the first _Heap_Initialize call for the RTEMS workspace?
>
I think that is correct, it would be called from
_Workspace_Handler_initialization in cpukit/score/src/wkspace.c

> 4. Is the second call for the libc heap (for malloc, new, etc.)?
>
> 5. I'm guessing the problem is the calculation of the size for the second
> heap.  That's in bspstart.c, right?  Specifically, it seems to be here, in
> bsp_pretasking_hook() - is that right?
>
> void bsp_pretasking_hook(void)
> {
>     uint32_t        heap_start;
>     uint32_t          heap_size;
>     uint32_t          heap_end;
>
>     /* round up from the top of workspace to next 64k boundary, get
>      * default heapsize from linker script  */
>     heap_start = (((uint32_t)Configuration.work_space_start +
>            rtems_configuration_get_work_space_size()) + 0x18000) &
> 0xffff0000;
>
>     heap_end = _heap_start + (uint32_t)&_HeapSize;
>
>     heap_size = (heap_end - heap_start);
>
>     _heap_start = heap_start;
>     _heap_end = heap_end;
>
>     _top_of_ram = heap_end;
>
>     bsp_libc_init((void *) heap_start, heap_size, 0); /* 64 * 1024 */
>
> }
>
I agree with your thinking. Can you check with printk or somehow what
are the values of heap_start, heap_size?  I see a possible bug here,
which is this line:
   heap_end = _heap_start + (uint32_t)&_HeapSize;
If my C is right, this is actually adding the address of HeapSize to
the _heap_start, when what is really wanted is to add the number of
bytes _HeapSize to the _heap_start. e.g.
  heap_end = _heap_start + *(uint32_t)&_HeapSize;

By moving your .text section, you may have shifted the address of
_HeapSize to reveal this as a bug.  That's my thinking anyway.
-Gedare

> Thanks,
> -Bob
>
> ---- Original message ----
>
> Date: Wed, 10 Mar 2010 09:31:34 -0600
> From: Joel Sherrill <joel.sherrill at oarcorp.com>
> Subject: Re: Dumb Question - Linkcmds and Heap initialization
> To: "rsg at alum.mit.edu" <rsg at alum.mit.edu>
> Cc: RTEMS Mailing List <rtems-users at rtems.org>
>>On 03/10/2010 09:07 AM, Robert S. Grimes wrote:
>>> Okay, some clarification and news...
>>>
>>> 1. Some of the output, such as the "calling ..." and
>>> "bsp_pretasking_hook called..." are simple printk debugging messages I
>>> had added.
>>>
>>> 2. I've added some more debugging calls that indicate the heap walker
>>> is being called from malloc, but there is no evidence that the heap
>>> was ever initialized to begin with. This certainly would explain the
>>> following messages!
>>>
>>> It seems the problem lies within the BSP startup, or maybe what the
>>> RTEMS startup sequence expects from the BSP (and how linkcmds affects
>>> that, I suppose). So, my questions become thus:
>>>
>>> 1. When (and where) is the heap set up?
>>>
>>In 4.10, this is much neater and easier to answer since it
>>is done in the same way across the BSPs. But in 4.9, the
>>code was in each BSP.
>>
>>virtex/startup/bspstart.c has the code which does the heap in
>>bsp_pretasking_hook. Workspace is carved out in bsp_start().
>>
>>It is possible that moving the base address up somehow caused
>>an overlap. Is the section .textrom in the linker script causing issues?
>>
>>Check that the workspace, heap, interrupt stack , .bss, etc do not overlap.
>>Make a good memory map.
>>
>>Check for overlaps. :)
>>> 2. Is it possible that an uninitialized heap could actually work?
>>>
>>No. :)
>>> 3. How could the start location of .text cause an (presumably
>>> uninitialized) heap to either work or not?
>>>
>>It could mess up the math in the BSP.
>>> 4. Again, I'm using powerpc/virtex BSP, under 4.9.0; has the startup
>>> been changed such that this problem has already been addressed?
>>>
>>If there was one of the common overlaps, it would be caught
>>and reported now. If there was a math error, it would have been
>>eliminated as that code is now shared across more BSPs.
>>
>>The old way had per BSP duplication of this and led to unique
>>ways of doing it and unique bugs. :)
>>
>>--joel
>>> Thanks again,
>>> -Bob
>>> Robert S. Grimes
>>>
>>> RSG Associates
>>> Embedded Systems and Software Development
>>> for Military, Aerospace, Industry - and beyond!
>>> 617.697.8579
>>> www.rsgassoc.com
>>>
>>>
>>
>>
>>--
>>Joel Sherrill, Ph.D. Director of Research& Development
>>joel.sherrill at OARcorp.com On-Line Applications Research
>>Ask me about RTEMS: a free RTOS Huntsville AL 35805
>> Support Available (256) 722-9985
>>
>>
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>
>