Dumb Question - Linkcmds and Heap initialization
gedare at gwu.edu
Wed Mar 10 16:45:29 UTC 2010
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) &
> 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.
> ---- 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?
>>> 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. :)
>>> Thanks again,
>>> Robert S. Grimes
>>> RSG Associates
>>> Embedded Systems and Software Development
>>> for Military, Aerospace, Industry - and beyond!
>>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
More information about the users