[cfe-dev] controlling the value of DW_AT_comp_dir

[Nick Lewycky]

[+cfe-commits now that this has a patch.]

On 20 October 2011 14:59, Nick Lewycky <nlewycky at google.com> wrote:

> 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.
>

Ok, here's a patch that passes PWD through from the driver into the .bc, and
it comes out in the .o files. Yay!

Please review!

Nick

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/3a43a69c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dwarf-comp-dir-1.patch
Type: text/x-patch
Size: 3451 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111020/3a43a69c/attachment.bin>