Advertisement
CSenshi

Pintos - Project 2 (GDB Questions)

May 26th, 2019
383
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 7.11 KB | None | 0 0
  1. GDB Questions
  2. ==============================
  3.  
  4. ```bash
  5. # run with gdb
  6. pintos --gdb --filesys-size=2 -p build/tests/userprog/args-none -a args-none -- -q -f run args-none
  7. ```
  8.  
  9.  
  10. The questions you should answer in your design doc are the following.
  11.  
  12. 1. Set a break point at process_execute and continue to that point.
  13.  
  14. * What is the name and address of the thread running this function?
  15. ```json
  16. (struct thread *) 0xc000e000 = {
  17. tid = 1,
  18. status = THREAD_RUNNING,
  19. name = "main", '\000' <repeats 11 times>,
  20. stack = 0xc000ee0c "\210", <incomplete sequence \357>,
  21. priority = 31,
  22. allelem = {
  23. prev = 0xc0034f68 <all_list>,
  24. next = 0xc0104020
  25. },
  26. fd_list = {
  27. head = {
  28. prev = 0x0,
  29. next = 0xc000e030
  30. },
  31. tail = {
  32. prev = 0xc000e028,
  33. next = 0x0
  34. }
  35. },
  36. elem = {
  37. prev = 0xc0034f78 <ready_list>,
  38. next = 0xc0034f80 <ready_list+8>
  39. },
  40. pagedir = 0x0,
  41. magic = 3446325067
  42. }
  43. ```
  44. * What other threads are present in pintos at this time?
  45. ```json
  46. (struct thread *) 0xc0104000 = {
  47. tid = 2,
  48. status = THREAD_BLOCKED,
  49. name = "idle", '\000' <repeats 11 times>,
  50. stack = 0xc0104f34 "",
  51. priority = 0,
  52. allelem = {
  53. prev = 0xc000e020,
  54. next = 0xc0034f70 <all_list+8>
  55. },
  56. fd_list = {
  57. head = {
  58. prev = 0x0,
  59. next = 0xc0104030
  60. },
  61. tail = {
  62. prev = 0xc0104028,
  63. next = 0x0
  64. }
  65. },
  66. elem = {
  67. prev = 0xc0034f78 <ready_list>,
  68. next = 0xc0034f80 <ready_list+8>
  69. },
  70. pagedir = 0x0,
  71. magic = 3446325067
  72. }
  73. ```
  74.  
  75. 2. What is the backtrace for the current thread?
  76. ```
  77. #0 process_execute (file_name=file_name@entry=0xc0007d50 "args-none") at ../../userprog/process.c:39
  78. #1 0xc002025e in run_task (argv=0xc0034e0c <argv+12>) at ../../threads/init.c:288
  79. #2 0xc00208e4 in run_actions (argv=0xc0034e0c <argv+12>) at ../../threads/init.c:340
  80. #3 main () at ../../threads/init.c:133
  81. ```
  82.  
  83. 3. Set a breakpoint at start_process and continue to that point.
  84. * What is the name and address of the thread running this function?
  85. ```json
  86. (struct thread *) 0xc010b000 = {
  87. tid = 3,
  88. status = THREAD_RUNNING,
  89. name = "args-none\000\000\000\000\000\000",
  90. stack = 0xc010bfd4 "",
  91. priority = 31,
  92. allelem = {
  93. prev = 0xc0104020,
  94. next = 0xc0034f70 <all_list+8>
  95. },
  96. fd_list = {
  97. head = {
  98. prev = 0x0,
  99. next = 0xc010b030
  100. },
  101. tail = {
  102. prev = 0xc010b028,
  103. next = 0x0
  104. }
  105. },
  106. elem = {
  107. prev = 0xc0034f78 <ready_list>,
  108. next = 0xc0034f80 <ready_list+8>
  109. },
  110. pagedir = 0x0,
  111. magic = 3446325067
  112. }
  113. ```
  114. * What other threads are present in pintos at this time?
  115. ```json
  116. #1 (struct thread *) 0xc0104000 = {
  117. tid = 2,
  118. status = THREAD_BLOCKED,
  119. name = "idle", '\000' <repeats 11 times>,
  120. stack = 0xc0104f34 "",
  121. priority = 0,
  122. allelem = {
  123. prev = 0xc000e020,
  124. next = 0xc010b020
  125. },
  126. fd_list = {
  127. head = {
  128. prev = 0x0,
  129. next = 0xc0104030
  130. },
  131. tail = {
  132. prev = 0xc0104028,
  133. next = 0x0
  134. }
  135. },
  136. elem = {
  137. prev = 0xc0034f78 <ready_list>,
  138. next = 0xc0034f80 <ready_list+8>
  139. },
  140. pagedir = 0x0,
  141. magic = 3446325067
  142. }
  143.  
  144. #2 (struct thread *) 0xc010b000 = {
  145. tid = 3,
  146. status = THREAD_RUNNING,
  147. name = "args-none\000\000\000\000\000\000",
  148. stack = 0xc010bfd4 "",
  149. priority = 31,
  150. allelem = {
  151. prev = 0xc0104020,
  152. next = 0xc0034f70 <all_list+8>
  153. },
  154. fd_list = {
  155. head = {
  156. prev = 0x0,
  157. next = 0xc010b030
  158. },
  159. tail = {
  160. prev = 0xc010b028,
  161. next = 0x0
  162. }
  163. },
  164. elem = {
  165. prev = 0xc0034f78 <ready_list>,
  166. next = 0xc0034f80 <ready_list+8>
  167. },
  168. pagedir = 0x0,
  169. magic = 3446325067
  170. }
  171. ```
  172.  
  173.  
  174. 4. Where is the thread running start_process created?
  175. ```c
  176. /* Create a new thread to execute FILE_NAME. */
  177. tid = thread_create(file_exe, PRI_DEFAULT, start_process, fn_copy);
  178. ```
  179.  
  180. 5. Continue one more time. The userprogram should cause a page fault and thus cause the page fault
  181. handler to be executed. It’ll look something like
  182. ```
  183. [Thread <main>] #1 stopped.
  184. pintos-debug: a page fault exception occurred in user mode
  185. pintos-debug: hit ’c’ to continue, or ’s’ to step to intr_handler
  186. 0xc0021ab7 in intr0e_stub ()
  187. ```
  188. Please find out what line of our user program caused the page fault. Don’t worry if it’s just an hex address. (Hint: btpagefault may be useful)
  189.  
  190. ```c
  191. (gdb) btpagefault
  192. #0 0x0804870c in ?? ()
  193.  
  194. process_execute
  195. |
  196. |
  197. v
  198. start_process
  199. |
  200. v
  201. asm volatile("movl %0, %%esp; jmp intr_exit"
  202. :
  203. : "g"(&if_)
  204. : "memory");
  205. ```
  206.  
  207. 6. The reason why btpagefault returns an hex address is because pintos-gdb build/kernel.o
  208. only loads in the symbols from the kernel. The instruction that caused the page fault is in our
  209. userprogram so we have to load these symbols into gdb. To do this use
  210. loadusersymbols build/tests/userprog/args-none
  211. . Now do btpagefault again and copy down the results.
  212.  
  213. ```
  214. _start (argc=<error reading variable: can't compute CFA for this frame>, argv=<error reading variable: can't compute CFA for this frame>) at ../../lib/user/entry.c:9
  215. ```
  216.  
  217. 7. Why did our user program page fault on this line?
  218. ```
  219. reason is this part of code "main (argc, argv)". Here code tries to access argc and argv. both of them are in the part of the stack, but we haven't pushed down stack pointer down yet. Not reducing esp (stack pointer) we will always access address that is not in our virtual adress space.
  220. ```
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement