From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23617 invoked by alias); 6 Apr 2006 00:14:53 -0000 Received: (qmail 23608 invoked by uid 22791); 6 Apr 2006 00:14:53 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao01.cox.net (HELO eastrmmtao01.cox.net) (68.230.240.38) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Apr 2006 00:14:52 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060406001447.IZTU3988.eastrmmtao01.cox.net@localhost.localdomain> for ; Wed, 5 Apr 2006 20:14:47 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FRI9I-0004MM-1s for gdb@sources.redhat.com; Wed, 05 Apr 2006 20:14:56 -0400 Date: Thu, 06 Apr 2006 00:14:00 -0000 From: Bob Rossi To: gdb@sources.redhat.com Subject: Re: text file formats Message-ID: <20060406001455.GC11610@brasko.net> Mail-Followup-To: gdb@sources.redhat.com References: <20060405223122.GB11610@brasko.net> <20060405233938.GA11013@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060405233938.GA11013@nevyn.them.org> User-Agent: Mutt/1.5.9i 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-04/txt/msg00042.txt.bz2 On Wed, Apr 05, 2006 at 07:39:38PM -0400, Daniel Jacobowitz wrote: > On Wed, Apr 05, 2006 at 06:31:22PM -0400, Bob Rossi wrote: > > One thing I have determined, is that in order to know what the file > > format is, the entire text file needs to be parsed. After that, either > > the file format is defined (unix/dos/mac) or it is undefined (mix of > > them). > > > > I would like to make sure that the algorithm CGDB uses to determine > > the line number from a file is the same algorithm that GDB uses. Can > > anyone point me in the correct direction? > > GDB does something much simpler. It opens the file in text mode and > lets the C library sort it out. > > Well, usually. In search and reverse search it sometimes uses a > similar but slightly simpler algorithm: ignore '\r' if followed by > '\n'. I'm not sure why those are done in binary mode. OK, so now I'm confused. If the user looks at the text file through my viewer, and set's a breakpoint at line 100, how can I be sure it's the same 100 that GDB will actually set a breakpoint at? Obviously this works for unix and dos file formats. But from the algorithm you stated above, it doesn't look like GDB will work with mac file formats. I mean, the C library on unix won't be able to read a file that was created on a mac (at least with the mac file format). Is GDB responsible for mapping the file line numbers to the actual lines? or is this the responsibility of GCC via the debug info? For instance, if foo () is defined at line 100 according to gcc and 101 according to GDB, does CGDB have to think foo () is at line 100 or 101? Thanks, Bob Rossi