How do I generate pure code (without runtime checks) in VC++ 2010 Express ? For example I removed Buffer Security Check ( set compile opt /GS-), but in my code I again saw these calls
call __security_init_cookie
...
call _RTC_CheckEsp
...
call _RTC_CheckEsp
...
How do I remove these calls?
The MSVC docs indicate that __security_init_cookie is called by the CRT runtime for "code compiled with /GS (Buffer Security Check) and in code that uses exception handling" (emphasis added). See http://msdn.microsoft.com/en-us/library/ms235362%28v=VS.100%29.aspx
I wouldn't be surprised if there's code in the runtime library itself that depends on the security cookie having been initialized, whether your code uses it or not (in other words, the runtime library code may have been compiled with /GS, and if so, it needs the cookie initialized whether or not your code does).
As for the _RTC_CheckEsp call - that should be controlled by the /RTCs or the /RTC1 option. Remove those options from your build and there should be no calls to _RTC_CheckEsp.
Disable /RTC compiler switch
http://msdn.microsoft.com/en-us/library/8wtf2dfz.aspx
Related
I'm debugging a CMake target in Visual Studio 2019 for a project which is managed by CMake and built using MinGW.
However, when an assertion fails the debugger simply quits without giving me a call stack or letting me inspect the current state of the program. (Normal breakpoints do suspend execution as expected.)
I've enabled Break When Thrown for all C++ Exceptions in Debug > Windows > Exception Settings, but to no avail.
How can I make Visual Studio break execution when an assertion fails?
If your project is a "Console" application rather than a "Windows" application and you have used <assert.h> then according to the documentation:
The destination of the diagnostic message depends on the type of
application that called the routine. Console applications receive the
message through stderr. In a Windows-based application, assert calls
the Windows MessageBox function to create a message box to display the
message with three buttons: Abort, Retry, and Ignore
So a possible solution is to temporarily build your program as a "Windows" app by adding the WIN32 option to your executable definition:
add_executable(<name> WIN32 [source1] [source2 ...])
It is possible that the NDEBUG macro is enabled in your project and that stops VS from breaking on assertion failure.
From cppreference
If NDEBUG is defined as a macro name at the point in the source code
where is included, then assert does nothing.
If NDEBUG is not defined, then assert checks if its argument (which
must have scalar type) compares equal to zero. If it does, assert
outputs implementation-specific diagnostic information on the standard
error output and calls std::abort. The diagnostic information is
required to include the text of expression, as well as the values of
the standard macros FILE, LINE, and the standard variable
func (since C++11).
My code is like this:
void some_func(void *source)
{
...
double *casted = reinterpret_cast<double *>(source);
...
}
This causes std::__non_rtti_object exception. Acording to stack trace, it is raised from __RTDynamicCast, which is (as far as i know) MSVC implementation of dynamic_cast.
This exception should occur with dynamic_cast, as the pointer comes from external library (probably compiled without /GR) and points to struct with several doubles. But I would not expect this with reinterpret_cast. Shouldn't it just change the type of the pointer, without any checks at all?
Notes:
my compiler is msvc120 (MS Visual Studio 2013)
project is compiled with /GR (enable run-time type information)
pointer "source" comes from external library (probably compiled without /GR)
I also tried static_cast with the same result
Non-reproducible.
Ah, i tried to rebuild whole project with all additional libraries and
the problem disappeared. Seems strange, because I never had a code
using dynamic_cast, so don't know what caused this. Also I already
tried to rebuild that project only (without other dlls) before.
Anyway, thanks for all help.
-- OP
It seems as that you need to recheck dll's order of build in your makefile (if you use such). I guess that the source from the external library you mentioned, comes from external library that is "higher" in the build tree than the library which your code resides. Try to see if your makefile properly works (maybe misses some triggers).
I am in the process of upgrading a Visual Studio 2010 project that targets the INtime RTOS. Code that performs casting operations fail to link. When investigating the "inline assembly" output files, it turns out that for some integer casting operations, VS2013 is generating assembly instructions to calls to __dtol3, __dtoui3, __dtoul3, __ltod3, and __ultod3. The problem is that the INtime libraries do not contain definitions for these functions. I've verified that VS2013 does the same for Win32 targets for both Debug and Release builds.
Is there a way to get VS2013 to stop generating generating calls to these functions?
You would need to disable SSE2 codegen, through use of the /arch option (use either /arch:IA32 or /arch:SSE).
Alternatively...(what follows is not officially supported; your mileage may vary; do this at your own risk)
Extract from msvcrt.lib the object that defines these functions, and link that object directly into your program. These functions are defined in the object named ftol3.obj; you can extract it using the lib tool:
=>lib /nologo /list msvcrt.lib | findstr ftol3
f:\binaries\Intermediate\vctools\crt_bld\SELF_X86\crt\prebuild\INTEL\dll_lib\ftol3.obj
=>lib /nologo /extract:f:\binaries\Intermediate\vctools\crt_bld\SELF_X86\crt\prebuild\INTEL\dll_lib\ftol3.obj msvcrt.lib
You may need additional objects, depending on (a) which functions you use and (b) what, exactly, the INtime libraries define. Again, this is not a supported way to use the Visual C++ runtime libraries, and it may or may not work for your particular use case.
possibly another way:
add compile option
/d2noftol3
this option is undocumented
Try create one of them __dtol3, __dtoui3, __dtoul3, __ltod3, and __ultod3, for ex.
extern "C" unsigned int _dtoui3(const double x) {
return (unsigned int) _mm_cvttsd_si32 (_mm_set_sd(x));
}
Make function externally visible and implement in one file.
Some info
I have a DLL which throws an exception like so:
throw POMException(err, drvErr, errmsg);
The calling code is in a separate program, and has a try, catch block like so:
try
{
// function in separate DLL
}
catch (TXNPDO_Exception& e)
{
SR_PERFLOG_MSG(SR_PERFMASK_SELECT, "ERROR selectInStages");
TXNDBO_THROW(e);
}
Where TXNPDO_Exception is defined in an included file:
#define TXNPDO_Exception POMException
When running this in a debugger, it states that the POMException was unhandled. I even added a catch(...) clause and it still isn't handled.
I suspect that this has something to do with the Visual C++ compilation parameters, since the DLL library in question is a legacy library that is compiled separate to the program calling it. I am using Visual Studio 2003.
The DLL cpp files are compiled with the following (relevant) flags: /X /GR /Ob1 /Zi /GX /Od /MDd /LD. Other exceptions within the calling program are handled correctly.
Can anyone provide reasons why this exception isn't being propagated to the calling program?
Edit:
The DLL library was previously compiled with possible build environment and code changes that are not available to me. The previously compiled library propagates exceptions correctly.
I am compiling the client program using the same compiler, using mostly the same switches: -Od -W3 -Z7 -MDd -GX -GR -Zm800 (no /X or /Ob1 and /Z7 instead of /Zi).
I would assume that throwing exceptions across .dll boundaries could only be possible, when the various .dll and program executable are compiled against the same C++ runtime, thus sharing the same heap. I could be wrong, but this is my best guess.
Edit:
I guess I wasn't wrong.
I have finally figured out what the problem is, and in this particular case, it is nothing to do with throwing exceptions between DLLs.
The problem is occurring due to an exception handler hook being installed further up the call stack. I diagnosed this by adding try, catch(...) blocks to every level in the library until I found the point at which the exception wasn't propagated. When I commented out the exception handler hook registration code, the exception was successfully propagated.
I now have to figure out the workings of exception handler hooks, which is outside the scope of this question. Thanks to everyone who shared their answers.
I am writing assembly-level optimized code, and I need to make sure that the C++ compiler is working with it correctly in Release-Mode.
I used to be able to get Release-Mode programs to break on breakpoints in VS 2002 (and display the raw disassembly as I stepped through it), but I can't remember how I got that to work. Does VS 2010 have any options that might allow this to happen?
Compile with /Zi and link with /DEBUG and you'll be able to set breakpoints.
Under a project's Properties dialog:
/Zi can be enabled in C++ --> General --> Debug Information Format
/DEBUG can be enabled in Linker --> Debugging --> Generate Debug Info
If you want to use the debugger to view the disassembly, you can place a __debugbreak() intrinsic call right before the code which you want to view.
If you're writing straight assembly, you can just use INT 3. When you place a breakpoint using the debugger, it actually changes the code to that (0xCC in binary) so the debugger will get called when it's executed.
You can also call one of the functions that do that for you like zr suggested. The Windows one is DbgBreakPoint(). If you disassemble it, you could easily see it's nothing but INT 3.
These used to be methods of causing breakponts:
_asm
{
int 3
}
or
_asm
{
_emit 0xcc
}
or was it
_emit 0xcc
I'm not sure of the syntax (it's been a while) but hopefully something can be made of it.