From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18996 invoked by alias); 8 Jan 2008 16:12:07 -0000 Received: (qmail 18983 invoked by uid 22791); 8 Jan 2008 16:12:06 -0000 X-Spam-Check-By: sourceware.org Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 08 Jan 2008 16:11:33 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2008 11:11:31 -0500 Message-ID: <2F6320727174C448A52CEB63D85D11F40A5F@nova.ott.qnx.com> From: Aleksandar Ristovski To: Joel Brobecker , Doug Evans Cc: gdb@sourceware.org, Ryan Mansfield Subject: RE: gdb_realpath: dealing with ./ and ../ Date: Tue, 08 Jan 2008 16:12:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00051.txt.bz2 > > Maybe I shouldn't have talked about complexity as this may be just me > needing time to understand the purpose of your patch. So I withdraw > that comment. Wherever the fix is put, it will be of approx. the same complexity as it solves the same problem in a similar way. > > > Handling the issue in each debug info reader is an important > > consideration and may or may not be a problem. One would need to > > examine to what extent the issue exists in the other readers, and to > > what extent start_subfile can solve it and still be debug-format > > independent without being more complex. > > My suggestion has two ideas behind it: > > I reallly think that the wrapper around start_subfile that adjusts > NAME and DIRNAME so that NAME is always a basename is a good step > forward, because it reduces the number of combinations we need to > handle during the matching phase later on. We don't have to handle > the case where NAME is a full path, or a relative path of a basename. This would effectively make keeping DW_AT_comp_dir value redundant. Not sure if this would create any issues (I don't see any). > > Second, I still believe at this point that the problem should be > handled outside of the debug info reader. I know that at least > stabs should have the same issues as DWARF. It would be very nice > to have the problems fixed in both cases without having to duplicate > the algorithms we're developing. > > > One could rewrite that patch to keep dwarf2_start_subfile, but one > > would have to pass an additional parameter so it would know if it's > > dealing with the main source file. The patch as submitted just > > reorganizes things so that other solutions(/heuristics) are possible > > without major reworking of the code (the patch itself had to do some > > reworking, but once that's done it's done (in the problem space being > > discussed)). Plus it simplifies all call sites to > > dwarf2_start_subfile/start_subfile. Previously, each call site had to > > process fe->dir_index, and there are three of them. > > I think that the reorganization will not be necessary. I'd like to > make the subfile layer work in a way that the debug info reader would > only have to pass the name and dirname as-is, and be confident that > it'll just work. If we can confirm for sure that "normalize_path" is safe, I think the idea is good (please read my comment about normalize_path here: http://sourceware.org/ml/gdb-patches/2008-01/msg00138.html) Example DW_AT_name=../main.cc DW_AT_comp_dir=/foo/bar/obj The Directory Table: .. The File Name Table:$ Entry>Dir>~~~~Time>~~~Size>~~~Name$ 1>~~~~1>~~~~~~0>~~~~~~0>~~~~~~main.cc$ Now we get rid of the comp_dir information (this is what effectively happens): NAME=main.cc DIR=/foo/bar And there is no info about /foo/bar/obj. I would think that this is safe. Thanks, Aleksandar