[llvm-bugs] [Bug 38799] New: msbuild integration: suppressing and translating more properties

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=38799

            Bug ID: 38799
           Summary: msbuild integration: suppressing and translating more
                    properties
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: mike.winterberg at gmail.com
                CC: llvm-bugs at lists.llvm.org

Visual Studio 2017 Update 8 introduced a new compiler option, /JMC to integrate
with the debugger. The "advertising" for it is described here:
https://blogs.msdn.microsoft.com/vcblog/2018/06/29/announcing-jmc-stepping-in-visual-studio/
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:

>lld-link /DEBUG:FastLink ManifestDependency.obj
lld-link.exe: error: could not open /DEBUG:FastLink: no such file or directory

>lld-link /LTCG:incremental ManifestDependency.obj
lld-link.exe: error: could not open /LTCG:incremental: no such file or
directory

>lld-link /LTCG ManifestDependency.obj
lld-link.exe: error: could not open /LTCG: no such file or directory

>lld-link /MAP:SomeFile.map ManifestDependency.obj
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180831/0b99c9f5/attachment.html>