[cfe-commits] [cfe-dev] controlling the value of DW_AT_comp_dir

Nick Lewycky nlewycky at google.com
Thu Oct 20 16:14:35 PDT 2011


On 20 October 2011 16:00, Devang Patel <dpatel at apple.com> wrote:

> What about following approach...
>

I don't like it because we've been nearly successful avoiding things which
would diverge a Google-build of clang from an open-source build of clang. Is
there no way we can get this functionality without an ifdef? Is there a
reason you don't like adding a flag?

Nick


> Index: Support/Unix/Path.inc
> ===================================================================
> --- Support/Unix/Path.inc (revision 141912)
> +++ Support/Unix/Path.inc (working copy)
> @@ -251,6 +251,9 @@
>
>  Path
>  Path::GetCurrentDirectory() {
> +#if defined(__GOOGLES_SYMLINKED_BUILD_ENV__) ||
> defined(__NEED_TO_USE_PWD__)
> +  return Path(getenv("PWD"))
> +#endif
>    char pathname[MAXPATHLEN];
>    if (!getcwd(pathname, MAXPATHLEN)) {
>      assert(false && "Could not query current working directory.");
>
> ?
>
> -
> Devang
> On Oct 20, 2011, at 3:53 PM, Nick Lewycky wrote:
>
> [+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.
>>>
>>
>>
> <dwarf-comp-dir-1.patch>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111020/c2341625/attachment.html>


More information about the cfe-commits mailing list