Finish 'How to debug MIPT-MIPS using GDB' manual

[pavelkryukov]

GNU Debugger (GDB) is a popular tool used for runtime debugging of software. However, MIPT courses are not focused on debugging much. The idea is to have a simple "flight rules" page covering the basic topics:

1. How to build a program to be used by GDB?
2. What is a breakpoint? How to set up a breakpoint?
3. Watchpoints: how to track what writes to a variable?
4. How to catch exceptions?
5. What useful information do backtraces contain?

Feel free to add anything you consider useful.

[UserVanya]

Hello, can i begin with this issue?

[pavelkryukov]

Yes!

[UserVanya]

well, how i can choose this issue in order to prevent assigning of other users to this problem?

[UserVanya]

or this assigners list is only for information?

[pavelkryukov]

Please check e-mail with my answer.
In brief: everyone sees that you are doing GDB wiki now, and no one else has to do it now.

[pavelkryukov]

I created a page for your future manual: https://github.com/MIPT-ILab/mipt-mips/wiki/GDB

[pavelkryukov]

Ivan, you are editing footer instead of the actual page.
I moved your data to the page https://github.com/MIPT-ILab/mipt-mips/wiki/GDB.
Please use 'edit' button in the top right corner.

[pavelkryukov]

GitHub has a cheat sheet for Markdown: https://guides.github.com/features/mastering-markdown/
Use it to make your manual looking great!

[pavelkryukov]

But if you are using Windows, you will need to install it. Use the guide below.

It's better to refer to the source page instead of copy-pasting the contents.
The installation instruction may be changed in future. Also, there are a lot of systems; for instance, I use WSL and I have no need to install MinGW, some guys are working on Macs.

(Use command "ls -al" to view your directory list. Use "cd 'path'" to change directory)

Let's assume one can use Bash commands. (Otherwise it may end up to something like "type 'l', then type 's', then hit a big key in the bottom of keyboard...).

Open directory with your program file.

Is that step actually required?
Also, what do you mean by 'program file'?

Now you must compile your file with GDB

Well. that's not the truth. -g option adds 'debugging information' to the executable.
Also, it is worth to note how to switch off optimization.

How to build a program to be used by GDB?

For sure, you have to explain how to build a MIPT-MIPS with GDB.

[UserVanya]

It's better to refer to the source page instead of copy-pasting the contents.
The installation instruction may be changed in future. Also, there are a lot of systems; for instance, I use WSL and I have no need to install MinGW, some guys are working on Macs.

