From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32705 invoked by alias); 8 Jun 2006 21:37:30 -0000 Received: (qmail 32672 invoked by uid 22791); 8 Jun 2006 21:37:28 -0000 X-Spam-Check-By: sourceware.org Received: from mail.s.netic.de (HELO mail.s.netic.de) (212.9.160.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 Jun 2006 21:37:20 +0000 Received: from host-213-178-187-11.dsl.netic.de ([213.178.187.11] helo=schleim.qwe.de) by mail.s.netic.de with esmtp (Exim 4.51) id 1FoSBq-000KNf-8t; Thu, 08 Jun 2006 23:37:18 +0200 Received: from localhost (localhost [IPv6:::1]) by schleim.qwe.de (Postfix) with ESMTP id E0BE93B4C3; Thu, 8 Jun 2006 23:41:12 +0200 (CEST) From: Torsten Mohr To: newlib@sourceware.org, gdb@sourceware.org Subject: Re: malloc() never returns Date: Thu, 08 Jun 2006 21:50:00 -0000 User-Agent: KMail/1.8 Cc: Jeff Johnston References: <200606081246.20231.tmohr@s.netic.de> <44886BBF.1030404@redhat.com> In-Reply-To: <44886BBF.1030404@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606082341.12598.tmohr@s.netic.de> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00059.txt.bz2 Hi, > It appears your static av_ array has been cleared. Perhaps you have > gone too far when clearing the .bss. Track the static av_ array and see > where it ends up after linking as well as what is in it. That array > should be initialized and non-zero by the time you get to main. I don't > have any experience with the v850 platform to give you any other direct > suggestions. thanks for your hint, it looks like you're right. The array ___malloc_av_ is located in .data at 0x3ffe40c. Or more precisely this is its VMA. In my linker script i use the common way to place data into ROM: .data : { *(.data) *(.data.*) *(.gnu.linkonce.d*) CONSTRUCTORS } > ram AT > rom When i verify it with v850e-unknown-elf-objdump -h | grep .data 7 .data 00000828 03ffe000 000071a8 00009000 2**2 Also, in hw2.srec at the expected offset of 0x040c (address of ___malloc_av_ - VMA(.data)) i see the expected data (at LMA(.data) + 0x40c): S315000075A800000000FFFFFFFF0000020000000000CF S315000075B8000000000CE4FF030CE4FF0314E4FF03DF S315000075C814E4FF031CE4FF031CE4FF0324E4FF03A5 ... So all fits fine, except: When i load the ELF file in "insight", i see the array ___malloc_av_ filled correctly, but after .data gets copied its all filled with 0x00. So is it possible that GDB loads the sections in the ELF file to the VMA and not to the LMA? It looks to me like this, but this means that no program that uses "> RAM AT > ROM" can run correctly in GDB, right? Is there a standard solution to this standard problem? Or do i misunderstand something here? Best regards, Torsten.