Is it possible to debugging executables not compiled with code::blocks ?

[advance-software]

Hi,
 
    I'd like to debug firefox (compiled using script/makefile voodoo) on Linux using code::blocks as the debugging environment as you have one of the best Linux debugging environments I've seen so far. Is this possible ?

Couldn't immediately spot how to open an executable as a project for debugging. Sorry if I've missed something obvious.

Thanks for all the hard work - loving CB.

Best regards,
Steve.

[golgepapaz]

Debug -> Attach Process should do the trick.

[advance-software]

> Debug -> Attach Process should do the trick.

If it was already running, that'd work. Not much good if you want to step through the initialization code though.

[Jenna]

If you have makefiles, you might be able to create an empty custom makefile project, add all sources and headers to the project and run it through C::B.
You have to correct the settings in the projects properties, especially the project settings, to make it a custom makefile project and in the build target tab, so it uses the correct folders and executable.
Somewhere in the forum or the wiki(?), there is a more exact desciption, if I remember correctly, but I do not have the time to search it at the moment.

[advance-software]

hey jens - it's all complex python make weirdness. not expecting your stuff to interact with the build process. that can be done from the command line.

I just want to be able to use your interface to debug an existing compiled binary (with debug info) - as can be done in eclipse for example.

prefer your interface to eclipse, hence the request.

a big thank you for all your work on this project. this isn't urgent. can use ddd for now, but it would be nice & would extend the appeal/power of cb imo.

if I'm understanding you, perhaps this can be done by configuring a null custom compile somehow then specify the precompiled exe as the target.

project -> import -> [binary]  would be an  intuitive interface to this.

[oBFusCATed]

Two options:

1. make a dummy-empty-project, where you setup you executable paths and then disable the option "Settings -> Debugger -> auto build project if it is not up to data"
2. setup a custom makefile project

[advance-software]

Appreciated & will try that.

The point however stands that an [import project -> binary] UI option to automate this task would improve codeblocks as the procedure would be more intuitive.

Yes, I know everyone is busy & no, I don't have time to implement this right now either.  Just sayin'.

Once again, thanks for being awesome. Totally understand if this is prioritized way down the list.

Cheers.

[oBFusCATed]

I don't think it is even on the priority list (at least in mine), because C::B is not a debugger frontend, but a IDE.

[advance-software]

I hear you but you have pretty much all the components in place to do this, so why not. makes it a more useful product.

other usability feedback:

ctrl-h is search & replace in visual studio & gedit. you currently have it set to hide tabs. only just figured out what was going on.

search & replace dialog goes after one operation. I often go search search search to find what I'm looking for so having to pop up the dialog then move it out of the way after each operation is cumbersome.

just a little constructive critique. hope you don't mind.

[BlueHazzard]

search & replace dialog goes after one operation. I often go search search search to find what I'm looking for so having to pop up the dialog then move it out of the way after each operation is cumbersome.

isn't it normal behaviour to use first search and then F3 for future search (at least in the regedit on windows ). The open "search dialog" takes only space (like in notepad++) from the editor....

ctrl-h is search & replace in visual studio & gedit. you currently have it set to hide tabs. only just figured out what was going on.

i personally like "R" because of "Replace"... H makes no sense for me.... But you can it change easily in Settings->Editor->Keyboard Shortcuts->Search->Replace

greetings

[advance-software]

> i personally like "R" because of "Replace"... H makes no sense for me.... But you can it change easily in Settings->Editor->Keyboard Shortcuts->Search->Replace

Agree R makes more sense but got this on autopilot. "VS mode" keyboard shortcuts would be nice as an option.

Couldn't spot Settings->Editor->Keyboard Shortcuts . Must be blind. Running Jens latest build.

> isn't it normal behaviour to use first search and then F3 for future search
dunno. that'll do. cheers. an icon on the toolbar for this would be nice. again, visual studio has a text edit on the toolbar you can drop quick searches into. not saying you should replicate everything they do, but that's a nice timesaver.

greetings.

[BlueHazzard]

again, visual studio has a text edit on the toolbar you can drop quick searches into. not saying you should replicate everything they do, but that's a nice timesaver.

its called incremental search in c::b (see picture).

Couldn't spot Settings->Editor->Keyboard Shortcuts . Must be blind. Running Jens latest build.

again, see image.

greetings

[Jenna]

Couldn't spot Settings->Editor->Keyboard Shortcuts . Must be blind. Running Jens latest build.

Make sure you have the contrib-plugins package installed.
Needed for keyboard-shortcuts and IncSearch.

[oBFusCATed]

I hear you but you have pretty much all the components in place to do this, so why not. makes it a more useful product.

Won't happen if you don't provide working and tested patch or this feature happens to be useful for my daily work in the future.
Unfortunately adding every randomly proposed feature is not the best option for long term maintainability