It`s okay. But i get this from you. You have explained instructions of installing on two different operating systems here.

Is that step actually required?
Also, what do you mean by 'program file'?

.c or .cpp file... Well. I realized that it is better to read more about debugging

[pavelkryukov]

You have explained instructions of installing on two different operating systems here.

Thanks, I reduced the paragraph a little.

[UserVanya]

Well, yes , putting the reference is better, but this means that the whole text in wiki should consist of references only, can you explain main rules to write wiki page?

[pavelkryukov]

1. It should contain a 'story': starting with motivation, each paragraph should follow the narration of next paragraph, from simpler topics to more complicated. Current version looks good from this perspective.
2. It should behave as a cheat sheet. Reader should find information about the most common operations very quickly.
3. In opposite, rarely needed information (like installation) or advanced topics may be referenced.

To my mind, the best guide we have is Smart Pointer Overview. When our project was hosted on GoogleCode, that page hit about 500 visitors per week. Since then, C++11 was released and many more manuals were published...

[UserVanya]

Sorry for many questions

Let's assume one can use Bash commands. (Otherwise it may end up to something like "type 'l', then type 's', then hit a big key in the bottom of keyboard...).

Can you describe the situation when somebody who works on Linux and doesn't have an access to bash commands.

[pavelkryukov]

Can you describe the situation when somebody who works on Linux and doesn't have an access to bash commands.

My point was that everyone should be able to use Bash or any other shell environment.

[UserVanya]

And on your assumption ... How much time one issue should take?

[pavelkryukov]

Under the following circumstances:

1. You have installed all the environment (how to build, how to test, how to run unit tests, how to commit, how to debug)
2. You understand the theory (if something is related to branch prediction, you at least attended the lecture or read Hennessy/Patterson)
3. You understand the task (what the target is)

my assumption is 1 hour of pure coding process per each point of the task. It's pessimistic, assuming low experience of students.

I would say that the majority of time is spent on points 2 and 3, as well as code review feedbacks.

[UserVanya]

Completed. Waiting for your comments.

[pavelkryukov]

1. The text is hardly readable, it requires some markdown. For example, I changed 'main commands' a little bit.
2. Hierarchy. For instance, your headers should have different weights:

## Main Commands
### Breakpoints
#### How to set up breakpoint
#### Conditional breakpoints
#### Intervals
### Watchpoints

3. Same goes for lists:

* `catch 'exceptions'` sets a breakpoint when the program responds actively to an exception. The exception can be one of following:
  * throw _blah-blah-blah_
  * catch _blah-blah-blah_
* `info`  _blah-blah-blah_

4. What useful information do backtraces contain? needs an example.
5. Currently, there are some limitations in the use of "catch". Be attentive - ok, and how big the limitation are? Can I use catch at all or it woks perfectly for 99% of case? Please refer to the limitation list and try to explain the size of the problem.
6. How to catch exceptions? does not explain how to catch C++ exceptions. For instance, I want to catch std::bad_alloc. What should I do?
7. watch 'expr' - set up a Watchpoint for expression expr. - if you tried ever to make watchpoint, you know that passing experessions like my_object.my_field does not work.

[UserVanya]

Ok. Fixed. Waiting for comments

[pavelkryukov]

General comment: it is great as a cheat sheet, but I think we need a flow example for each section in following manner:

1. Problem: description of what we are going to solve (segfault, unhandled exception etc.)
2. Objective: what we are going to do, in general (we are going to set up a breakpoint and see what are the values of variables)
3. Implementation: what GDB commands we type to achieve our goal.

My examples would be following — feel free to enhance or discuss.

1. Breakpoint: consider we have a following function:

   void foo(void * ptr) {
      // ...
   }

Objective: get into the function if pointer is zero and understand what happens

2. Watchpoint: there is a variable, and something writes a zero into it. We need to find what writes zero.
3. Exceptions: quite easy, an exception is thrown somewhere, we need to locate
4. Backtrace: we have a segmentation fault, and we have to understand where it occured

For sure, you have to explain how to build a MIPT-MIPS with GDB.

I still do not see that point.

It was made with the command ‘bt 3’, so it shows the innermost three frames.

Could you please get an example from our simulator?
Also, there is a useful command to jump into a stack frame, please add it.

// You can use info break to list all situations handled by the program.

The '//' is hardly readable. Please, use emphasis or bold to denote importance of expressions.

[UserVanya]

I apologize for not alerting about missing the lecture yesterday. I confused days. чт, 11 окт. 2018 г. в 12:08, Pavel I. Kryukov <notifications@github.com>:

…

General comment: it is great as a cheat sheet, but I think we need a flow example for each section in following manner: 1. Problem: description of what we are going to solve (segfault, unhandled exception etc.) 2. Objective: what we are going to do, in general (*we are going to set up a breakpoint and see what are the values of variables*) 3. Implementation: what GDB commands we type to achieve our goal. My examples would be following — feel free to enhance or discuss. 1. Breakpoint: consider we have a following function: void foo(void * ptr) { // ... } Objective: get into the function if pointer is zero and understand what happens 1. Watchpoint: there is a variable, and something writes a zero into it. We need to find what writes zero. 2. Exceptions: quite easy, an exception is thrown somewhere, we need to locate 3. Backtrace: we have a segmentation fault, and we have to understand where it occured For sure, you have to explain how to build a MIPT-MIPS with GDB. I still do not see that point. It was made with the command ‘bt 3’, so it shows the innermost three frames. Could you please get an example from our simulator? Also, there is a useful command to jump into a stack frame, please add it. // You can use info break to list all situations handled by the program. The '//' is hardly readable. Please, use *emphasis* or *bold* to denote importance of expressions. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#525 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Apb4xzkXgtNJQm9DbB4j3lE-Z5MVRYeAks5ujwp7gaJpZM4VlHjF> .

[UserVanya]

hm, can i continue ?

[UserVanya]

sorry for not alerting about my absence within 2 weeks, i watched all lessons on youtube...

[pavelkryukov]

Yes, sure.

[UserVanya]

Well, and then i will get 1 or 3 points from this issue?

[UserVanya]

And sorry for question... i have notified that at the last lecture you sad that this term is last for us? Is it true?

[pavelkryukov]

I added two points to the table that week. One more will be added once you complete the manual and broadcast the link to our e-mail group.

This term is the last for "software development" track. 2nd term will contain only lectures on computer architecture, once a week each.

[UserVanya]

I will be absent today too. Some problems...I will watch all videos on YouTube... вс, 25 нояб. 2018 г., 3:19 Pavel I. Kryukov notifications@github.com:

…

I added two points to the table that week. One more will be added once you complete the manual and broadcast the link to our e-mail group. This term is the last for "software development" track. 2nd term will contain only lectures on computer architecture, once a week each. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#525 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Apb4x9pZmAVUtER8VZUtN0xt_bvIQHI6ks5uyeH9gaJpZM4VlHjF> .

[otakubeam]

That page desperately needs info about gdbtui.

[pavelkryukov]

Since MIPT-V is a TDD project, we discourage using debugger at all.