From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27141 invoked by alias); 14 Oct 2004 09:41:37 -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 27123 invoked from network); 14 Oct 2004 09:41:34 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sourceware.org with SMTP; 14 Oct 2004 09:41:34 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0); Thu, 14 Oct 2004 10:41:02 +0100 From: "Dave Korn" To: "'geneSmith'" , Subject: RE: Can't find source files Date: Thu, 14 Oct 2004 09:41:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: Message-ID: X-OriginalArrivalTime: 14 Oct 2004 09:41:02.0798 (UTC) FILETIME=[EB590EE0:01C4B1D1] X-SW-Source: 2004-q4/txt/msg00033.txt.bz2 > -----Original Message----- > From: insight-owner On Behalf Of geneSmith > Sent: 13 October 2004 20:09 > Page 62 of the gdb manual states" > "You can use the string '$cdir' to refer to the compilation directory > (if one is recorded)..." > which I took to mean the src path embedded in the runtime > file for the > current function. The only place I see it refererenced is in the > "directory" path which defaults to "$cdir:$cwd" which implies > that the literal path from the r.t. file is tried first...maybe. Yeah, I'm not really sure; that's the only mention of it in the docs and it's a bit ambiguous. FWIW I couldn't get a local copy of gdb to place anything useful in $cdir automatically, even when debugging an application which it was having no problem finding source locations for. So I dunno if there's a bug that means cdir should be automatically set but isn't, or if that's a misinterpretation of the manual. It could do with a little clarification on what a compilation directory is, and where and how precisely one might be recorded. Ah, ok, I got it. I've looked through the source. $cdir is not a real convenience variable, that's why I wasn't seeing anything from "show conve". It's a fake that is only substituted in at the very last moment. The compilation dir in question is that recorded in the symtab for which the source is being looked up. > > Well, the new source path features are only in mainline > (CVS), not in > > either the 6.1 nor the 6.2 release branch. Seems like they gave you > > documentation from a more up-to-date version of gdb than > the actual binary > > they gave you! > > The gdb manual I was referring I got directly from the fsf > site. There was no indication it describes unreleased features. Do you mean http://sources.redhat.com/gdb/documentation/? It does say "Online GDB manuals Documentation generated from the current sources are available online: " which implies that the documentation is kept up-to-date with development work on the sources. They also keep a version for the last release there as well. > A the symlink method worked. m/p would work too I am sure. Excellent, at least you can get on with debugging your code instead of debugging the debugger! > > Ummm..... you do have to use the same kind of cross > objdump as the cross > > compiler and cross debugger, you know..... [guess it is > getting late!] > > Right, can't just use the pc native objdump (using e.g., > powerpc-rtems-objdump). > > It looks like in gdb 6.1 the path "concatentate" feature sort > of works > but may have bugs for some cases. Thanks for your help in > looking at this. If you're still curious, take a look at the output from "maint show symtab". The "dirname" fields show you the actual paths that are recorded in the symtabs and that are the potential values to be substituted for $cdir in the source path. cheers, DaveK -- Can't think of a witty .sigline today....