<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 27, 2014 at 9:17 PM, Yaron Keren <span dir="ltr"><<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="rtl"><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div dir="ltr">With Visual C++, this structure prevents the debugger from working, since the breakpoints are placed on the main process and not the spawned process. The cumbersome workaround is to print and capture the child -cc1 command line and use it instead.</div>
</div></blockquote><div><br></div><div>Yep, we're all familiar with this - all of us working on Clang have been doing this for a while now...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="rtl">

<div dir="ltr"><br></div><div dir="ltr">I'm not sure how much crash recovery is useful here, clang never crashes ;-). </div></div></blockquote><div><br></div><div>The bug reports beg to differ (when you work on the compiler you see just how much it can fail).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="rtl"><div dir="ltr"><br></div><div dir="ltr">Seriously, If clang faults doing something the whole compilation job is very likely to fail anyhow even if clang can recover and compile the other source files in the job. </div>
</div></blockquote><div><br></div><div>Crash reporting/handling isn't likely to allow the user to continue without changing their code - but it will give them some useful information to report bugs.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="rtl">

<div dir="ltr"><br></div><div dir="ltr">Yaron</div><div dir="ltr"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div dir="ltr">2014-01-28 Yuri <span dir="ltr"><<a href="mailto:yuri@rawbw.com" target="_blank">yuri@rawbw.com</a>></span></div>
<div><div class="h5">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 01/27/2014 17:38, Richard Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't think the reasons why we spawn another binary have really been<br>
captured in this thread. The biggest reason is that the clang driver<br>
accepts multiple files to compile:<br>
<br>
    clang foo.c bar.c baz.c -o thing<br>
<br>
... and runs one compile process for each source file (and in this case,<br>
one link process for the binary). Crash recovery is just a nice side-effect<br>
of having a separate driver and frontend. The main benefit is that we get a<br>
consistent execution model regardless of the number of files passed to the<br>
driver.<br>
</blockquote>
<br></div>
But this also is not necessary to do. clang can just go through them sequentially in the same process. Now it forks itself for each of them one by one sequentially.<div><div><br>
<br>
Yuri<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div></div></div><br></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>