From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13730 invoked by alias); 14 Nov 2002 20:08:58 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 13723 invoked from network); 14 Nov 2002 20:08:56 -0000 Received: from unknown (HELO exchwenz01.smtp.dmcwave.co.nz) (202.27.34.1) by sources.redhat.com with SMTP; 14 Nov 2002 20:08:56 -0000 Received: by exchwenz01.dmcwave.co.nz with Internet Mail Service (5.5.2656.59) id ; Fri, 15 Nov 2002 09:08:54 +1300 Message-ID: <8D7C5F56B409554D9D46AC22195807F3061B69@exchwenz01.dmcwave.co.nz> From: Rod Boyce To: 'Tim' , Rod Boyce Cc: 'Fernando Nasser' , insight@sources.redhat.com Subject: RE: Source lines out of sync with instructions Date: Thu, 14 Nov 2002 12:08:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2002-q4/txt/msg00110.txt.bz2 >From what I can see in your makefile the dependencies are hand coded. Are you sure these are all the dependencies? Have you tied compiling on a different machine? Have you tired debugging on a different machine? Are you sure that the instructions are not just being executed out of order? These are all C++ files are you sure that your classes and / or threads are not changing the order? I'm not sure about Intel machines but our embedded envoriment and the RISC processor reorders instructions and does all sorts of tricks to increase speed it can be interesting to debug. These are all things that have nothing to do with GDB. I'm sure others on this list can think up many more questions these are just the obvious questions. The fault could also lie with GDB. Are you using a GDB that came with your distribution? If you recompiled GDB then what options did you use? Are you sure you are using the latest released version of GDB? Have you thoroughly searched the mailing list archives on both the GDB and insight mailing list? The same applies to these questions I'm sure there are many more others on this list can think up. Are you sure this is not a known problem with your version of GDB / insight? Rod -----Original Message----- From: Tim [mailto:Tim@deltacompsys.com] Sent: Thursday, November 14, 2002 11:28 AM To: Rod Boyce Cc: 'Fernando Nasser'; insight@sources.redhat.com Subject: RE: Source lines out of sync with instructions Here is my make file ... see anything wrong with it? ARCH = CC = $(ARCH)gcc CXX = $(ARCH)g++ CFLAGS = -Wall -ggdb -O0 -I .. -DHANDLE_PRAGMA_PACK_PUSH_POP=1 -DHANDLE_SYSV_PRAGMA=1 -fsigned-char LDFLAGS = -ggdb -O0 LIBS = STRIP = $(ARCH)strip LDD = $(ARCH)ldd OBJFILES = objs/main.o \ objs/MSTerminal.o \ objs/QTerm.o \ objs/Serial.o \ objs/MemManager.o \ objs/MenuObjs.o \ objs/Summary.o \ objs/SSheet.o \ objs/ParamSS.o TARGET = msterminal msterminal: $(OBJFILES) $(CC) $(LDFLAGS) $(OBJFILES) $(LIBS) -o $(TARGET) objs/main.o: main.cc main.h MSTerminal.h $(CXX) $(CFLAGS) main.cc -o objs/main.o -c objs/MSTerminal.o: MSTerminal.cc MSTerminal.h main.h $(CXX) $(CFLAGS) MSTerminal.cc -o objs/MSTerminal.o -c objs/QTerm.o: QTerm.cc QTerm.h ../Serial.h $(CXX) $(CFLAGS) QTerm.cc -o objs/QTerm.o -c objs/Serial.o: ../Serial.cc ../Serial.h $(CXX) $(CFLAGS) ../Serial.cc -o objs/Serial.o -c objs/MemManager.o: ../MemManager.cc ../MemManager.h ../SharedData.h $(CXX) $(CFLAGS) ../MemManager.cc -o objs/MemManager.o -c objs/MenuObjs.o: MenuObjs.cc MenuObjs.h MenuHdr.h MenuTbl.h Summary.h ParamSS.h $(CXX) $(CFLAGS) MenuObjs.cc -o objs/MenuObjs.o -c objs/Summary.o: Summary.cc Summary.h $(CXX) $(CFLAGS) Summary.cc -o objs/Summary.o -c objs/SSheet.o: SSheet.cc SSheet.h $(CXX) $(CFLAGS) SSheet.cc -o objs/SSheet.o -c objs/ParamSS.o: ParamSS.cc ParamSS.h SSheet.h $(CXX) $(CFLAGS) ParamSS.cc -o objs/ParamSS.o -c clean: rm -f $(TARGET) cd objs rm -f $(OBJFILES) cd .. On Thu, 2002-11-14 at 10:29, Rod Boyce wrote: > More importantly and the first thing you should try before asking question > you should do a make clean and then a make. I find this problem is 999 out > of a 1000 is caused by dependencies not being compiled correctly after > changes to source code. This usually means you make file is not working > correctly and cannot determine what has changed in your source. This > includes everything from clock synchronization to not being able to write a > correct make file I have seen more bad makefiles than good makefiles. > > I would strongly suggest deleting all object files and rebuilding this > should be the first step before asking this kind of question on ANY list. > > > Regards, > Rod > > > > -----Original Message----- > From: Fernando Nasser [mailto:fnasser@redhat.com] > Sent: Thursday, November 14, 2002 10:23 AM > To: Tim; insight@sources.redhat.com > Subject: Re: Source lines out of sync with instructions > > Can you try and run without the GUI? If when you say step and get into your > > subroutine you see the same problem (use the list command to print the > source > lines or look at what was printed by gdb when it stopped -- usually a line > number but you may get an hex address instead/as well). > > Maybe the version of GDB you are using has a problem with your architecture > (insight is just a GUI to the GNU debugger, which still does the actual > breakpoint debugging). Is this i386, MIPS, or what? > > Regards, > Fernando > > > Tim wrote:> Thanx! tried -O0 with no luck. Things are still out of sync. > It > > appears to happen only after I step into a new compilation unit. That > > is, in main everything is fine, but when I break or step into the next > > compilation unit things get messed up. > > > > Any other thoughts? > > > > On Thu, 2002-11-14 at 09:45, Fernando Nasser wrote: > > > >>Tim wrote:> I have seen this with gdb console so I don't think it is a > problem with > >> > >>>insight, but perhaps someone can help me. > >>> > >>>When I'm debugging the source code lines get out of sync with the actual > >>>instructions. Why is this and more importantly how do I stop it? > >>> > >>>Thanx! > >> > >>Try compiling your program without optimization... > >> > > > -- > Fernando Nasser > Red Hat - Toronto E-Mail: fnasser@redhat.com > 2323 Yonge Street, Suite #300 > Toronto, Ontario M4P 2C9 >