From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30227 invoked by alias); 22 Dec 2012 11:00:28 -0000 Received: (qmail 30211 invoked by uid 22791); 22 Dec 2012 11:00:27 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_00,KHOP_DNSBL_BUMP,KHOP_THREADED,RCVD_IN_MSPIKE_BL,RCVD_IN_MSPIKE_L3 X-Spam-Check-By: sourceware.org Received: from tirion.supremecenter202.com (HELO tirion.supremecenter202.com) (209.25.195.243) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 22 Dec 2012 11:00:21 +0000 Received: from [195.189.206.101] (port=55314 helo=[192.168.209.11]) by tirion.supremecenter202.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TmMoW-0008JC-I2; Sat, 22 Dec 2012 11:00:20 +0000 Message-ID: <50D592C0.8090806@siva.com.mk> Date: Sat, 22 Dec 2012 11:00:00 -0000 From: Ilija Kocho User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Jones CC: eCos Discussion References: <50D2CCFE.4030800@dallaway.org.uk> <50D32FEE.8070309@dallaway.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Eclipse / CDT without Makefile Project X-SW-Source: 2012-12/txt/msg00047.txt.bz2 Hi Mike >From my experience I have noticed that when debugging with Redboot, it is important to supply target file (path) to the invoking GDB command line. Some Eclipse front ends don't do that. You can try to add target path to the GDB command (Debug configurations -> Debugger). Ilija On 21.12.2012 08:03, Michael Jones wrote: > John, > > So now I am struggling getting GDB to work from Eclipse. It is actually a very interesting problem. > > I can load my app from gdb on the command line and run it fine. > > When I load the same app from Eclipse, I get a SIGTRAP at the the reset vector. > > reset_vector: > > ldr sp,=hal_startup_stack > b hal_reset_vsr > > Stops at the ldr instruction no matter how many times I do a continue. > > This is the same problem I had when I was using Insight. That problem was finally diagnosed. When I compiled Insight, it replaced the arm-eabi-gdb file, and when I reverted back to the one from the tool chain, the problem went away. > > In this case, I am sure that Eclipse is using the same are-eabi-gdb because I can do a "show version" in the Eclipse command window and get the same revision as the working command line. > > There appears to be something very subtle different. As an experiment, I selected my file and loaded my app from the eclipse command line so the GUI was eliminated. I get the same SIGTRAP. And after download, the memory segments are all in the same place. > > Do you have any ideas on how to debug this kind of problem? Is it possible that when I use commands like "load" and "cont" what is sent to RedBoot at the other end is different? Could there be hidden communications that change the mode of RedBoot? Could the memory contents after a load be different? Could GDB in the Eclipse environment be inserting some kind of trap like a break point that it is failing to remove when I type "cont"? > > I have to admit, I was not so surprised that a newer version of GDB mis-behaved, but I was really surprised that a working version of gdb running in Eclipse would not behave the same. > > Mike > > > On Dec 20, 2012, at 8:34 AM, John Dallaway wrote: > >> Mike >> >> On 20/12/12 15:15, Michael Jones wrote: >> >>> Thanks, now it is closer. I have provided the output showing the final failure: >>> >>> /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find crt0.o: No such file or directory >>> /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find -lg >>> /opt/ecos/gnutools/arm-eabi/lib/gcc/arm-eabi/4.6.3/../../../../arm-eabi/bin/ld: cannot find -lc >>> collect2: ld returned 1 exit status >>> make: *** [Sources/hello.o] Error 1 >>> >>> 07:56:20 Build Finished (took 929ms) >>> >>> What is interesting is that even with the -L option, it does not show up in the compile output. >>> >>> The rule it makes in the makefile is >>> >>> hello_world: $(OBJS) $(USER_OBJS) >>> @echo 'Building target: $@' >>> @echo 'Invoking: Cross GCC Linker' >>> arm-eabi-gcc -nostartfiles -nodefaultlibs -nostdlib -static -mcpu=cortex-m3 -mthumb -Wl,--gc-sections -Wl,-static -Wl,-n -g -v -nostdlib -L../../ecos/TWR-K60D100M_install/lib -T../../ecos/TWR-K60D100M_install/lib/target.ld -o "hello_world" $(OBJS) $(USER_OBJS) $(LIBS) >>> @echo 'Finished building target: $@' >>> @echo ' ' >>> >>> Somehow it does not get passed on to the linker. >> I believe your build is not getting as far as the above makefile rule. >> You are missing the "-c" flag on your _compilation_ line, so GCC is >> attempting to both compile and link (using a default linker script) the >> first time it is invoked. >> >> I hope this helps... >> >> John Dallaway >> eCos maintainer >> http://www.dallaway.org.uk/john >> >> -- >> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos >> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss >> > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss