* re: malloc always returns null
@ 2008-07-20 2:44 Duane Ellis
2008-07-20 22:54 ` Ted Phares
2008-07-23 0:46 ` Ted Phares
0 siblings, 2 replies; 9+ messages in thread
From: Duane Ellis @ 2008-07-20 2:44 UTC (permalink / raw)
To: tphares, gcc-help
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;
}
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: malloc always returns null
2008-07-20 2:44 malloc always returns null Duane Ellis
@ 2008-07-20 22:54 ` Ted Phares
2008-07-20 23:05 ` Duane Ellis
2008-07-23 0:46 ` Ted Phares
1 sibling, 1 reply; 9+ messages in thread
From: Ted Phares @ 2008-07-20 22:54 UTC (permalink / raw)
To: duane-gcc-help; +Cc: gcc-help
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: malloc always returns null
2008-07-20 22:54 ` Ted Phares
@ 2008-07-20 23:05 ` Duane Ellis
2008-07-20 23:21 ` Ted Phares
0 siblings, 1 reply; 9+ messages in thread
From: Duane Ellis @ 2008-07-20 23:05 UTC (permalink / raw)
To: Ted Phares; +Cc: gcc-help
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: malloc always returns null
2008-07-20 23:05 ` Duane Ellis
@ 2008-07-20 23:21 ` Ted Phares
2008-07-21 6:18 ` Duane Ellis
0 siblings, 1 reply; 9+ messages in thread
From: Ted Phares @ 2008-07-20 23:21 UTC (permalink / raw)
To: duane-gcc-help; +Cc: gcc-help
>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: malloc always returns null
2008-07-20 23:21 ` Ted Phares
@ 2008-07-21 6:18 ` Duane Ellis
0 siblings, 0 replies; 9+ messages in thread
From: Duane Ellis @ 2008-07-21 6:18 UTC (permalink / raw)
To: Ted Phares; +Cc: gcc-help
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: malloc always returns null
2008-07-20 2:44 malloc always returns null Duane Ellis
2008-07-20 22:54 ` Ted Phares
@ 2008-07-23 0:46 ` Ted Phares
1 sibling, 0 replies; 9+ messages in thread
From: Ted Phares @ 2008-07-23 0:46 UTC (permalink / raw)
To: duane-gcc-help; +Cc: gcc-help
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: malloc always returns null
2008-07-19 13:12 ` Andrew Haley
@ 2008-07-19 21:54 ` Ted Phares
0 siblings, 0 replies; 9+ messages in thread
From: Ted Phares @ 2008-07-19 21:54 UTC (permalink / raw)
To: Andrew Haley; +Cc: gcc-help
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: malloc always returns null
2008-07-19 0:48 Ted Phares
@ 2008-07-19 13:12 ` Andrew Haley
2008-07-19 21:54 ` Ted Phares
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Haley @ 2008-07-19 13:12 UTC (permalink / raw)
To: Ted Phares; +Cc: gcc-help
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* malloc always returns null
@ 2008-07-19 0:48 Ted Phares
2008-07-19 13:12 ` Andrew Haley
0 siblings, 1 reply; 9+ messages in thread
From: Ted Phares @ 2008-07-19 0:48 UTC (permalink / raw)
To: gcc-help
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) }
}
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-07-22 20:18 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-20 2:44 malloc always returns null Duane Ellis
2008-07-20 22:54 ` Ted Phares
2008-07-20 23:05 ` Duane Ellis
2008-07-20 23:21 ` Ted Phares
2008-07-21 6:18 ` Duane Ellis
2008-07-23 0:46 ` Ted Phares
-- strict thread matches above, loose matches on Subject: below --
2008-07-19 0:48 Ted Phares
2008-07-19 13:12 ` Andrew Haley
2008-07-19 21:54 ` Ted Phares
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).