<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - msbuild integration: suppressing and translating more properties"
href="https://bugs.llvm.org/show_bug.cgi?id=38799">38799</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>msbuild integration: suppressing and translating more properties
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>mike.winterberg@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Visual Studio 2017 Update 8 introduced a new compiler option, /JMC to integrate
with the debugger. The "advertising" for it is described here:
<a href="https://blogs.msdn.microsoft.com/vcblog/2018/06/29/announcing-jmc-stepping-in-visual-studio/">https://blogs.msdn.microsoft.com/vcblog/2018/06/29/announcing-jmc-stepping-in-visual-studio/</a>
It does alter the generated code -- it inserts calls to a "magic" function
called __CheckForDebuggerJustMyCode. I don't know if there is a desire to
support something like this, but adding an empty <SupportJustMyCode /> element
to the ClCompile section in LLVM.Cpp.Common.targets prevents the /JMC flag from
being passed on and prevents a warning about an unused command line flag.
For Link, three issues:
1) Link.GenerateDebugInformation with a value of 'true' in debug builds or
'DebugFastLink' otherwise generates a hard error. While it's not the exact same
as what happens with /ZI and /Zi, would there be any reason to not just convert
fastlink PDB requests to full?
2) Since ClCompile.WholeProgramOptimization is silently disabled, it seems like
Link.LinkTimeCodeGeneration should also be. Currently if it's set to any value
other than Default it causes a hard error.
3) This may more accurately be an issue with lld-link compatibility rather than
addressing it into the msbuild support files, but should
/MAP:LinkerAddressFile.map map to -lldmap:LinkerAddressFile.map? The output
format is different from what link.exe produces, so I'm assuming that's why
lld-link doesn't just translate internally. It may also just be because few
people actually care about address map files so support was missed. Apologies
if this has been addressed in the past, but searching for "lld" and "map"
doesn't exactly produce a concise list of results.
Example failures on the command line:
<span class="quote">>lld-link /DEBUG:FastLink ManifestDependency.obj</span >
lld-link.exe: error: could not open /DEBUG:FastLink: no such file or directory
<span class="quote">>lld-link /LTCG:incremental ManifestDependency.obj</span >
lld-link.exe: error: could not open /LTCG:incremental: no such file or
directory
<span class="quote">>lld-link /LTCG ManifestDependency.obj</span >
lld-link.exe: error: could not open /LTCG: no such file or directory
<span class="quote">>lld-link /MAP:SomeFile.map ManifestDependency.obj</span >
lld-link.exe: error: could not open /MAP:SomeFile.map: no such file or
directory
Since these issues all reproduce outside of the msbuild integration, it is
reasonable to say that this isn't just to be addressed in
LLVM.Cpp.Common.targets, but it seems like those first three command line
examples would still possibly emit warnings or just silently translate
internally.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>