search

ldc-developers / ldc

The LLVM-based D Compiler.
http://wiki.dlang.org/LDC
Other
1.19k stars 258 forks source link

VS debugger throws Error: Could not find 'runtime\objects\rt\dmain2.obj' when linked with /DEBUG:FASTLINK #3083

Open rainers opened 5 years ago

rainers commented 5 years ago

Not sure when it started, but with recent versions of VS2017 or VS2019 I get this message in the debugger when the callstack of a simple "hello world" app is shown:

Error: Could not find 'runtime\objects\rt\dmain2.obj' in 'c:\D\ldc2-1.15.0-windows-multilib\lib64\druntime-ldc.lib'. WindowsApp2.exe was built with /DEBUG:FASTLINK which requires object files for debugging.

Maybe "fastlink" shouldn't be used for releases?

kinke commented 5 years ago

That has got to be a changed default setting for the MS linker, apparently depending on whether invoked from within the IDE. LDC itself only adds /DEBUG (with -g[c]). From MSDN:

When you specify /DEBUG with no additional options, the linker defaults to /DEBUG:FULL for command line and makefile builds, for release builds in the Visual Studio IDE, and for both debug and release builds in Visual Studio 2015 and earlier versions. Beginning in Visual Studio 2017, the build system in the IDE defaults to /DEBUG:FASTLINK when you specify the /DEBUG option for debug builds. Other defaults are unchanged to maintain backward compatibility.

rainers commented 5 years ago

Indeed, the message disappears with /DEBUG:FULL. But AFAICT the release library doesn't contain any debug info. I also don't see similar messages with dmd. BTW: there is an initial MessageBox, with further messages to the output window, but operation continues.

Trying again, the message appears when stepping into template instances of writeln. The first one is about sections_win64, so unlikely to be related to the actual callstack. I suspect there is something unexpected about the library, maybe that VS doesn't like the paths in the object file names. Is it generated by LLD instead of the MS lib tool?

kinke commented 5 years ago

Is it generated by LLD instead of the MS lib tool?

Sort-of (LLD doesn't archive AFAIK), it's a slightly modified copy of LLVM's llvm-lib.exe tool embedded in LDC.

I suppose everything's good when linking in a command-line (VS command prompt and naked) and so really just an issue if invoked within VS/VisualD?

rainers commented 5 years ago

Yeah, probably whenever linked with /DEBUG:FASTLINK which is the default for VC projects.

kinke commented 5 years ago

/DEBUG:FASTLINK works fine with the debug libs (-link-defaultlib-debug, also archived with LLVM).

kinke commented 5 years ago

... and the release libs also work fine if archived with MS lib.exe.

kinke commented 5 years ago

I guess VisualD links via the LDC executable, or does it invoke the linker directly?

rainers commented 5 years ago

It only links with LDC if "combined compile and link" is used with the visualdproj projects. Otherwise it calls link.exe directly. vcxproj projects use the standard linker build step, and that's the only place where /DEBUG:FASTLINK creeps in.

kinke commented 5 years ago

Ah ok, so there's not much LDC can do about it - using the MS librarian would be a CMake PITA, as we need llvm-lib for the LTO libs (and for cross-archiving).

rainers commented 5 years ago

I just compared the llvm-lib.exe generated library with an ms-lib.exe generated one: the LLVM has an extra slash at the end of the object file list when viewed in a text lister (not visible with /list though):

runtime\objects\core\atomic.obj/
runtime\objects\core\attribute.obj/
runtime\objects\core\bitop.obj/ 
...
kinke commented 5 years ago

I noticed that too yesterday when looking at the raw file and thought it may be the reason, but this is also the case for the debug libs, so I dropped that idea again.