Red Hat Bugzilla – Bug 137200
RHEL4 U1: collapse_path patch for gcc
Last modified: 2007-11-30 17:07:14 EST
Feature Name: Include provided collapse_path patch for gcc
2. More Detailed Description
Client requests that we include the provided collapse_path patch for gcc. The
patch is to rework the relative paths in the compilation to be absolute
(/a/b/../c -> /a/c). These relative paths can be a problem in AFS and
potentially NFS environments.
Architectures (mark all that apply)
32-bit x86 X
64-bit Itanium2 X
64-bit AMD64/Intel EM64T X
64-bit IBM POWER *
31-bit IBM S/390 *
64-bit IBM zSeries *
X - Required
* - Client doesn't use at present, but this patch should be generic.
External links: None
Priority (H,M,L): M
Target Releases: RHEL3 U5, RHEL4 GA/U1
Target Release Date: See above
Drivers or hardware dependency: None
Target Kernel: N/A
3. Business Justification: Including this patch will make the relocation and
deployment of the compiler much easier for clients in AFS environments.
4. Code Status: Done by client, not submitted/accepted upstream. Would require
us to get upstream acceptance.
5. Hardware to Red Hat? N/A
6. Partner management contact, email, phone, chat: Mike Herron, firstname.lastname@example.org
Request from PM:
Can the tools team please
a) state if they know of an alternate solution.
b) provide any insight in the work that happened upstream (rumored).
c) provide a design estimate for making these patches acceptable to upstream,
and integrating them into RHEL3 as well.
d) list any reasons why this is a really bad idea.
We may want to have a short call with the customer to discuss engineer to engineer.
Created attachment 119420 [details]
squeeze absolute paths into canonical form
Jakub, I think performance is a huge deal! Especially since there has been a lot
of work to improve compilation performance in gcc: I cannot imagine something
that slows down compilation around 10% (or more) to ever get into mailine.
People are mad enough over the creeping compile times.
Walking up a directory tree and lsating for each .. seems to me to be a
performance killer. Ouch!
I don't think gcc driver ever shows on the radar performance-wise.
For a simple hello world program, GCC driver calls ~ 80 stat/lstat/access
syscalls. If we cached the info, this could add another 20 or so, even if not,
stat/lstat are fairly cheap when kernel has the dentry loaded (which it has
most of the time).
But from #9 it seems even what I was proposing wouldn't help to the customer.
Collapsing disregarding symlinks is something completely else though,
that is a clear behavioural change, not working around buggy filesystems.
And I don't think that's desirable, at least not desirable by default.
There could perhaps be a GCC switch that would request the different behaviour.
This issue is on Red Hat Engineering's list of planned work items
for the upcoming Red Hat Enterprise Linux 4.4 release. Engineering
resources have been assigned and barring unforeseen circumstances, Red
Hat intends to include this item in the 4.4 release.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.