dblaikie added a comment.

In https://reviews.llvm.org/D52296#1282603, @probinson wrote:

> In https://reviews.llvm.org/D52296#1282589, @dblaikie wrote:
>
> > In https://reviews.llvm.org/D52296#1282587, @probinson wrote:
> >
> > > Any distributed build has to make this work, so the paths in the line 
> > > table are usable.  Not clear what you're thinking might be the problem 
> > > with the split-in-.o case.
> >
> >
> > Fair point - same sort of problem, but might need distinct handling (ie: 
> > might not work "for free" with existing tools, but need more support), etc, 
> > depending on how it's solved?
> >
> > Mostly just wondering whether Clang would need extra flags to support this 
> > - to get a sense of the total/overall solution/surface area of the feature, 
> > etc.
>
>
> Shouldn't.  We have licensees using distributed builds all day every day, but 
> we haven't introduced anything into the compiler itself to make that work.  
> On Windows, I know SN-DBS will intercept system calls to patch up filespecs.  
> On Linux I'd expect the remote servers to set up chroot environments so the 
> path names will Just Work, although I admit I've never actually looked.  
> Never had to; it Just Works.


Neat!

> In this patch, where the .o normally points to the .dwo it would instead just 
> point to itself, right?

Right - that's an absolute path, like the line table (between dir+name, if you 
don't override the base dir to something else, etc). So, yeah, if the solutions 
for that are implemented at a sufficiently low level as you've described above, 
sounds like there's a good chance it'd Just Work for this part too.

>   The linker doesn't need to fix anything up, it just ignores the .dwo 
> sections.

*nod* Not suggesting the linker could/would be able to fix anything up here - 
but that the compiler might need extra command line features to help ensure the 
values were written in a way that was useful.

For example, I believe the Chromium build system may use 
-fdebug-compilation-dir and -fdebug-prefix-map to make cached distributed 
builds work (where it'd be impossible to bake in any particular path - because 
two users may be building Chromium from different locations, but they should be 
able to share build artefacts for maximal caching). But if that's not the usual 
problem/solution (or there are sufficiently many users/use cases that don't 
have that problem) - that's cool & it's nice if this just works for those users 
- and if, for whatever reason, that a Chromium-like situation comes up & wants 
non-split-split-DWARF & needs to address the problem, we can cross that bridge 
at that time (either by using the existing properties (like 
-fdebug-compilation-dir and -fdebug-prefix-map) if they provide enough 
information, or by adding other flags to that family to allow the user to do so)


https://reviews.llvm.org/D52296



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to