From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15909 invoked by alias); 4 Sep 2013 16:31:44 -0000 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 Received: (qmail 15898 invoked by uid 89); 4 Sep 2013 16:31:43 -0000 Received: from mail-ie0-f178.google.com (HELO mail-ie0-f178.google.com) (209.85.223.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 04 Sep 2013 16:31:43 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,NO_RELAYS autolearn=ham version=3.3.2 X-HELO: mail-ie0-f178.google.com Received: by mail-ie0-f178.google.com with SMTP id f4so1184538iea.9 for ; Wed, 04 Sep 2013 09:31:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Hk7F8Z/KlUOxOG5jo38LMoUkn4/CuhWMeWyTJoBE6Sk=; b=RSwdG5m9FW0brssDVBrUjtvJYwM3pJf97YD9rx+hTpVCITR3HQNdkGlqhs9NxG0Ow3 B5LeMLalHEYd7AGcEhtdTn6KfQwVPsLuGKcXwSeBhT8ePSkiKm1XZyGbrhvQ6KlacbHh Q2VoUynqP9U9grb8/lkD5rQ8SNgDXVbUyxvzy8Za3tejmqUzPCY4DKExgH9rUuts+t2v SCFNuqsVfyFh8wTFRn6n1sdbFsaFb85uHfq+DfSWEc5gVcw8F+0K08fccrLHg30fRerw SzCq82wvsI/FT2z3Ta/v+cit4DpfuV1ep+1BMFAQWUThSZg0NP3UQZMVVQgDXKyLUZzS +oow== X-Gm-Message-State: ALoCoQmitvb+uFxDRnOKj3byYS/e9DQL7jIT4OnqSd2faHXerDWt+HBoQg0BxIxPw4aYSTFeSoVXCHxB/FTnI7u270UuCHx8NdM7lcqFTpxhlKdrOyL082dBANnbKsVif6UhPRv3izufhRLUHPw4LkNd0eFDtAYBqTSJBb6viF5ij8fJG1C2BKN0E+NhTbWqcNVDg8Y7tBPvpa6LRizEpLlCKRIoapEaBA== MIME-Version: 1.0 X-Received: by 10.42.223.10 with SMTP id ii10mr2284967icb.17.1378312300647; Wed, 04 Sep 2013 09:31:40 -0700 (PDT) Received: by 10.64.64.161 with HTTP; Wed, 4 Sep 2013 09:31:40 -0700 (PDT) In-Reply-To: <52271009.50805@redhat.com> References: <20130826182111.GA19509@host2.jankratochvil.net> <21019.47767.404597.352962@ruffy.mtv.corp.google.com> <20130827140915.GA17861@host2.jankratochvil.net> <21022.10862.436924.879667@ruffy.mtv.corp.google.com> <20130828180359.GB4770@host2.jankratochvil.net> <52271009.50805@redhat.com> Date: Wed, 04 Sep 2013 16:31:00 -0000 Message-ID: Subject: Re: [commit+7.6.1] [patch] [7.6.1] Fix argv[0] symlink regression (PR 15415) From: Doug Evans To: Pedro Alves Cc: Jan Kratochvil , gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00134.txt.bz2 On Wed, Sep 4, 2013 at 3:48 AM, Pedro Alves wrote: > It seems this patch introduces some output inconsistency > (only tried mainline): > > $ ./gdb > ... > (gdb) file ./gdb > Reading symbols from /home/pedro/gdb/mygit/build/gdb/gdb...done. > Setting up the environment for debugging gdb. > (top-gdb) info inferiors > Num Description Executable > * 1 /home/pedro/gdb/mygit/build/gdb/./gdb > (top-gdb) > > Note "gdb/gdb" vs "gdb/./gdb". > > (top-gdb) file gdbserver/../gdb > Load new symbol table from "/home/pedro/gdb/mygit/build/gdb/gdb"? (y or n) y > Reading symbols from /home/pedro/gdb/mygit/build/gdb/gdb...done. > (top-gdb) info inferiors > Num Description Executable > * 1 /home/pedro/gdb/mygit/build/gdb/gdbserver/../gdb > (top-gdb) > > Note ".../gdb/gdb" vs ".../gdb/gdbserver/../gdb". > > I tried your new series at > , and > seems there's still some inconsistency: > > (gdb) file ./gdb > Reading symbols from /home/pedro/gdb/mygit/build/gdb/./gdb...done. > Setting up the environment for debugging gdb. > (top-gdb) info inferiors > Num Description Executable > * 1 /home/pedro/gdb/mygit/build/gdb/./gdb > (top-gdb) info files > Symbols from "/home/pedro/gdb/mygit/build/gdb/./gdb". > Local exec file: > `/home/pedro/gdb/mygit/build/gdb/./gdb', file type elf64-x86-64. > > This one's consistent now, but then this one's odd: > > (top-gdb) file gdbserver/../gdb > Load new symbol table from "/home/pedro/gdb/mygit/build/gdb/./gdb"? (y or n) y > Reading symbols from /home/pedro/gdb/mygit/build/gdb/./gdb...done. > > (top-gdb) info inferiors > Num Description Executable > * 1 /home/pedro/gdb/mygit/build/gdb/gdbserver/../gdb > (top-gdb) > > Hmm. It seems to only happen after having loaded "./gdb" first. This > sounds like related to the filename handling in the gdb/bfd cache? GDB > finds reuses the same bfd (as gdbserver/../gdb is the same file as > the previous ./gdb), and then we printing the filename that had > been associated with the bfd before, instead of the one that was > specified in the second "file" ? Hi. Some random thoughts. If the user wants to debug foo/bar/../baz, I don't mind gdb printing it as foo/bar/../baz. Other's might of course. Removing ./ from paths is easy and reasonable enough. If gdb is debugging a new file I would have expected the old file to be gone from bfd's cache. [The problem may be in the sequencing.] We do need to be consistent with which flavor of a path we use.