[Fwd: alloc problem?]

[J. Johnston]

Bryce,

   Your ld script seems messed up.  You have your stack starting at the same 
location as your heap.  The heap starts at _end and moves up.  The stack starts 
at _stack and moves down.  In your ld script you have your stack preceding your 
heap.  You should be placing your stack high above your heap as they will both 
eat into this storage.  Your low-level sbrk function should check for collision.

   If you issue an arm-elf-ld with the --verbose option and no files, you can 
see the default ld script which you can use as a basis for writing your own if 
you like.  You should use this as a basis for your script.  I have attached the 
default script for a really old arm-elf build I have lying around.

Note how the stack starts up high at 0x80000.

-- Jeff J.

Bryce Schober wrote:
> Ping.
> 
> Bryce Schober wrote:
> 
>> I haven't gotten anything on the crossgcc list, so I'm going to 
>> cross-post this here.  FYI, the toolchain is gcc-3.3 / newlib-1.11.0.
>>
>> Thanks for any advice you can give me.
>>
>> -------- Original Message --------
>> Subject: alloc problem?
>> Date: Wed, 12 Nov 2003 15:12:14 -0800
>> From: Bryce Schober <bryceman@dpzone.com>
>> To: crossgcc@sources.redhat.com
>>
>> Our arm-elf project here has been plagued with problems when trying to 
>> use
>> sprintf.  We've gotten by without it by writing some of our own 
>> conversion
>> functions, but ideally we'd be able to use c++, which would need use 
>> alloc a
>> lot.  My instinct tells me that alloc is the problem, because the 
>> problems we've
>> had with sprintf are fairly unpredictable and it's the only function 
>> that we're
>> using that needs an alloc.  Furthermore, I suspect that the root of 
>> the problem
>> may be our linker script (because the wierd behavior of sprintf has 
>> seemed to
>> variy with program size at times), but I know little about linker 
>> scripts, and
>> nothing about what the alloc functions require of one.
>>
>> Here's our linker script:
>>
>> SEARCH_DIR("/usr/local/src/arm-elf-gcc-combined/installs-combined/arm-elf/lib"); 
>>
>> SECTIONS
>> {
>>     . = 0x00008000;
>>     ER_RO : { *(ER_RO) }
>>     .text : { *(.text ) }
>>     .rodata : { *(.rodata) }
>>     .data : { *(.data) }
>>     __bss_start__ = .;
>>     .bss : { *(.bss) }
>> /*    __sbss_start = .; */
>>     /*__sbss_end = .; */
>>     __bss_end__ = .;
>>     . += 0x4000;
>>
>> PROVIDE (__stack = .);
>>     _end = .;
>>     end = .;
>> /*
>>     .debug_info     0 : { *(.debug_info) }
>>        .debug_abbrev   0 : { *(.debug_abbrev) }
>>        .debug_line     0 : { *(.debug_line) }
>>        .debug_frame    0 : { *(.debug_frame) }
>> */
>> /*       .debug_str      0 : { *(.debug_str) } */
>> /*       .debug_loc      0 : { *(.debug_loc) } */
>> /*       .debug_macinfo  0 : { *(.debug_macinfo) } */
>> }
>>
>>
> 
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ldscript
URL: <http://sourceware.org/pipermail/newlib/attachments/20031123/4e714cae/attachment.ksh>