User account creation filtered due to spam.

Bug 38966

Summary: libiberty make_relative_prefix_1 mistakes directories for executables
Product: gcc Reporter: Michael Lotz <mmlr>
Component: otherAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED DUPLICATE    
Severity: normal CC: aschorr, dfeldstern, dickie, gcc-bugs, jakub, mvanier, psmith, ttignor
Priority: P3    
Version: 4.3.2   
Target Milestone: ---   
Host: i586-pc-haiku Target: i586-pc-haiku
Build: Known to work:
Known to fail: Last reconfirmed:
Attachments: Proposed fix for make_relative_prefix_1
Proposed fix with conditional use of stat based on HAVE_SYS_STAT_H
Simple repro for "gcc" subdir in PATH bug.

Description Michael Lotz 2009-01-25 14:54:59 UTC
When GCC tries to resolve paths to executables it generates an exec prefix based on argv[0]. It does that using the make_relative_prefix_1 function in libiberty (make-relative-prefix.c). If argv[0] doesn't contain a path (i.e. it only reads "gcc"), make_relative_prefix_1 searches the PATH to find the full path to the current executable.

When checking candidates however, it only checks the executable bit to determine whether or not it found the current executable. This means that when there is a directory with the same name as the executable in the PATH, this mechanism will produce a wrong prefix.

Attached is a patch that uses stat to determine whether the candidate file is a regular file at all, hence skipping directories.
Comment 1 Michael Lotz 2009-01-25 14:56:28 UTC
Created attachment 17181 [details]
Proposed fix for make_relative_prefix_1
Comment 2 Andrew Pinski 2009-01-26 19:23:57 UTC
*** Bug 37995 has been marked as a duplicate of this bug. ***
Comment 3 DJ Delorie 2009-01-26 19:46:56 UTC
Subject: Re:   New: libiberty make_relative_prefix_1 mistakes directories for executables


Your code conditionally includes <sys/stat.h> but doesn't
conditionally enable the other code.  If sys/stat.h isn't found,
perhaps the code could revert to the old access() code?
Comment 4 Michael Lotz 2009-01-27 01:23:31 UTC
Created attachment 17189 [details]
Proposed fix with conditional use of stat based on HAVE_SYS_STAT_H

This only conditionally uses stat() if HAVE_SYS_STAT_H is defined. Not sure about the indentation style at all, sorry.
Comment 5 Andrew Pinski 2009-02-23 18:01:28 UTC
*** Bug 39278 has been marked as a duplicate of this bug. ***
Comment 6 Jack Howarth 2009-02-24 01:17:26 UTC
The currently proposed patch doesn't solve the problem where 'make -k check-libiberty' executed at the top level of the build directory results in gcc being used instead of xgcc. If you execute 'make -k check' in darwin_objdir/libiberty, you get...

/sw/src/fink.build/gcc44-4.3.999-20090221/darwin_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20090221/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4.4/i686-apple-darwin10/bin/ -DHAVE_CONFIG_H -g -O2 -fomit-frame-pointer -I.. -I../../../gcc-4.4-20090221/libiberty/testsuite/../../include  -o test-demangle \
		../../../gcc-4.4-20090221/libiberty/testsuite/test-demangle.c ../libiberty.a

whereas if you execute 'make -k check-libiberty' in darwin_objdir, you get the incorrect compiler...

gcc -DHAVE_CONFIG_H -g -O2 -I.. -I../../../gcc-4.4-20090221/libiberty/testsuite/../../include  -o test-demangle \
		../../../gcc-4.4-20090221/libiberty/testsuite/test-demangle.c ../libiberty.a
Comment 7 Michael Lotz 2009-02-24 17:16:41 UTC
(In reply to comment #6)
> The currently proposed patch doesn't solve the problem where 'make -k
> check-libiberty' executed at the top level of the build directory results in
> gcc being used instead of xgcc.

That's not really the scope of this patch though. This is just to correct the case where a directory is mistaken for an executable. The other issue looks like a separate bug to me.
Comment 8 Andrew Pinski 2009-06-25 01:25:03 UTC
*** Bug 40548 has been marked as a duplicate of this bug. ***
Comment 9 Tom Tignor 2012-08-15 21:31:57 UTC
I ran into the related 37995 bug today (now closed as a duplicate of this one) on gcc version 4.4.6. The bug reproduces simply by having a directory with a "gcc" subdirectory in your PATH ahead of the directory which holds the gcc binary. I have session output showing the repro procedure which I'll attach.
Comment 10 Tom Tignor 2012-08-15 21:34:50 UTC
Created attachment 28023 [details]
Simple repro for "gcc" subdir in PATH bug.
Comment 11 Jakub Jelinek 2012-08-16 06:58:19 UTC
Dup of PR48306.

*** This bug has been marked as a duplicate of bug 48306 ***
Comment 12 Tom Tignor 2012-08-16 12:59:39 UTC
Hi Jakub,
Can you tell me what gcc version has the fix? Read through 48306 and saw 
"Fixed in 4.5+" but I have a colleague here who is able to reproduce on 
4.5.1.

Tom    :-)




From:   "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To:     Thomas Tignor/Marlborough/IBM@IBMUS
Date:   08/16/2012 02:59 AM
Subject:        [Bug other/38966] libiberty make_relative_prefix_1 
mistakes directories for executables



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38966

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |jakub at gcc dot gnu.org
         Resolution|                            |DUPLICATE

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-08-16 
06:58:19 UTC ---
Dup of PR48306.

*** This bug has been marked as a duplicate of bug 48306 ***