Add GDB support

[ouuan]

Is your feature request related to a problem? Please describe.

I don't know how to use GDB with CP Editor.

Describe the solution you'd like

Support GDB with GUI, like many other IDEs.

Describe alternatives you've considered

Support GDB in command line.

Additional context

N/A

[caretaker-claire[bot]]

Hi ouuan Thanks for Opening a new Issue here. I will also thank you for strictly following the Issue Templates. I will add an appropriate tag to your Issue.

Have Patience, One of our Cool Contributors will help you soon.

[coder3101]

Breakpoints supports are required from Editor for this feature to be incorporated in Editor. You can however add sanitizers to your compile commands and get more information about Crashes directly in Message box.

Set g++ -Wall -fsanitize=memory -g to enable memory sanitizer and information about line where error occurred. You can also use address and undefined sanitizers as well.

[coder3101]

Scintialla has margins that allow us to put breakpoints. This issue will get some attention once Scintilla based editor is released.

[ouuan]

Instead of providing GUI support for GDB, we can let users set the debug command, and provide debug actions.

Users can set:

• Debug command: gdbgui ${binary}
• Debug command with input: gdbgui ${binary} < ${input}
• Compile command when debugging: g++ -g

Users can do:

• Debug without input.
• Debug on a test case.

[neko-para]

gdb provide a machine interface for program to use it. It is no hard to implement a simple ui for gdb with the support to Start, Stop, Step, StepIn, StepOut, Print, Watch, as these features are included in gdb, and what we need is a wrapper.

[ouuan]

I'd rather like the solution I mentioned above: let the user use external frontend for GDB in one click.

[ouuan]

It is no hard to implement a simple ui for gdb

what we need is a wrapper

That sounds easy, can you implement it?

[neko-para]

For some pure competitors(according to my experience), they cannot use terminals or any tools based on it. The gdbui or gdb -ui may be helpful, but i think it is a quite important feature.

[neko-para]

I used to write a editor for c++(qdevcpp) which is similar to devcpp(however, it hasn't been update for months and i don't want to continue it), but i do think about how to implement the debug funtion and have done some experience. I'll do it if i have enough time

[ouuan]

For some pure competitors(according to my experience), they cannot use terminals or any tools based on it. The gdbui or gdb -ui may be helpful, but i think it is a quite important feature.

1. What is "pure competitors"?
2. Why can't somebody use the terminal but can use GUI?

[ouuan]

Does "cannot use terminals" mean "don't know how to use terminals"?

[neko-para]

For some pure competitors(according to my experience), they cannot use terminals or any tools based on it. The gdbui or gdb -ui may be helpful, but i think it is a quite important feature.

1. What is "pure competitors"?
2. Why can't somebody use the terminal but can use GUI?

Such "pure competitors" mean who learn only algorithm and no more. They cannot deal with the unusual problems(like strange compile error) and knows nothing about compile, link. They can do well on windows with the help of devc++, but when switch to linux they are always trapped. (actually they know how to search for information after learning more, but they are quite helpless at first) They know how to use GUI, as they know the meaning of stepin, stepout and so on, but they are not well on dealing terminal program.

[neko-para]

They do know more after learning, but at first some of they know nothing about computers(not only my senior high classmates, but also university classmates).

[ouuan]

In fact, you only need to answer "Does 'cannot use terminals' mean 'don't know how to use terminals'?", I know there are people not good at terminals, but "cannot use terminal" doesn't sound like "don't know how to use"/"not familiar with".

If you can help us write a pretty GUI, that's good. But I think external tools like gdbgui is also a good choice, that will make things easier for the maintainers of CP Editor, and the user can have more choices.

[neko-para]

Yes, what i mean it that they don't know how to use it. ps. I'm not good at English, so some expressions may be strange. And I just know about this project from your passage on Zhihu about half an hour ago, so I come here and express my option.

[ouuan]

Yes, what i mean it that they don't know how to use it. ps. I'm not good at English, so some expressions may be strange. And I just know about this project from your passage on Zhihu about half an hour ago, so I come here and express my option.

You can use Chinese for the expressions which you are not sure. Possibly in brackets.

Do you mean they don't know how to use gdbgui? My plan is to make it able to launch external tools in CP Editor with a button/a shortcut. They may need to install external tools and set the command for launching external tools, but that is not hard, right?

[ouuan]

However, it will be best if you can help us write a pretty GUI with the basic functions.

[neko-para]

Actully i just know about gdbgui and it seems quite good(i have away from OI about two year and doesn't join ACM) the ui I know before is the internal ui of gdb, aka gdb -ui

[ouuan]

I also don't use gdbgui much, I usually use cerr to debug.

[neko-para]

Yes. but gdb is useful when a crash appears or debug with the data structure(use cerr to print will create a bunch of output if you want to know what happen)

[neko-para]

I've already write a library which provides an interface to control gdb easily. I'd like to popup a modeless dialog which contains the debug control buttons and infomations, but I'm not sure if my window style could be similar to the style of cpeditor.

[neko-para]

In some reasons it's not convenient for me to debug it on windows, and i have no idea if different version of gdb would provide the output in different syntax. It still needs test.

[ouuan]

In fact, "reveal the executable file in the file manager" can be a workaround for many things. Now it's not very easy to find the executable file, especially when it's in the temporary directory. If users can easily find the executable file, they can do anything they like including running gdb. However, a GUI like #340 could be better if it works as expected.

[neko-para]

Currently #340 is quite poor. As no left margin and line highlight, it's very hard to use it.

[neko-para]

It seems that we can upgrade the LineNumberArea to support marks on the left margins, but I still don't know if there's a way to set some lines' background(current I use the cursor to show where the program is)