Trouble using malloc on ARM (Yagarto)

Hi,

I am using Yagarto tools for ARM development (AT91SAM7S64). Everything seems to be OK, except that when I use malloc the returned pointer points to

0x00000008 regardless of the amount of bytes that I want to allocate. I have read the newsgroups, but nothign seems to help.

I need your advice with my .ld file, in order to know what could be messed / missing and how to fix it. Other suggestions are welcome too.

/ *--------------------------------------------------------------------------- */ /*- ATMEL Microcontroller Software Support - ROUSSET - */ / *--------------------------------------------------------------------------- */ /* The software is delivered "AS IS" without warranty or condition of any */ /* kind, either express, implied or statutory. This includes without */ /* limitation any warranty or condition with respect to merchantability or */ /* fitness for any particular purpose, or against the infringements of */ /* intellectual property rights of others. */ / *--------------------------------------------------------------------------- */ /*- File source : GCC_FLASH.ld */ /*- Object : Linker Script File for Flash Workspace */ /*- Compilation flag : None */ /*- */ /*- 1.0 20/Oct/04 JPP : Creation */ / *--------------------------------------------------------------------------- */

/* slightly modified for the WinARM example - M.Thomas (not Atmel) */

/* //*** > ***

*/

/* // Memory Configuration // Code (Read Only) // Start // Size // // Data (Read/Write) // Start // Size // // Top of Stack (Read/Write) // STACK // //

*/

/* Memory Definitions */

/* mt change code origin from 0x00000000 */ MEMORY { CODE (rx) : ORIGIN = 0x00100000, LENGTH = 0x00010000 DATA (rw) : ORIGIN = 0x00200000, LENGTH = 0x00002800 STACK (rw) : ORIGIN = 0x00202800,LENGTH = 0x00001800 }

/* Section Definitions */

SECTIONS { /* first section is .text which is used for code */ . = 0x0000000; .text : { *cstartup.o (.text) }>CODE =0 .text : { *(.text) /* remaining code */

*(.glue_7t) *(.glue_7)

} >CODE =0

. = ALIGN(4);

/* .rodata section which is used for read-only data (constants) */

.rodata : { *(.rodata) } >CODE

. = ALIGN(4);

_etext = . ; PROVIDE (etext = .);

/* .data section which is used for initialized data */

.data : AT (_etext) { _data = . ; *(.data) SORT(CONSTRUCTORS) } >DATA . = ALIGN(4);

_edata = . ; PROVIDE (edata = .);

/* .bss section which is used for uninitialized data */

.bss : { __bss_start = . ; __bss_start__ = . ; *(.bss) *(COMMON) } . = ALIGN(4); __bss_end__ = . ; __bss_end__ = . ; _end = .; . = ALIGN(4); .int_data : { *(.internal_ram_top) }> STACK

PROVIDE (end = .);

/* Stabs debugging sections. */ .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } .stab.excl 0 : { *(.stab.excl) } .stab.exclstr 0 : { *(.stab.exclstr) } .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .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) } /* SGI/MIPS DWARF 2 extensions */ .debug_weaknames 0 : { *(.debug_weaknames) } .debug_funcnames 0 : { *(.debug_funcnames) } .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) }

}

Regards,

--
Jaime Andres Aranguren C.
SanJaaC Electronics
 Click to see the full signature
Reply to
Jaime Andrés Aranguren Cardona
Loading thread data ...

*---------------------------------------------------------------------------
*---------------------------------------------------------------------------
*---------------------------------------------------------------------------
*---------------------------------------------------------------------------

Does it always return 0x00000008 regardless of how many times you've called malloc, or regardless of how much you've asked for? The former would be a problem; the latter is only a problem if that's not where you're supposed to be allocating heap. Since I'm not terribly familiar with the ARM, I don't know if there's a problem with having heap memory at 0x00000008.

I would expect most malloc routines to return the same address on the very first call, to me that's normal behavior.

--
Tim Wescott
Control systems and communications consulting
 Click to see the full signature
Reply to
Tim Wescott

exto de la cita -

Hello Tim, thanks for showing up.

Yes: we have a problem here. It returns 0x00000008 regardless of how many times I call malloc and how much I ask for. It _always_ returns

0x00000008.

I guess it has to do with the linker file, but I am not so much of a master with them to find out what has to be fixed.

Any help is appreciated.

Thanks.

Reply to
Jaime Andrés Aranguren Cardona

[Linker file snipped]

AFAIK Yagarto uses newlib. For everything to work in newlib, there are a few stubs that must be provided for newlib. One of the stubs concern malloc. It might be that the stubs provided for newlib is not complete enough for your application.

Look at

formatting link
for a bit more detail.

Regards Anton Erasmus

Reply to
Anton Erasmus

This may be too late to help the original poster, but I just came across the same issue. The problem was that sbrk was called before malloc_init, so sbrk had null pointers for beginning and end of heap memory.

george

former

familiar

consulting

formatting link

t=

--------------------------------------- This message was sent using the comp.arch.embedded web interface on

formatting link

Reply to
najay

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.