Chromium `debugger` equivalent, on `gdb` for Cygwin? - c++

How do people trigger a breakpoint on gdb (for Cygwin, specifically) from the very source code?
Like when a JS script has the debugger word in it and Chromium dev tools trigger stop for debugging?

Here's how SDL2 implements this feature:
#if defined(_MSC_VER)
/* Don't include intrin.h here because it contains C++ code */
extern void __cdecl __debugbreak(void);
#define SDL_TriggerBreakpoint() __debugbreak()
#elif ( (!defined(__NACL__)) && ((defined(__GNUC__) || defined(__clang__)) && (defined(__i386__) || defined(__x86_64__))) )
#define SDL_TriggerBreakpoint() __asm__ __volatile__ ( "int $3\n\t" )
#elif defined(__386__) && defined(__WATCOMC__)
#define SDL_TriggerBreakpoint() { _asm { int 0x03 } }
#elif defined(HAVE_SIGNAL_H) && !defined(__WATCOMC__)
#include <signal.h>
#define SDL_TriggerBreakpoint() raise(SIGTRAP)
#else
/* How do we trigger breakpoints on this platform? */
#define SDL_TriggerBreakpoint()
#endif
The conditionals should probably resolve to __asm__ __volatile__ ( "int $3\n\t" ) on Cygwin.

Related

using #if to run a function

I'm trying to run the expression _setmode only if I'm using Windows, and setlocale only if I'm using Linux, but I can't manage to make them work with a simple if-else inside a function due to Linux having errors with the Windows libraries, and vice versa.
#if defined(_WIN32) || defined(_WIN64) || (defined(__CYGWIN__) && !defined(_WIN32))
#define PLATFORM_NAME 0
#include <io.h>
#include <fcntl.h>
#elif defined(__linux__)
#define PLATFORM_NAME 1
#include <locale>
#elif defined(__APPLE__) && defined(__MACH__)
#include <TargetConditionals.h>
#if TARGET_OS_MAC == 1
#define PLATFORM_NAME 2
#endif
#else
#define PLATFORM_NAME NULL
#endif
#if PLATFORM_NAME == 0
_setmode(_fileno(stdout), _O_U8TEXT);
#endif
#if PLATFORM_NAME == 1
setlocale(LC_CTYPE, "");
#endif
If you write OS-dependent* code (as in this case), you can manage it at compile-time**. To do this, we need two parts:
Define OS-dependent constants (optional, if condition simple, this part can be omitted):
#if defined(_WIN32)
#define PLATFORM_NAME 0
#include <fcntl.h>
#include <io.h>
#elif defined(__linux__)
#define PLATFORM_NAME 1
#include <locale>
#endif
In needed place call OS-dependent code with preprocessor conditions:
#if PLATFORM_NAME == 0
//Windows code here
#endif
You can write more complex conditions:
#if PLATFORM_NAME == 0
//Windows code here
#elif PLATFORM_NAME != 0
//Non-Windows code here
#if PLATFORM_NAME == 1 || PLATFORM_NAME == 2
//Linux or unknown OS code here
#endif
#endif
See restrictions of conditions here
Tip: If your code have entrypoint (main function as example), you can call most of OS-dependent code at main if this help to reduce code. In library you can place OS-dependent code to dedicated source-file functions like there. Usage preprocessor-time code is good method for writing zero-cost runtime code because of preprocessor just remove all sources,if they're not met conditions.
* - or whatever-dependent 😃
** - more precisely, preprocessor-time
Source: GNU, Microsoft docs.

C++ Unresolved External Symbols Embedded Lua ( based on longjmp issue ) ( not duplicate )

I will describe the problem as follows:
Compiler: Visual Studio 2019
The root of the problem is that longjump crashes the process because I manually map my code to the process.
The code works fine as follows, but crashes on any syntax error in the lua script due to longjump:
extern "C" {
#include "lua.h"
#include "lualib.h"
.....
}
I want C++ exceptions originating from:
#if defined(__cplusplus) && !defined(LUA_USE_LONGJMP) /* { */
/* C++ exceptions */
#define LUAI_THROW(L,c) throw(c)
#define LUAI_TRY(L,c,a) \
try { a } catch(...) { if ((c)->status == 0) (c)->status = -1; }
#define luai_jmpbuf int /* dummy variable */
#elif defined(LUA_USE_POSIX) /* }{ */
/* in POSIX, try _longjmp/_setjmp (more efficient) */
#define LUAI_THROW(L,c) _longjmp((c)->b, 1)
#define LUAI_TRY(L,c,a) if (_setjmp((c)->b) == 0) { a }
#define luai_jmpbuf jmp_buf
#else /* }{ */
/* ISO C handling with long jumps */
#define LUAI_THROW(L,c) longjmp((c)->b, 1)
#define LUAI_TRY(L,c,a) if (setjmp((c)->b) == 0) { a }
#define luai_jmpbuf jmp_buf
#endif /* } */
Because longjmp crashes my process.
So I decided to compile my code with the C++ compiler (without extern C) and:
#include "lua.h"
#include "lualib.h"
.....
This is how I called it. But this also led to the following problem:
error LNK2019: unresolved external symbol _lua_pcall
...
...
...
I thought a lot about it but couldn't find a solution.It's ridiculous that it's a linker error because all the lua header and c files are joined to my project.
#define LUAI_THROW(L,c) c->throwed = true
#define LUAI_TRY(L,c,a) \
__try { a } __except(filter()) { if ((c)->status == 0 && ((c)->throwed)) (c)->status = -1; }
#define luai_jmpbuf int /* dummy variable */
Btw, i solved my throwing exception issue like that. Im not sure its correct or no but not crashing anymore.
struct lua_longjmp {
struct lua_longjmp *previous;
luai_jmpbuf b;
volatile int status; /* error code */
bool throwed;
};
Works as expected even you build without C++ exceptions

