From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16914 invoked by alias); 6 Apr 2006 03:27:01 -0000 Received: (qmail 16904 invoked by uid 22791); 6 Apr 2006 03:27:01 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao05.cox.net (HELO eastrmmtao05.cox.net) (68.230.240.34) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Apr 2006 03:26:59 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao05.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060406032653.CCCS3108.eastrmmtao05.cox.net@localhost.localdomain> for ; Wed, 5 Apr 2006 23:26:53 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FRL9C-0005A3-7b for gdb@sources.redhat.com; Wed, 05 Apr 2006 23:27:02 -0400 Date: Thu, 06 Apr 2006 03:27:00 -0000 From: Bob Rossi To: gdb@sources.redhat.com Subject: Re: text file formats Message-ID: <20060406032702.GE11610@brasko.net> Mail-Followup-To: gdb@sources.redhat.com References: <20060405223122.GB11610@brasko.net> <20060405233938.GA11013@nevyn.them.org> <20060406001455.GC11610@brasko.net> <20060406011732.GA12814@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060406011732.GA12814@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/msg00046.txt.bz2 On Wed, Apr 05, 2006 at 09:17:32PM -0400, Daniel Jacobowitz wrote: > On Wed, Apr 05, 2006 at 08:14:55PM -0400, Bob Rossi wrote: > > 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). > > The manual algorithm is only used while searching. It will work on any > file format recognized by the C library. > > The C library is generally used. If you want to handle a text file, > including a source file, it had better be in the native format. Full > stop. > > I don't think any recent version of MacOS uses the old \r format, > anyway? I thought OSX had switched to the Unix convention. Sure, but for some reason the file '/usr/include/g++-3/sstream' on red hat enterprise 3 has mixed file formats. So, this becomes a practical issue, not just a theoretical one. Here is an example from 'od -a /usr/include/g++-3/sstream 0007400 h ) cr nl sp sp sp sp { sp } cr nl nl sp sp The 'cr nl' is "\r\n" and the extra "nl" is "\n". Opening this file in vim shows the ^M at the end of each line. > > 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? > > I have no idea what you mean. GDB gets line numbers from debug info, > of course; where else would it get them? Does the debug info actually say, "at line 100 symbol foo() exists?" Meaning, does gcc calculate that information, or does GDB derive the line number from the debug info? OK, I'm sorry, as usual I'm describing this bad. Let's start out by trying to agree with an assumption that I have. Since the file is in a mixed format, is it true that the line number is determined ambiguously by the program reading the file? Thanks, Bob Rossi