Richard Biener: > On Mon, Oct 17, 2016 at 11:44 PM, Mike Stump <mikest...@comcast.net> wrote: >> On Oct 17, 2016, at 2:38 PM, Ximin Luo <infini...@pwned.gg> wrote: >>> >>> Mike Stump: >>>> On Oct 17, 2016, at 11:00 AM, Ximin Luo <infini...@pwned.gg> 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. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
