This is the mail archive of the
mailing list for the GCC project.
Re: [patch driver]: Fix relocatable toolchain path-replacement in driver
- From: Kai Tietz <ktietz70 at googlemail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 11 Sep 2013 19:07:34 +0200
- Subject: Re: [patch driver]: Fix relocatable toolchain path-replacement in driver
- Authentication-results: sourceware.org; auth=none
- References: <CAEwic4Z=6YQNyaB7p+J-0by6ejDQtn1FrUD4ZACz4=TP+bjmwg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1309111510380 dot 23762 at digraph dot polyomino dot org dot uk>
2013/9/11 Joseph S. Myers <firstname.lastname@example.org>:
> On Wed, 11 Sep 2013, Kai Tietz wrote:
>> This change fixes a quirk happening for relocated toolchains. Driver
>> remembers original-build directory
> The original *build* directory should never be known to the driver; only
> the *configured* prefix.
> This area is complicated and subtle; you need to be very careful and
> precise in the analysis included in any patch submission related to it.
> Get things absolutely clear in your head and then write a complete,
> careful, precise self-contained explanation of everything relevant in GCC,
> as if for an audience not at all familiar with the code in question.
That I agree on, and it took me some time to find this.
>> in std_prefix variable for being able later to modify path. Sadly
>> this std_prefix variable gets modified
>> later on, and so update_path can't work any longer as desired. This
> You don't say what "as desired" is. prefix.c contains a long description
> of *what* the path updates are, but no explanation of *why* or any overall
> design; it appears to be something Windows-specific.
Well it might be Windows specific. It shows its bad side on Windows
due old build-prefix remains on translation and leads to the try to
access an invalid path. That isn't necessarily a problem as long as
the drive-letter exists. Otherwise user gets system-failures by this.
I am pretty sure that it isn't related to make_relative_path, as
otherwise we would see same behavior on other targets, too.
> update_path should, as I understand it, always be called with PATH being a
> relocated path (one that has had the configured prefix converted to the
> prefix where the toolchain is in fact installed, using
> make_relative_prefix, or that doesn't need any relocation, e.g. a path
> passed with a -B option). In incpath.c, for example, you see how a path
> is computed using make_relative_prefix before update_path is called.
> Thus, it is correct for std_prefix to be the relocated prefix rather than
> the unrelocated one.
I understand this different. See here translate_name function (used
by update_path). If path is empty it falls back to PREFIX (not
std_prefix). So I understand that this routine tries to cut off
compiled in prefix from paths and replaces it by key's path. But
well, I might got this wrong.
The bad point about all this on native Windows targets is the use of
msys and its stupid auto-magic PATH-translation (means it converts
simply everything what it sees to begin with a slash ...). By this it
might be that it is indeed a Windows specific thing here.
Nevertheless one I think we need to address ...
> If there is a bug, I'd say it's in whatever code is calling update_path
> without having first done the make_relative_prefix relocation on the path
> being passed to update_path. Thus, it is that caller that you need to
> Joseph S. Myers