C++ Platform Support

I am planning to make my C++ application compatible with Windows/Mac/Linux. At the moment I came up with this "code":
#if defined(_WIN32) || defined(WIN32) || defined(__WIN32__) || defined(__NT__)
#include <Windows.h>
#elif defined(__APPLE__) || defined(__MACH__)
#include <TargetConditionals.h>
#if TARGET_IPHONE_SIMULATOR == 1
#error "IOS simulator is not supported!"
#elif TARGET_OS_IPHONE == 1
#error "IOS is not supported!"
#elif TARGET_OS_MAC == 1
//MAC??????
#else
#error "Unknown Apple platform!"
#endif
#else
#error "The platform you are currently using is not compatible!"
#endif
I don't know if I implemented Windows correctly, but at least I know what to include. So my questions are:
What do I need to import to use the Mac system library?
How can I implement linux support and what do i need to include to use his library?
I need the system libraries because later I planned to make a window class based on the system's libraries, I think you can do it for Windows but I am not really if you can do it sure on linux/mac.
Update #1:
Ok so I figured out which macros to use but what libraries should I include?
#if defined(_WIN32) || defined(WIN32) || defined(__WIN32__) || defined(__NT__) || defined(__CYGWIN__) || defined(__CYGWIN32__)
#define PLATFORM_WINDOWS
#include <Windows.h>
#elif defined(__APPLE__) && defined(__MACH__)
#include <TargetConditionals.h>
#if TARGET_IPHONE_SIMULATOR == 1
#define PLATFORM_IPHONE_SIMULATOR
#error "Iphone simulator environment is not compatible!"
#elif TARGET_OS_IPHONE == 1
#define PLATFORM_IPHONE
#error "Iphone environment is not compatible!"
#elif TARGET_OS_MAC == 1
#define PLATFORM_MACOS
//what do I need to include here???
#endif
#elif defined(__ANDROID__)
#define PLATFORM_ANDROID
#error "Android environment is not compatible!"
#elif defined(__linux__) || defined(__linux) || defined(linux)
#define PLATFORM_LINUX
//what do i need to include here???
#else
#error "The platform you are currently using is not compatible!"
#endif

What are the performance impacts that Expects(cond) of the GSL imposes on the runtime?

