Author Topic: JIT debugger  (Read 5435 times)

Offline everSome

  • Multiple posting newcomer
  • *
  • Posts: 34
JIT debugger
« on: February 19, 2022, 06:56:58 pm »
I've come to understand that CodeBlocks uses Dr Mingw as its JIT debugger. But I'm wondering how useful that is considering that strip is run against all the .exe and .dll files in output31_64.

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: JIT debugger
« Reply #1 on: February 19, 2022, 10:10:35 pm »
useless i suppose....
i asked killerbot to not strip the nightlies, but i did not get any response

Offline AndrewCot

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 678
Re: JIT debugger
« Reply #2 on: February 20, 2022, 12:34:11 am »
everSome, What are you trying to do?

The doc I posted for you to follow a while ago has info on debugging codeblocks, my post was:
https://forums.codeblocks.org/index.php/topic,24814.msg169333.html#msg169333

Offline everSome

  • Multiple posting newcomer
  • *
  • Posts: 34
Re: JIT debugger
« Reply #3 on: February 21, 2022, 02:55:51 am »
What are you trying to do? I'm poking around the edges of compiling CodeBlocks with just the MSYS2 tool chains installed on my system. Not being enamored with the out of band binaries existing in src/exchndl, I looked into what that's for. Turns out that MSYS2 has binary packages for Dr Mingw for the various MSYS2 environments. So I loaded these binary packages and compiled against them. For instance, the UCRT64 package's url is:
https://packages.msys2.org/package/mingw-w64-ucrt-x86_64-drmingw?repo=ucrt64
This supplies exchndl.dll and mgwhelp.dll
The dbgcore.dll, dbghelp.dll, and symsrv.dll are distributable Microsoft components, but more up to date versions can be had directly from them if one wishes. The mgwhelp.dll is used to access dwarf (something like Debug With Arbitrary Record Format) information whereas dbgcore/dbghelp stuf is used to access Microsoft's PDB debug information files. symsrv.dll is used to access Microsoft's publicly exposed Symbol server, and symsrv.yes keeps the damn thing from trying to dialog with the user on startup. I'm just an old fart with time on his hands! But I'm learning. It just seemed odd to me that there is this elaborate construction to provide a postmortem dump but not feed it any debugging info. Just wondering if there was a back door to such info, but I guess not. Unwinding a stack usually needs all the help it can get.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: JIT debugger
« Reply #4 on: July 30, 2022, 04:33:11 pm »
Hi, everSome,

Do you have the latest drmingw 0.9.5 working with the current SVN head of C::B?

See this post:

error alert message when using ThreadSearch Plugin

It looks like I have some problem with the latest version of drmingw.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline everSome

  • Multiple posting newcomer
  • *
  • Posts: 34
Re: JIT debugger
« Reply #5 on: September 02, 2022, 10:43:57 pm »
Hi, everSome,

Do you have the latest drmingw 0.9.5 working with the current SVN head of C::B?

See this post:

error alert message when using ThreadSearch Plugin

It looks like I have some problem with the latest version of drmingw.

I'll take a look at it. Note that I'm running in a strictly MSYS2 environment; so, I just picked it up via:
pacman -S --needed mingw-w64-ucrt-x86_64-drmingw
as ucrt-x86 is the tool chain I'm currently using. Had to make some .cbp changes to derefernce much of what's in the exchndl directory.  I did notice an off hand comment in Dr Ming stating that he'd seen seen some problems with some windows tool chains not emitting a frame pointer in stack frames. Didn't mention which tool chains though. For safety I just throw in a
-fno-omit-frame-pointer
compiler flag for all wxWidgets and CodeBlocks builds. gcc and g++ take the option without complaining, but I don't know if it's really needed.

Update: gcc documentation says "Most optimizations are completely disabled at -O0 or if an -O level is not set on the command line ..." Note that, as -fomit-frame-pointer is listed as being turned on by -O, -O1, or -Og, usage of these options or -O2 or -O3 as well seems to require the inclusion of the -fno-omit-frame-pointer for Dr Mingw to work when one compiles with gcc.
« Last Edit: September 08, 2022, 01:55:12 pm by everSome »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: JIT debugger
« Reply #6 on: September 03, 2022, 08:32:33 am »
Hi, everSome, the issue is already identified and fixed, I'm just waiting for the fix to arrive in the drmingw's git.

See this ticket:
ExcHndl.dll can't print the crash call stack under Windows 7
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: JIT debugger
« Reply #7 on: September 16, 2022, 08:40:23 am »
Hi, everSome, the drmingw 0.9.7 is released, see here:

Release 0.9.7 jrfonseca/drmingw
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.