<div dir="ltr">Ah, ok - there are two problems then, not one.<div class="gmail_extra"><br><div class="gmail_quote">2014-01-30 Jim Grosbach <span dir="ltr"><<a href="mailto:grosbach@apple.com" target="_blank" class="cremed">grosbach@apple.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">That subtraction diagnostic doesn’t generate a stack trace, does it? I don’t see one on Darwin, anyway. Perhaps a platform difference?</div>

</blockquote><div><br></div><div>It doesn't generate a stack trace with `-triple i686-pc-linux` but does with `-triple i686-pc-win32`.</div><div>Looks like the COFFStreamer doesn't play well with SMLoc.</div><div>

It looks like a bigger issue and I don't think it should be a part of this change.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word"><div>The top level report_fatal_error() function has a parameter for whether to consider the failure a crasher or not, but doesn’t look like this is going through that path.</div><span class=""><font color="#888888"><div>

<br></div><div>-Jim</div></font></span><div><div class="h5"><div><br><div><div>On Jan 30, 2014, at 10:54 AM, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank" class="cremed">rnk@google.com</a>> wrote:</div>

<br><blockquote type="cite"><div dir="ltr">I'd leave the stack trace alone for now.  That's what all other MC errors do.  If somebody wants to fix that, they can do it later.</div></blockquote></div></div></div></div>

</div></blockquote><div>Agree. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">

<div><div class="h5"><div><div><blockquote type="cite"><div dir="ltr"><div>For the wording, IMO it'd be more consistent to say that this was an "undefined symbol".  It's not clear what "couldn't resolve" means, and "undefined" feels more precise.</div>

</div></blockquote></div></div></div></div></div></blockquote><div>OK, see the updated version of the patch.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><div class="h5"><div><div><blockquote type="cite"><div dir="ltr"><div>Also, we should mention .secidx.</div>
<div><br></div><div>We have other errors like:</div><div><div>          Twine("symbol '") + B->getName() +</div><div>              "' can not be undefined in a subtraction expression");</div>


</div><div><br></div><div>So we could do something like:</div><div><span style="font-family:arial,sans-serif;font-size:13px">Cannot get section of undefined symbol 'bar' in .secidx directive</span></div></div></blockquote>

</div></div></div></div></div></blockquote><div>I'm not sure - the condition might theoretically be (un)met for other directives as well.</div><div>Long-term, when the locations are threaded properly, we'll get a nice diagnostic pointing at the very instruction and saying</div>

<div>  C:\src\llvm\test\MC\COFF\secidx_diagnostic.s:8:17: error: symbol 'bar' can not be undefined</div><div>        .secidx bar</div><div>               ^</div><div>(this one is manually crafted based on the `-triple i686-pc-linux` output)</div>

<div><br></div><div>Does that sound good?</div></div></div></div>