The CPP Core Guidelines propose to use Expects(expression) to state preconditions and Ensures(expression) to state postconditions from the GSL in functions.
Example:
int area(int height, int width)
{
Expects(height > 0 && width > 0); // good
if (height <= 0 || width <= 0) my_error(); // obscure
// ...
}
What is the performance impact of these macros?
Is it just as checking the condition with if and then throwing an exception?
Is there a difference between debug and non-debug mode?
I.e. are the macros also active if the app is built as a release?
I ask because I am thinking about using it as a good practice, i.e. try, if there is not a specific reason against it, just stating possible pre/post conditions (assuming it is not sensible to use different types as parameters) using these macros from the GSL.
These macros are defined in the gsl_assert header.
Here's the relevant code:
#define Expects(cond) GSL_CONTRACT_CHECK("Precondition", cond)
#if defined(GSL_THROW_ON_CONTRACT_VIOLATION)
#define GSL_CONTRACT_CHECK(type, cond) \
(GSL_LIKELY(cond) ? static_cast<void>(0) \
: gsl::details::throw_exception(gsl::fail_fast( \
"GSL: " type " failure at " __FILE__ ": " GSL_STRINGIFY(__LINE__))))
#elif defined(GSL_TERMINATE_ON_CONTRACT_VIOLATION)
#define GSL_CONTRACT_CHECK(type, cond) \
(GSL_LIKELY(cond) ? static_cast<void>(0) : gsl::details::terminate())
#elif defined(GSL_UNENFORCED_ON_CONTRACT_VIOLATION)
#define GSL_CONTRACT_CHECK(type, cond) GSL_ASSUME(cond)
#endif // GSL_THROW_ON_CONTRACT_VIOLATION
As you can see, it depends on how you choose to handle contract violations. In the first two cases, you will pay the cost of a branch plus either throwing an exception or calling std::terminate.
In the case that GSL_UNENFORCED_ON_CONTRACT_VIOLATION is defined, the macros will expand to GSL_ASSUME:
//
// GSL_ASSUME(cond)
//
// Tell the optimizer that the predicate cond must hold. It is unspecified
// whether or not cond is actually evaluated.
//
#ifdef _MSC_VER
#define GSL_ASSUME(cond) __assume(cond)
#elif defined(__GNUC__)
#define GSL_ASSUME(cond) ((cond) ? static_cast<void>(0) : __builtin_unreachable())
#else
#define GSL_ASSUME(cond) static_cast<void>((cond) ? 0 : 0)
#endif
In that case, the condition might or might not be evaluated depending on the compiler. It can also make your code faster as the compiler might be able to optimize more aggressively thanks to the assumptions.
There is no deactivation as for an assert, the condition will be tested all the time:
#if defined(__clang__) || defined(__GNUC__)
#define GSL_LIKELY(x) __builtin_expect(!!(x), 1)
#define GSL_UNLIKELY(x) __builtin_expect(!!(x), 0)
#else
#define GSL_LIKELY(x) (!!(x))
#define GSL_UNLIKELY(x) (!!(x))
#endif
And then yes, it throws an exception or even terminate depending on your settings:
#if defined(GSL_THROW_ON_CONTRACT_VIOLATION)
#define GSL_CONTRACT_CHECK(type, cond) \
(GSL_LIKELY(cond) ? static_cast<void>(0) \
: gsl::details::throw_exception(gsl::fail_fast( \
"GSL: " type " failure at " __FILE__ ": " GSL_STRINGIFY(__LINE__))))
#elif defined(GSL_TERMINATE_ON_CONTRACT_VIOLATION)
#define GSL_CONTRACT_CHECK(type, cond) \
(GSL_LIKELY(cond) ? static_cast<void>(0) : gsl::details::terminate())
#elif defined(GSL_UNENFORCED_ON_CONTRACT_VIOLATION)
#define GSL_CONTRACT_CHECK(type, cond) GSL_ASSUME(cond)
#endif // GSL_THROW_ON_CONTRACT_VIOLATION
If GSL_UNENFORCED_ON_CONTRACT_VIOLATION is set, nothing happens.
I have a feeling that Expects is slightly against the spirit of C++ (as I perceive this spirit) ... Maybe it would really be good if C++ was more mainstream and Java-like but for me its original idea is to provide maximum performance (sometimes at the cost of less safety/more complexity/lower readability). I think we can obtain both goals without sacrifising performance. For me the solution is quite simple - custom assert (cassert) - that is the fast assert that can be switched on or off for release builds.
Sample implementation (Windows only) :
// cassert.h:
#pragma once
// Switch this macro off for maximum performance release builds:
#define __RELEASE_WITH_ASSERTS__
#ifndef cassert
#if defined(_DEBUG) || defined(__RELEASE_WITH_ASSERTS__)
void __cassert(bool val, const char* szFile, int line, const char* szDesc);
#define cassert(a) ((a) ? ((void)1) : __cassert(a, __FILE__, __LINE__, _CRT_STRINGIZE(#a)))
#else
#define cassert(a)
#endif
#endif
// cassert.cpp
#if defined(_DEBUG) || defined(__RELEASE_WITH_ASSERTS__)
void __cassert(bool val, const char* szFile, int line, const char* szDesc)
{
if (!val)
{
std::string sIgnore;
int mode;
#if defined(_DEBUG)
sIgnore = "\n\nIgnore assertion?";
mode = MB_YESNO;
#else
sIgnore = "";
mode = MB_OK;
#endif
char szLine[16];
_itoa(line, szLine, 10);
std::string sAssertion = std::string("Assertion failed in file ") + szFile + " at line " + szLine + "\n" + szDesc;
Log(sAssertion.c_str());
if (MessageBoxA(NULL, (std::string("Assertion failed in file ") + szFile + " at line " + szLine + "\n" + szDesc + sIgnore).c_str(), "Assertion failed", mode | MB_ICONINFORMATION) == IDNO)
_CrtDbgBreak();
}
}
#endif
Such cassert will make even debug builds run much faster because there is no actual call to (c)assert function, if condition is satisfied (and every such call would be quite heavy because of _CRT_STRINGIZE(#a) (condition as a string).

Arduino platform compiler flag

Is there's any compiler flag to indicate the platform?
e.g:
#ifdef ARDUINO_UNO
....//code for uno
#elif ARDUINO_NANO
...//code for nano
#else
error("unknown platform");
#endif
In Arduino.h file, you can find the following preprocessor checks:
#if defined(__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__) || defined(__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)
...
#else
#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__) || defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)
...
#endif
I never tried these, but do not I see why you will not be able to use them in your code as well.