User account creation filtered due to spam.

Bug 38966 - libiberty make_relative_prefix_1 mistakes directories for executables
Summary: libiberty make_relative_prefix_1 mistakes directories for executables
Status: RESOLVED DUPLICATE of bug 48306
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.3.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 37995 39278 40548 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-25 14:54 UTC by Michael Lotz
Modified: 2012-08-16 12:59 UTC (History)
8 users (show)

See Also:
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 (480 bytes, patch)
2009-01-25 14:56 UTC, Michael Lotz
Details | Diff
Proposed fix with conditional use of stat based on HAVE_SYS_STAT_H (501 bytes, patch)
2009-01-27 01:23 UTC, Michael Lotz
Details | Diff
Simple repro for "gcc" subdir in PATH bug. (1.26 KB, text/plain)
2012-08-15 21:34 UTC, Tom Tignor
Details

Note You need to log in before you can comment on or make changes to this 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 ***