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

[Devang Patel]

On Oct 20, 2011, at 4:14 PM, Nick Lewycky wrote:

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

Essentially, what you're looking  for to say is, "on this platform use pwd". Have you considered an alternative to use configure check to enable use of PWD ?

I want you to exhaust all alternatives before deciding to add a command line flag. Adding a command line flag is usually easy way out, but removing an command line flag is almost impossible. 

If you add a compiler option then would it be confusing or useful to people on other platforms? 

If you still think command line flag is the way to go then pick a name that obvious to someone who does not know what is DWARF. Something like -fcurrent-working-dir=... or as such.

-
Devang

> 
> 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/e71c2545/attachment.html>