[cfe-dev] controlling the value of DW_AT_comp_dir

Nick Lewycky nlewycky at google.com
Thu Oct 20 14:59:36 PDT 2011


On 20 October 2011 14:55, Chandler Carruth <chandlerc at google.com> wrote:

> On Thu, Oct 20, 2011 at 2:03 PM, Nick Lewycky <nlewycky at google.com> wrote:
>
>> To understand why, you first need to know that we run builds on hermetic
>> build machines.
>
>
> I'm not really sure why our build system is relevant here.
>

Only because there are ways to fix that problem which would still break
caching in our build system. I wanted to steer us away from that.


>  This has been a problem for me many times using very mundane and ordinary
> build systems. If I build on machine X and then copy the binary to machine
> Y, it can't find the source code if it is stored in a different directory,
> even if the directory structure is entirely compatible.
>
> Why can't we follow GCC's lead here, and use PWD (when on a system with
> such a concept) as the basis for DW_AT_comp_dir? I think what I'm missing is
> why doing that causes problems...
>

Works for me. I just want agreement for what to do (flag, using PWD,
whatever). I honestly don't care how it works as long as it works. I can
propose a patch using PWD if you want, the plumbing through -cc1 will be the
same either way.

Nick

Chris's objections (which seem reasonable) are to *always* using PWD. To be
> clear, I'm not suggesting that. I'm suggesting that the Clang driver, which
> is already quite aware of the user's shell, can inspect PWD and getcwd and
> consult any other oracle needed to determine a valid working directory, and
> then pass it via an internal-only flag to the CC1 layer IFF it differs from
> getcwd.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111020/f527b512/attachment.html>


More information about the cfe-dev mailing list