From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29582 invoked by alias); 28 Oct 2003 09:25:41 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 29573 invoked from network); 28 Oct 2003 09:25:39 -0000 Received: from unknown (HELO urano.sidsa.es) (195.53.86.130) by sources.redhat.com with SMTP; 28 Oct 2003 09:25:39 -0000 Received: from sidsa.es ([195.53.86.199]) by urano.sidsa.es (8.12.10/8.11.4) with ESMTP id h9S9Bbit030146 for ; Tue, 28 Oct 2003 10:11:37 +0100 Message-ID: <3F9E3660.3050504@sidsa.es> Date: Tue, 28 Oct 2003 09:25:00 -0000 From: =?ISO-8859-1?Q?Rub=E9n_P=E9rez_de_Aranda_Alonso?= Organization: SIDSA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecos-discuss@sources.redhat.com References: <3F9CDCE5.9000106@sidsa.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [ECOS] Execution of constructors in at91 X-SW-Source: 2003-10/txt/msg00473.txt.bz2 Nick Garnett wrote: >Rubén Pérez de Aranda Alonso writes: > > > >>Hello, >> >> > > > > >>I am working with the at91 eb40 porting of eCOS to develop another >>port for a prototype based on the same microcontroller. I now use >>the EmbeddedIce pod to debug the eCOS and execute the tests of the >>different parts and layers, but I would like use the Redboot and its >>GDB stub because it allows me write the falsh chips and the >>comunication with the host is faster. I have installed a redboot >>image in flash. With the load command in GDB I upload the >>application in the RAM memory that has been compiled to be executed >>in RAM and with a ROM monitor. The problem is when the eCOS startup >>code calls to the cyg_hal_invoke_constructors() function. This >>function uses the symbols allocated by the linker, __CTOR_LIST__ and >>__CTOR_END__, to know the address of the constructors belonging to >>*.ctors binary sections of the different object files. The function >>calls to these constructors without verify if the function pointer >>points to NULL, so the pc register branch to the 0x0 address and >>execute the reset vector. >> >> > >There should not be NULL pointers in the constructor table. So the >thing to do is find out why they are there. Make sure you have not >corrupted the linker script in some way. Also, add the option >"-Wl,-Map,map" to the linker options, take a look at the map file >produced and see where the sections being added to the constructor >table are coming from. > > > > > Yesterday I found the problem. When the firmware is configured with RAM startup the vectors.S does not contains the code to initialize the .data section and the .ctors and .dtors sections of the object files are allocated in the .data section of the final binary file. I had configured the linker script with LMA != VMA and RAM startup. Another problem is when the the stack pointer of the stub code overlaps the .bss and/or .data sections of the application which are being debugged. I resolved this adding a bigger offset in the sram shared by the stub and the application. I seen this behaviour debugging the ROM monitor throught the Embedded ICE at the same time I was debugging the application with the ROM monitor throught the serial port of the target. -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss