malloc always returns null

malloc always returns null

[Ted Phares]

Hi,

I'm attempting to configure the gcc 4.0.3 tool chain to compile c++ 
source on an ARM 9 (ARM926-ejs) target.  At this point, everything seems 
to be working except malloc:  It always returns the null pointer.

I'm wondering if I've correctly configured my .ld script indicate the 
location and size of the heap.  It was put together with a bit of 
guesswork & patching together examples for other targets, since it's not 
clear to me what symbols malloc() relies upon for locating the heap (is 
this documented somewhere?).

Below are the command lines i'm using for compile/assemble/link & the ld 
script.  Do they look substantially complete?

Thanks,

-ted



Command lines:
================================================================

gcc.exe -c -gdwarf-2 -MD -O0 -mapcs-frame -trigraphs -mcpu=arm926ej-s -w 
-Wall  -fsigned-char  -xc++  -mlittle-endian  -marm  -mthumb-interwork 
-mtune=arm926ej-s -mlong-calls -o .\objects\mySourceFile.o mySourceFile.cpp
as.exe -mcpu=arm9e -gdwarf2  -EL  -mthumb-interwork  .\objects\startup.o 
.\source\startup.s
ld.exe  -T.\Settings\my_ld_script.ld --cref -t -static -lstdc++ -lm -lc 
-lgcc -nostartfiles -Map=my_program.map   -o .\objects\my_program.elf


ld script:
================================================================

MEMORY
{
   INTRAM(rwx) : ORIGIN = 0x00000004, LENGTH = 0x1FFFC /* this isn't used */
   SDRAM(rwx)  : ORIGIN = 0x80000000, LENGTH = 0x00800000 /* this is the 
memory i'm using */
}

SECTIONS
{
   .text :
   {
     __code_start__ = .;

     objects\startup.o (.text)         /* Startup code */
     objects\*.o       (.text)

     . = ALIGN(4);
     __code_end__ = .;

     *(.gnu.linkonce.t.*)
   	*(.glue_7)
   	*(.glue_7t)
   	*(.gcc_except_table)
   	*(.gnu.linkonce.r.*)

   } >SDRAM

   . = ALIGN(4);

   /* .rodata section which is used for read-only data (constants) */
   .rodata . :
   {
     *(.rodata)
   } >SDRAM

	.ctors :
	{
		PROVIDE(__ctors_start__ = .);
		KEEP(*(SORT(.ctors.*)))
		KEEP(*(.ctors))
		PROVIDE(__ctors_end__ = .);
	} >SDRAM

	.dtors :
	{
		PROVIDE(__dtors_start__ = .);
		KEEP(*(SORT(.dtors.*)))
		KEEP(*(.dtors))
		PROVIDE(__dtors_end__ = .);
	} >SDRAM

   _etext = . ;
   PROVIDE (etext = .);

   .data :
   {
     /* used for initialized data */
     __data_start__ = . ;
     PROVIDE (__data_start__ = .) ;
     *(.data)
    	*(.data.*)
	  *(.gnu.linkonce.d*)

     SORT(CONSTRUCTORS)
     __data_end__ = . ;
     PROVIDE (__data_end__ = .) ;
   } >SDRAM
   . = ALIGN(4);

   _edata = . ;
   PROVIDE (edata = .);

   .bss :
   {
     /* used for uninitialized data */

     __bss_start = . ;
     __bss_start__ = . ;
     *(.bss)
     *(.gnu.linkonce.b*)
     . = ALIGN(4);
     __bss_end__ = . ;

   } >SDRAM

   .bss2 :
   {
     /* used for uninitialized data */

     __bss2_start = . ;
     __bss2_start__ = . ;
     *(COMMON)
     . = ALIGN(4);
     __bss2_end__ = . ;

   } >SDRAM

   .stack ALIGN(256) :
   {
     . += 0x00100000;
     PROVIDE (_stack = .);
   } > SDRAM

   .heap :
   {
    PROVIDE (end = .);PROVIDE (__end__ = .);PROVIDE (_end = .);
    *(.heap)
    PROVIDE (heap_limit = . );
   } >SDRAM

   .comment       0 : { *(.comment) }
   /* DWARF debug sections.
      Symbols in the DWARF debugging sections are relative to the beginning
      of the section so we begin them at 0.  */
   /* DWARF 1 */
   .debug          0 : { *(.debug) }
   .line           0 : { *(.line) }
   /* GNU DWARF 1 extensions */
   .debug_srcinfo  0 : { *(.debug_srcinfo) }
   .debug_sfnames  0 : { *(.debug_sfnames) }
   /* DWARF 1.1 and DWARF 2 */
   .debug_aranges  0 : { *(.debug_aranges) }
   .debug_pubnames 0 : { *(.debug_pubnames) }
   /* DWARF 2 */
   .debug_info     0 : { *(.debug_info .gnu.linkonce.wi.*) }
   .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) }
}

