toolchain/40647: [dM] gdb breaks under non-readable dirs

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>Number:         40647
>Category:       toolchain
>Synopsis:       [dM] gdb breaks under a non-readable directory
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Feb 15 13:55:02 +0000 2009
>Originator:     der Mouse
>Release:        NetBSD 4.0 (also seen on 3.1)
>Organization:
        Dis-
>Environment:
System: NetBSD NetBSD-4-0.Rodents.Montreal.QC.CA 4.0 NetBSD 4.0 (GEN40) #0: Mon 
Nov 24 05:05:05 EST 2008 
mouse%NetBSD-4-0.Rodents.Montreal.QC.CA@localhost:/home/mouse/kbuild/GEN40 i386
Architecture: i386
Machine: i386
>Description:
        gdb breaks badly under some circumstances which appear to
        amount to "getwd fails", at least when the failure is due to a
        non-readable ancestor to the current directory.  See
        how-to-repeat for the exact symptoms observed; they appear to
        all be based on some kind of perceived need on the part of the
        gdb author(s) to access the program being debugged by an
        absolute pathname.  Under 4.0, gdb --version reports version
        6.5; under 3.1, 5.3nb1.
>How-To-Repeat:
        As root:
        # mkdir /root/z /root/z/y
        # chmod 711 /root/z
        # chown mouse /root/z/y
        (presumably any other non-root user will do as well as mouse,
        here and below)
        As mouse:
        % cd /root/z/y
        % cp /bin/cat .
        % gdb cat
        ...
        (gdb) run
        BFD: reopening /cat: No such file or directory
        
        `/cat' has disappeared; keeping its symbols.
        Starting program: /cat 
        csh: Permission denied
        csh: Trying to start from "/home/mouse"
        /cat: Command not found.
        
        Program exited with code 01.
        BFD: reopening /cat: No such file or directory
        
        You can't do that without a process to debug.
        (gdb) 

        Using "env SHELL=sh gdb cat" changes the symptoms slightly,
        because sh is less obnoxious about its cwd on startup, but the
        basic problem with gdb appears to be the same:

        (gdb) run
        BFD: reopening /cat: No such file or directory
        
        `/cat' has disappeared; keeping its symbols.
        Starting program: /cat 
        exec: /cat: not found
        
        Program exited with code 0177.
        BFD: reopening /cat: No such file or directory
        
        BFD: reopening /cat: No such file or directory
        
        BFD: reopening /cat: No such file or directory
        
        BFD: reopening /cat: No such file or directory
        
        warning: Unable to find dynamic linker breakpoint function.
        GDB will be unable to debug shared library initializers
        and track explicitly loaded dynamic code.
        You can't do that without a process to debug.
        (gdb) 
>Fix:
        Much as I hate "don't do that, then", the closest thing to a
        workaround I know of is to just not do that; don't try to debug
        in directories having ancestors unreadable by the user.  A real
        fix would have to be implemented in gdb, and my understanding
        of gdb is far too weak to know how involved it would be to fix
        this curious compulsion to refer to the program being debugged
        by full pathname for no visible reason.  (This same tendency
        can be observed during normal debugging when gdb prints a full
        pathname when starting to run the program.)

        /~\ The ASCII                             Mouse
        \ / Ribbon Campaign
         X  Against HTML                mouse%rodents-montreal.org@localhost
        / \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B