Richard Biener:
> On Mon, Oct 17, 2016 at 11:44 PM, Mike Stump <> wrote:
>> On Oct 17, 2016, at 2:38 PM, Ximin Luo <> wrote:
>>> Mike Stump:
>>>> On Oct 17, 2016, at 11:00 AM, Ximin Luo <> wrote:
>>>>> Therefore, it is better to emit it in all circumstances, in case the 
>>>>> reader needs to know what the working
>>>>> directory was at compile-time.
>>>> I can't help but wonder if this would break ccache some?
>>> Could you explain this in some more detail? At the moment, GCC will already 
>>> emit DW_AT_name with an absolute path (in the scenario that this patch is 
>>> relevant to). How does ccache work around this at the moment? (Does it use 
>>> debug-prefix-map? In which case, this also affects DW_AT_comp_dir, so my 
>>> patch should be fine.)
>> If you compile the same file, but in a different directory, I wonder if cwd 
>> will cause the cache entry to not be reused.
>> I expect one of the ccache people that are around would just know if it will 
>> care at all.
> I believe ccache compares preprocessed source, definitely _not_ DWARF
> output, so this shouldn't break anything there.
> It might result in different object file output but as the reporter
> figured due to a bug in dwarf2out.c we end up generating
> DW_AT_comp_dir in almost all cases already.
> I think the patch is ok but it misses a ChangeLog entry.  How did you
> test the patch? (bootstrapped and tested on ...?)

Thanks, I'll add the Changelog entry. My computer isn't very powerful, so I 
didn't bootstrap it yet, I only tested it on a stage1 compiler, on Debian 
testing/unstable. I'll find some time to bootstrap it and test it fully over 
the next few days.

Shall I also get rid of the Darwin force_at_comp_dir stuff? Looking into it a 
bit more, my patch basically obsoletes the need for this so I can delete that 
as well.


GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

Reply via email to