Re: malloc always returns null

[Andrew Haley]

Ted Phares wrote:
> Hi,
> 
> I'm attempting to configure the gcc 4.0.3 tool chain to compile c++
> source on an ARM 9 (ARM926-ejs) target.  At this point, everything seems
> to be working except malloc:  It always returns the null pointer.
> 
> I'm wondering if I've correctly configured my .ld script indicate the
> location and size of the heap.  It was put together with a bit of
> guesswork & patching together examples for other targets, since it's not
> clear to me what symbols malloc() relies upon for locating the heap (is
> this documented somewhere?).
> 
> Below are the command lines i'm using for compile/assemble/link & the ld
> script.  Do they look substantially complete?

Questions like this really need the expertise of the binutils list.

Andrew.

Re: malloc always returns null

[Ted Phares]

Thanks for the suggestion, however I'm not sure what list you're 
referring to.  Can you provide a link?

Thanks,

-ted


Andrew Haley wrote:
> Ted Phares wrote:
>> Hi,
>>
>> I'm attempting to configure the gcc 4.0.3 tool chain to compile c++
>> source on an ARM 9 (ARM926-ejs) target.  At this point, everything seems
>> to be working except malloc:  It always returns the null pointer.
>>
>> I'm wondering if I've correctly configured my .ld script indicate the
>> location and size of the heap.  It was put together with a bit of
>> guesswork & patching together examples for other targets, since it's not
>> clear to me what symbols malloc() relies upon for locating the heap (is
>> this documented somewhere?).
>>
>> Below are the command lines i'm using for compile/assemble/link & the ld
>> script.  Do they look substantially complete?
> 
> Questions like this really need the expertise of the binutils list.
> 
> Andrew.

re: malloc always returns null

[Duane Ellis]

ted> I'm attempting to configure the gcc 4.0.3 tool chain to compile c++ 
source on an ARM 9 (ARM926-ejs) target.  At this point, everything seems 
to be working except malloc:  It always returns the null pointer.

You do not state what you are using as your "standard C library". I 
assume "newlib" it is the most common embedded C library.

NEWLIB requires the underlying function: "_sbrk" - in syscalls, In "OS" 
type environment, SBRK would call the operating system requesting more 
memory.

In an embedded system using NEWLIB - the SBRK function has (a) a pointer 
to the current end of the heap, it sort of works like this:
Newlib impliments it this way:  (newlib source, libgloss, arm, syscalls.c)

You want to set a break point at _sbrk - and step through the code.
Examine the addresses of variables as you do this.

caddr_t
_sbrk (int incr)
{
  extern char end asm ("end"); /* Defined by the linker.  */
  static char * heap_end;
  char * prev_heap_end;

  if (heap_end == NULL)
    heap_end = & end;
 
  prev_heap_end = heap_end;
 
  if (heap_end + incr > stack_ptr)
    {
      /* Some of the libstdc++-v3 tests rely upon detecting
     out of memory errors, so do not abort here.  */
#if 0
      extern void abort (void);

      _write (1, "_sbrk: Heap and stack collision\n", 32);
     
      abort ();
#else
      errno = ENOMEM;
      return (caddr_t) -1;
#endif
    }
 
  heap_end += incr;

  return (caddr_t) prev_heap_end;
}    

Re: malloc always returns null

[Ted Phares]

> You do not state what you are using as your "standard C library". I 
> assume "newlib" it is the most common embedded C library.

I'm actually not sure.  I'm using binaries compiled by the vendor that 
supplied the hardware debug tool & development environment for my target 
system.

In the ld command line, I specify

  -lc -lgcc -lstdc++

In the ld script, I specify

  SEARCH_DIR("...\arm-hitex-elf\lib\interwork\arm926ej-s")
  SEARCH_DIR("...\arm-hitex-elf\4.0.3\interwork\arm926ej-s")

