Code::Blocks / Tickets / #282 Windows: Let 32bit C::B break a 64bit debugee when debugging

Teodor Petrov - 2016-01-19

Type: Undefined --> Feature_Request
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

bluehazzard - 2019-01-20

assigned_to: bluehazzard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

bluehazzard - 2019-01-20

We probably can close this, because nightlies are 64bit now by default.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Teodor Petrov - 2019-01-21

I doubt... The current debugging experience on windows is quite bad. Ollydbg fixed one of the issues, but I'm sure we have more.

Also I hope we'll have a 32bit release, because I'm sure there would be a lot of people which would need this release.

Also now it is important to make sure that 64bit cb could break 32bit executables.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ollydbg - 2019-01-22

64bit C::B can't break the 32bit debugee. (I have experience this issue months ago). To solve this issue, we need some "bridge", which means, if we wan't to break a 32bit debugee, we need a "bridge" 32bit executable which can call the DebugBreak function call. It's the same for debugging 64bit debugee. I believe Codelite also use this way.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

bluehazzard - 2019-01-22

wow, i am impressed how fuXXXX up this is. Microsoft at the best again... So there is no way around a second binary...
related qt creator commit with some usefull information:
qtcreator commit for breaking debugger
qt creator related aapplication:
qtcreator debugger interrupt application

does this extend to killing the application also? Or only breaking the debugger?

[edit:] Does something speaks against using always the external application? I think this would reduce the code maintaining...

Last edit: bluehazzard 2019-01-22

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Andrew Cottrell - 2022-06-23

IMHO I do not think it is worth doing anything to fix this as there are not allot of devs using C::B for 32bit compared to 64bit. So long as there is a C::B 32bit release available or build able for devs to use then they can use this for 32bit development instead of someone spending time resolving this like qtcreator did as there are more important issues/bugs to work on.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

bluehazzard - 2022-06-23

status: open --> wont-fix
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

bluehazzard - 2022-06-23

I am with you... Closing this for now....

👍
1

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ollydbg - 2022-06-24

I also agree, I am fully working under 64bit Windows system, so all the tool-chain I use are 64 bit now.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Morten MacFly - 2022-06-24

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Morten MacFly - 2022-06-24

There is one thing which is bad: A lot embedded compilers and processors are 32 bit and have a gcc compatible tool chain. This segment we loose, which is bad.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Andrew Cottrell - 2022-06-24
  
  How exactly are you loosing this segment as I said "So long as there is a C::B 32bit release available or build able for devs to use then they can use this for 32bit development...."?
  How is is having a 32buit C::B release or having the abiliy to build a 32bit C::B release bad?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Morten MacFly - 2022-06-25
    
    When we discussed the last release, most devs voted not to provide the 32 bit version anymore. But in the end we did. We should, however, always strive for simplicity and provide a one-for-all solution. Since people also don't read these days they will download the first one available and if it doesn't work they will either flood the forums or just use another IDE. That's why I believe we will use the embedded 32 bit people on the long run.
    
    If I look at:
    https://github.com/qt-creator/qt-creator/commit/2bc24b7a25ba7faf523166bbb75e36a9e7528124
    ...as ollydbg suggested it doesn't seem too hard? Or am I missing some show-stoppers?
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Windows: Let 32bit C::B break a 64bit debugee when debugging

A free C, C++ and Fortran IDE

Milestone

Searches

Help

#282 Windows: Let 32bit C::B break a 64bit debugee when debugging

Discussion