<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 16, 2013 at 10:51 AM, Kevin Enderby <span dir="ltr"><<a href="mailto:enderby@apple.com" target="_blank">enderby@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div class="im"><div>On Jan 16, 2013, at 10:44 AM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 16, 2013 at 10:38 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@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>On Wed, Jan 16, 2013 at 9:55 AM, Kevin Enderby <<a href="mailto:enderby@apple.com" target="_blank">enderby@apple.com</a>> wrote:<br>
> Hi Eric,<br>
><br>
> This is just for testing (without the clang change). I didn't want to add a<br>
> it as a command line argument to llvm-mc as that would then have the<br>
> producer string as it would also affect the AT_Apple flags.<br>
<br>
</div>Curious: what do you mean by this? What are the AT_Apple flags?<br>
(sorry, I'm not familiar with this area)<br>
<br></blockquote><div><br></div><div>There are some apple internal attributes on dwarf. They're usually tagged DW_AT_APPLE_...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As for the testing issue, could this be written as a unit test instead<br>
of having a test hook like this? (Ideally even once Clang is testing<br>
this code path, it'd be nice to still have LLVM functionality tested<br>
in LLVM so LLVM developers who aren't necessarily working<br>
with/building/testing Clang could still know that they haven't broken<br>
this functionality - but I realize sometimes that benefit isn't worth<br>
the overhead of writing such tests for relatively trivial features,<br>
but it's worth checking* if we've reached a tipping point where a few<br>
trivial features could all benefit from the addition of unit tests,<br>
for example)<br>
<br>
* I say this in the absence of any specific knowledge - perhaps this<br>
is the only such case & there's no aggregate benefit, etc, at the<br>
moment.<br>
<div><br></div></blockquote><div><br></div><div>Not necessarily a bad idea. The code path could alternately be tested by a command line flag added to llvm-mc?</div></div></div></div></blockquote><div><br></div></div>Again I didn't want to add a command line to llvm-mc as it would effect the values in the DW_AT_APPLE since it contains all the command line.<blockquote type="cite">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></div></blockquote></div></div></blockquote><div style>Hrm. I wonder if the arguments to llvm-mc should be passed into DW_AT_Apple_flags or if there should be a separate command line that adds them in?<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div></div><div>
Kevin? Your thoughts?</div></div></div></div></blockquote><div><br></div>I really don't care how this is tested. I just want to get the work done.</div><div class="im"><div><br></div></div></div></blockquote><div><br>
</div><div style>*nod* I do have a baseline aversion to environment variables but I'm not going to draw any lines in the sand. Just interested in getting the best way of testing this in. :)</div><div style><br></div><div style>
-eric </div></div></div></div>