Jens: do you still think it is a good idea to have ctrl-h bound by default? (I think we had argument about this in the past, if I'm wrong I apologise)

[Jenna]

Jens: do you still think it is a good idea to have ctrl-h bound by default? (I think we had argument about this in the past, if I'm wrong I apologise)

It's correct, we discussed this already.
To be honest, I don't care about MS (and others) defaukt shortcuts very much.
Another thing are more commonly used things like Ctrl+C, Ctrl+S, Ctrl+f etc.

I'm not against changing this in general, but I'm always against changing how things work silently, because it can break other users workflow, if we change shortcuts.

Won't happen [...] [until] this feature happens to be useful for my daily work in the future.

[advance-software]

>  setup you executable paths and then disable the option "Settings -> Debugger -> auto build project if it is not up to data"

"Settings -> Debugger -> auto build project is a global setting so I'd have to remember to switch this on/off as I switch projects. That might work but it's not a good solution.

So it's time to enter makefile hell ... yay.

The point is rather than everyone figuring their way around a quirky system, a more intuitive interface will make support easier and the product better.  If your motivation is just to add the stuff you need/use, that's fair enough I suppose. Such is free software ...

update :

>  setup you executable paths and then disable the option "Settings -> Debugger -> auto build project if it is not up to data"

so, now I'm done whining & actually doing what you've suggested it works. and it works sweet.

this is why this is frustrating. you've done the hard bit. just a little "icing on top" & that's another weird quirk transformed into another awesome feature.  


Other stuff:

Editor shortcut config & incremental search should be standard base package features not addons imo.

Not suggesting changing your default key bindings. Your choice there is more intuitive but allowing secondary binding packages (or however you want to call it) to provide shortcuts that match other popular packages would aid user migration.

Cheers guys.

[oBFusCATed]

...a more intuitive interface will make support easier and the product better.

C::B is not a product in the common sense, but free software project/tool.
Adding features makes one software harder to maintain/support.

Editor shortcut config & incremental search should be standard base package features not addons imo.

Here I agree.

Not suggesting changing your default key bindings. Your choice there is more intuitive but allowing secondary binding packages (or however you want to call it) to provide shortcuts that match other popular packages would aid user migration.

Key collisions are inevitable...

[advance-software]

> Key collisions are inevitable...

Sorry, phrased that badly. Key mapping templates. Either standard CB or standard VC or whatever, which could then be customized by users & saved as their bindings defaults. Again, sounds like you have most of this already. Just the option of being able to select VC bindings & that one's done.

But here I'll come onto your side of the fence & say these things are fluff that aren't hard to deal with once you know the system.

Of more importance is there's still a little debugging weirdness. Get the occasional lockup. No idea if it's CB or gdb. Update when I have more info,

[advance-software]

Ok, back to the using codeblocks as a debugger front end feature :

If I untick settings -> Debugger -> auto build project if not up to date as advised ...

... the properties, build targets execution working directory is ignored & the app starts from the directory that the project would have built into had I not unticked auto build (hope that makes sense)

I want to be able to step into an existing executable & specify the startup directory.

Will go back to ddd for this for now as too many obscure hoops to jump through in cb right now but a shame this isn't closed out in an intuitive manner ... would make the product a lot more useful & you're so close to having an awesome new feature.

Understand the resource issue. Sorry, overloaded too right now & no beer tokens with which to compensate you at the moment.

Working on that ... might even happen one day

[BlueHazzard]

I want to be able to step into an existing executable & specify the startup directory.

i think this should help:

Project->Properties->Build Targets->Execution working dir

"Settings -> Debugger -> auto build project is a global setting so I'd have to remember to switch this on/off as I switch projects. That might work but it's not a good solution.

I think too that this should be a project specific setting...

[oBFusCATed]

I think too that this should be a project specific setting...

Real life use-case please! I'm not sure that the current one is valid one, because if the project is empty the build will succeed or you can always click "Debug anyway" in the message box that pops up if the build fails.

Ok, back to the using codeblocks as a debugger front end feature :

If I untick settings -> Debugger -> auto build project if not up to date as advised ...

... the properties, build targets execution working directory is ignored & the app starts from the directory that the project would have built into had I not unticked auto build (hope that makes sense)

Post simple project and the steps needed to reproduce the problem.

[advance-software]

> Post simple project and the steps needed to reproduce the problem.

well, I could but it's going round the houses to fix something that I don't want anyhow.

If someone were to implement import -> project -> [binary] & allow the binary startup directory to be specified in an intuitive manner, I'd definitely file bug reports with test cases if that had issues.

hope you understand why I wrote that - lets do this right or not at all.

[oBFusCATed]

But it is implemented. You can set the path in the Project -> Properties -> Build targets -> Execution working dir

[advance-software]

guess this will have to wait till I have the time & patience to do it right.

can't have a bunch of weird quirky stuff getting in the way. stops me working efficiently.

please take that the right way - it's the offer of a little help when I get a minute.