Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit

[Pedro Alves <pedro@palves.net>]

[Adding Samuel.]

Samuel, please see Hurd question below.

On 2022-04-18 19:19, Simon Marchi wrote:
> 
> 
> 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 <gdb-patches@sourceware.org> 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
>