What good do things like this do me?

(gdb) bt
#0  0x0040460c in AbortHandler () at C:\ctwoplus\progcode\ManyMouse\src\RawInputMain.cpp:23
#1  0x73e37720 in raise () from C:\WINDOWS\SysWOW64\msvcrt.dll
#2  0x00000016 in ?? ()
#3  0xe071adbb in ?? ()
#4  0x73e91248 in msvcrt!_iob () from C:\WINDOWS\SysWOW64\msvcrt.dll
5  0x6775ced0 in __func__.35133 () from c:\ctwoplus\progcode\ManyMouse\cbbuild\bin\allegro_monolith-debug-5.2.dll 
#6  0x00000000 in ?? ()

At least some of the ones in this come with line numbers. Which makes it even more mystifiying as to why gdb doesn't know which function it is in.

Is there any way to figure out what functions these are? I seem to have hit my limit with gdb. And it has so many quirks that I just can't figure out yet.

As an aside I discovered process / record ability of gdb, but guess what it's not supported on 'my platform' yet.

Are there any better debuggers out there? I'm reluctant to use MSVC because I have to build a dll to use windows hooks and for that I have to write my own .def file and I haven't figured out how to automate it yet. Why isn't MSVC smart enough to write its own def file yet??? It's 2016 already. There's got to be some configuration somewhere in that steaming monstrosity that does this for me.

I'm getting really tempted to try out Clang/LLVM. What about LLDB? I can't find any windows binaries for it.

Does anyone know what that means? Anyone have any experience debugging with LLDB on Windows yet?

Unless you require more advanced features, MSVC supports __declspec(dllexport) (see https://msdn.microsoft.com/en-us/library/a90k134d.aspx).

I found Clang had quirks when I tried it last year on Windows (about a year ago now), such as C++ exceptions having little to no support. Also, I found most open source projects expected Visual Studio or GCC on Windows, if they had build scripts that supported Windows at all, which resulted in many headaches.

Regardless, Visual Studio's debugging features are much better than GDB on Windows. If anything, you should use Visual Studio for its debugging capabilities.

I 100% agree with Aaron.

Visual Studio is the de facto standard for developing on Windows. Visual Studio 2015 Community Edition is completely free and comparable to older paid professional versions. Visual Studio "15" preview is currently available if you want to go bleeding edge, too.

The last time I tried to get my cross-platform Allegro application to build in VS2015 I absolutely could not get it to work. Is there a good place to start looking for guidance?

Visual Studio is getting more and more standard-conform every year, though. 2015 made some great progress in this area. Not only that, but it also includes a clang Toolset if you need even more standard-compliance.

My main reason for hating MSVC is that it is a terrible IDE compared to CodeBlocks, but I can't get the MSVC compiler to work with CB at least not last time I checked. :/

In fact, as of VS2015 Update 2 it is 100% C++17 feature-complete in the STL.

Wait, really? I could never get used to Code::Blocks IDE at all and MSVC is pretty much the only IDE I can work with productively at all, especially once I install Visual Assist. Admittedly, that plugin is quite expensive, but since you only need to buy it once (unless you want all updates), this was worth it to me. After having used that plugin once at work, I pretty much can't work without it anymore. It just saves you so much time doing trivial things. Code::Blocks, on the other hand, just always seemed way too basic for me and - for simple use - also too complex. I mean, it can't even be used without setting up the complete compiler toolchain yourself (unless I remember that wrong?), which for an average user is definitely too complicated. I don't know how much the IDE has changed over the last few years, though. There were also some rather nasty bugs back then. For example: Breakpoints in your application never fired if your project was saved in a path that contained spaces. Don't know why that was. Granted, Visual Studio also contains a ton of bugs (as probably every IDE does), but so far I at least didn't stumble upon any that prevented me from doing basic development.

In the end, I guess, it all comes down to what IDE you're used to. Visual Studio is what I work with most, so that's probably why it's the best IDE to me. If I had to work with Code::Blocks every day, I might eventually get used to it.

Thanks Aaron for that link. It led me to exactly what I needed. Apparently I don't need a .def file as long as I use __declspec(dllexport). But now I need to write a DllMain (MinGW provides it for you).

@RPG_Hacker
I just find CodeBlocks so much simpler and easier to navigate. And its code completion has advanced leaps and bounds in the last year or two (You have to use the nightly builds, but there are windows binaries for them). It also has a much better file explorer and actually has some sense of sanity when it comes to project folder layouts and "solutions" (I use that term loosely).

As to having to specify everything in the toolchain, that's not true (anymore?) and hasn't been for some time. All you have to do is specify the compiler from a list of detected installed compilers. It autodetects MinGW and GCC and MSVC as well as many others. Then the toolchain information is filled in for you. Of course you can do it manually too if you want.

Don't know what the status of debugging functionality in CB is but I always used GDB from the command line anyway.

Yeah, that's one of the few important things that Visual Studio is actually missing natively. Luckily, Visual Assist adds a great and fast file search to Visual Studio, which simplifies things a lot. It also comes with a lot of other features (such as better auto completion or a great symbol search dialog), so you're not just paying for a missing features. Nevertheless you have a point. Visual Studio should have that natively. Even XCode has a file search like that natively, and XCode is total garbage.

Yeah, I think I remember what the problem was now. Back then, I was actually following an Allegro setup tutorial from the Wiki, and this tutorial for some reason made you set up the whole toolchain yourself. I don't know why that was, but that's probably what stuck with me.

Anyways, all this considered, I still consider Visual Studio to be a bit more friendly to beginners, and I personally think that all important project properties and settings are easy to find in Visual Studio. I remember that in Code::Blocks, I sometimes had to search quite a while to find some stuff I was looking for. Maybe it has advanced in this field as well, though.

Source level debugging in Codeblocks is easy enough. You can set breakpoints, step line by line, execute to line #, etc.

Did you compile with -g before passing your junk to gdb ?

Of course I did. I'm not that big of a newb.

Visual Assist plus Atomineer Utils is heaven.

I've been using Visual Assist for about 6 years now and can't live without it. The rename/Create Impl. function(s) alone are amazing. Smart project-wide renames have saved me a ton of time.

In later versions of Visual Studio (2010, I think) the syntax/code highlighting is redundant though.

Edgard: I don't know, I never make silly coding mistakes which generate cryptic output ;-p

Yeah, but I kinda appreciate the fact that Visual Assist just uses the same coloring scheme across all versions of Visual Studio. This makes it easy to adjust when you have to switch between many different versions of Visual Studio regularly (which I have to do at work, thanks to certain console debuggers/compilers only including bindings for certain versions of Visual Studio). Being able to always instantly associate color with syntax really saves you a lot of adjustment time when switching between versions. Another benefit of Visual Assist's syntax highlighting and auto completion is that they both work in places where Visual Studio fails completely. Taking work as an example again: At work, we generate our Visual Studio projets with our own build system (lace). For some reason, on those generated projects, Visual Studio's auto completion and syntax highlighting just fail completely (almost the whole text appears in default text color). Visual Assist still works fine on those projects, though, and offers you both: Great and functional auto completion and reliable syntax highlighting. It would be almost impossible to use those generated projects without Visual Assist.