The contents of those directories are

crtbegin.o
crtend.o
crti.o
crtn.o
libgcc.a
libgcov.a

crt0.o
iq80310.specs
libc.a
libg.a
libiberty.a
libm.a
libnosys.a
librdimon.a
librdpmon.a
libstdc++.a
libstdc++.la
libsupc++.a
libsupc++.la
pid.specs
rdimon-crt0.o
rdimon.specs
rdpmon-crt0.o
rdpmon.specs
redboot-crt0.o
redboot-syscalls.o
redboot.ld
redboot.specs

Can the answer be inferred from this info?

-ted

Re: malloc always returns null

[Duane Ellis]

Ted Phares wrote:
>> You do not state what you are using as your "standard C library". I 
>> assume "newlib" it is the most common embedded C library.
>
> I'm actually not sure.  I'm using binaries compiled by the vendor that 
> supplied the hardware debug tool & development environment for my 
> target system.

Hm.. You paid for your GCC eh? 

You then probably paid for support from your GCC vendor. You should ask 
your vendor for the support you paid for.

But To answer your question - you do not give enough information.  You 
might go digging through the header files - looking at copyright 
statements. The key file you are looking for is "reent.h" - it is some 
what of a tell tail sign you are using newlib. Compare the copyright 
statements and the files with those in newlib.

Otherwise - you'll need to find the source to the library you are using 
so you debug your problem. Or - resort to disassembly :-( yuck

Your vendor who wants your business, or has your money should be able to 
help.

-Duane.

Re: malloc always returns null

[Ted Phares]

>> I'm actually not sure.  I'm using binaries compiled by the vendor that 
>> supplied the hardware debug tool & development environment for my 
>> target system.
> 
> Hm.. You paid for your GCC eh?
> You then probably paid for support from your GCC vendor. You should ask 
> your vendor for the support you paid for.

Indeed, we paid for a piece of hardware--a JTAG interface--that happened 
to come with GCC already set up to compile C (but, inexplicably, not 
C++) for this target.

Unfortunately, the vendor hasn't been very helpful, and it's looking 
like one of those situations where if I want it done now, I need to do 
it myself.  (I also don't mind going through this exercise--it's given 
me a much better understanding of gcc configuration.)

Thanks for your all your suggestions; I'll investigate further.

-ted

Re: malloc always returns null

[Duane Ellis]

Ted Phares wrote:
>>> I'm actually not sure.  I'm using binaries compiled by the vendor 
>>> that supplied the hardware debug tool & development environment for 
>>> my target system.
>>
>> Hm.. You paid for your GCC eh?
>> You then probably paid for support from your GCC vendor. You should 
>> ask your vendor for the support you paid for.
>
> Indeed, we paid for a piece of hardware--a JTAG interface--that 
> happened to come with GCC already set up to compile C (but, 
> inexplicably, not C++) for this target.
>
> Unfortunately, the vendor hasn't been very helpful, and it's looking 
> like one of those situations where if I want it done now, I need to do 
> it myself.  (I also don't mind going through this exercise--it's given 
> me a much better understanding of gcc configuration.)
>
> Thanks for your all your suggestions; I'll investigate further.
>

Check out:

    http://lostarm.sourceforge.net.

It might be helpful.  It does *NOT* support C++, the intent was "tiny 
platforms", C++ is bloat when you have less then 32K of ram & 256K flash.
Perhaps I should add C++ support. 

But... it shows you how to do all kinds of stuff.

-Duane.

Re: malloc always returns null

[Ted Phares]

> NEWLIB requires the underlying function: "_sbrk" - in syscalls, In "OS" 
> type environment, SBRK would call the operating system requesting more 
> memory.
> 
> In an embedded system using NEWLIB - the SBRK function has (a) a pointer 
> to the current end of the heap, it sort of works like this:
> Newlib impliments it this way:  (newlib source, libgloss, arm, syscalls.c)
> 
> You want to set a break point at _sbrk - and step through the code.
> Examine the addresses of variables as you do this.

Thank you, Duane.  You hit the nail on the head:  sbrk()'s check for 
stack-heap collision was failing, because the user stack area happened 
to be set up ahead of the heap area in my memory map.  I set up the more 
conventional arrangement where the heap & stack grow toward each other, 
and now malloc() is working.

Thanks again,

-ted