From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27485 invoked by alias); 22 Jan 2013 08:24:52 -0000 Received: (qmail 27471 invoked by uid 22791); 22 Jan 2013 08:24:49 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_NIX_SPAM,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Jan 2013 08:24:43 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MH000B00PYOY800@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Tue, 22 Jan 2013 10:24:42 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MH000B4GQ15K3B0@a-mtaout22.012.net.il>; Tue, 22 Jan 2013 10:24:42 +0200 (IST) Date: Tue, 22 Jan 2013 08:24:00 -0000 From: Eli Zaretskii Subject: Re: [patch 4/9] TUI: Use internally fullname In-reply-to: <20130122071205.GA31510@host2.jankratochvil.net> To: Jan Kratochvil Cc: tromey@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83a9s1oc9w.fsf@gnu.org> References: <20130117215935.GE16249@host2.jankratochvil.net> <87r4le1i04.fsf@fleche.redhat.com> <20130121211121.GA29177@host2.jankratochvil.net> <83mww1ogfl.fsf@gnu.org> <20130122071205.GA31510@host2.jankratochvil.net> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00516.txt.bz2 > Date: Tue, 22 Jan 2013 08:12:05 +0100 > From: Jan Kratochvil > Cc: tromey@redhat.com, gdb-patches@sourceware.org > > > Why strip it? We could resolve "." to an absolute file name using the > > compilation directory, and then they will match, right? > > That can be done for S->FILENAME and that is already done by > symtab_to_fullname. > > But for NAME - the string which user entered in "break ./gdb.base/return.c:main" > - has no compilation nor "current" directory. What is the semantics of such a 'break' command? Does "." here mean the current directory? Or does it mean something else? If the former, then we have the current directory in GDB, don't we? > http://msdn.microsoft.com/en-us/library/windows/desktop/aa363788%28v=vs.85%29.aspx > dwVolumeSerialNumber > nFileIndexHigh > nFileIndexLow > The identifier (low and high parts) and the volume serial number > uniquely identify a file on a single computer. To determine whether > two open handles represent the same file, combine the identifier and > the volume serial number for each file and compare them. > > So I do not understand why MS-Windows stat call does not provide st_ino from > those fields. Because MS didn't bother to code that. > I expect it is just a MS-Windows stat implementation bug probably > workarounded in Cygwin but apparently not in MinGW? Cygwin doesn't use the Windows runtime, it uses its own library. MinGW does use the Windows runtime, and doesn't have a replacement for 'stat' in its "mingwex" library. One complication with such a replacement is that the FileIndex thing is a 64-bit quantity, while 'struct stat' in MS implementation uses a 'short' data type for it. This creates binary incompatibility. That's why I suggested a separate method for retrieving the inode.