From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 12B2D3858D1E for ; Mon, 18 Apr 2022 18:19:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 12B2D3858D1E Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 23IIJ1RF014692 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Apr 2022 14:19:06 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 23IIJ1RF014692 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 513761EDF0; Mon, 18 Apr 2022 14:19:01 -0400 (EDT) Message-ID: <8e5a16e3-534f-9cff-2d6a-9f39d22ecf6d@polymtl.ca> Date: Mon, 18 Apr 2022 14:19:01 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit Content-Language: en-US To: Pedro Alves , Tom Tromey , Eli Zaretskii via Gdb-patches References: <20220407015159.1734834-1-simon.marchi@polymtl.ca> <20220407015159.1734834-6-simon.marchi@polymtl.ca> <835ynlctmb.fsf@gnu.org> <37276133-bfc5-43df-dea7-9e8188a8e5a9@polymtl.ca> <83lewgbzam.fsf@gnu.org> <87sfqauz6b.fsf@tromey.com> From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 18 Apr 2022 18:19:01 +0000 X-Spam-Status: No, score=-3034.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2022 18:19:11 -0000 On 2022-04-18 13:59, Pedro Alves wrote: > On 2022-04-18 18:36, Simon Marchi via Gdb-patches wrote: >> >> >> On 2022-04-18 12:35, Tom Tromey wrote: >>>>>>>> "Eli" == Eli Zaretskii via Gdb-patches writes: >>> >>>>> It might not look pretty, but it should still yield a valid path. >>> >>> Eli> Well, at least on MS-Windows, "/foo/bar" and "//foo/bar" are very >>> Eli> different things. >>> >>> Technically, in POSIX, a leading "//" may have an implementation-defined >>> meaning. Or at least this was true "back in the day", I haven't exactly >>> kept up. I'm not aware of any implementations that do anything special >>> here, but I think in the distant past there was one. >>> >>> Tom >> >> There's one mentionned here: >> >> https://gitlab.com/gnutools/binutils-gdb/-/blob/dc6c21dabfbd242616b9e6266b459eded2d0762b/gdb/cli/cli-cmds.c#L606= >> >> /* We are dealing with leading repetitions of "/..", for >> example "/../..", which is the Mach super-root. */ >> p += 3; >> >> I have no idea what "Mach super-root", and Googling doesn't help. I >> started to get in the rabbit hole of factoring out this code that >> removes . and .. from paths, but gave up for now. But I was >> considering getting rid of this behavior in factor of the behavior >> where /../.. simplifies to /. I tested on macOS, that's how it works >> today. Perhaps someone on Hurd can tell how it works there? > > The autoconf manual, mentions, here: > > https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/File-System-Conventions.html > > "Posix lets implementations treat leading // specially, but requires leading /// and beyond to be equivalent to /. Most Unix variants > treat // like /. However, some treat // as a “super-root” that can provide access to files that are not otherwise > reachable from /. The super-root tradition began with Apollo Domain/OS, which died out long ago, but unfortunately Cygwin has revived it." Ok, that's a different "super-root" syntax then. What's supported in cd_command (my link above) talks about repeated leading "/..". I just tried "ls //foo" on Cygwin. It gave "no such file or directory", but it took a while to return, so I guess it's just handling it as a UNC path, trying to look up computer "foo" on my network (as Eli told initially). > Mach here probably refers to the Mach microkernel used in the Gnu Hurd. Yeah, that's why I asked. If somebody has a Hurd system handy. If Hurd treats /../.. as /, then I would vote to get rid of that behavior in cd_command, since there would be no known-to-us platform where it works like that. Simon