Using adb to look at tiny s variables


Using adb to look at tiny's variables

Now that we have some understanding about included header files and have used nm for a listing of the symbol table, we can use adb to look at the variables.

It is important to note that adb is not normally the first debugger you would reach for when debugging a user program. Tools such as dbx, dbxtool , and debugger are far more suitable. All three are easier to use and are much closer to the programming language we used to write our program, whereas adb is closer to the hardware's native language, in this case, SPARC assembly language. However, for the purpose of your education in working with the kernel, we will use adb now.

When adb 'ing a program to be executed, adb starts off in an idle mode of sorts, waiting to see if we want to set up breakpoints before execution commences. Once our program is executing, we can watch our variables change as each SPARC assembly instruction is executed step by step.

Watch this Solaris 2 adb session on our tiny program and see if you can follow what is happening.

Figure 11-3 Running tiny under the control of adb
 Hiya...  adb tiny -   main:bx   :r  breakpoint      main:           sethi   %hi(0xfffffc00), %g1  main?20i  main:  main:           sethi   %hi(0xfffffc00), %g1                  add     %g1, 0x3b8, %g1          ! -0x48                  save    %sp, %g1, %sp                  mov     0x6, %o0                  st      %o0, [%fp - 0x4]                  sethi   %hi(0x20400), %o1                  ld      [%o1 + 0x394], %o1       ! beach_factor                  sethi   %hi(0x20400), %o2                  st      %o1, [%o2 + 0x3a0]                  ld      [%fp - 0x4], %o3                  sethi   %hi(0x20400), %o4                  st      %o3, [%o4 + 0x3a4]                  sethi   %hi(0x20400), %o5                  ld      [%o5 + 0x398], %o5       ! whistles                  sethi   %hi(0x20400), %o7                  st      %o5, [%o7 + 0x3a8]                  ret                  restore  _init:          save    %sp, -0x60, %sp                  ret  dreamcar/fDD  dreamcar:  dreamcar:   +0.0000000e+00  0               0  beach_factor/f  beach_factor:  beach_factor:       +1.2350000e+02  whistles/D  whistles:  whistles:        10  tickets/D  symbol not found  :s  stopped at      main+4:         add     %g1, 0x3b8, %g1  :s  stopped at      main+8:         save    %sp, %g1, %sp  :s  stopped at      main+0xc:       mov     0x6, %o0  :s  stopped at      main+0x10:      st      %o0, [%fp - 0x4]  :s  stopped at      main+0x14:      sethi   %hi(0x20400), %o1  :s  stopped at      main+0x18:      ld      [%o1 + 0x394], %o1 ! beach_factor  :s  stopped at      main+0x1c:      sethi   %hi(0x20400), %o2  :s  stopped at      main+0x20:      st      %o1, [%o2 + 0x3a0]  :s  stopped at      main+0x24:      ld      [%fp - 0x4], %o3  dreamcar/fDD  dreamcar:  dreamcar:   +1.2350000e+02  0               0  :s  stopped at      main+0x28:      sethi   %hi(0x20400), %o4  :s  stopped at      main+0x2c:      st      %o3, [%o4 + 0x3a4]  :s  stopped at      main+0x30:      sethi   %hi(0x20400), %o5  dreamcar/fDD  dreamcar:  dreamcar:   +1.2350000e+02  6               0  :s  stopped at      main+0x34:      ld      [%o5 + 0x398], %o5 ! whistles  :s  stopped at      main+0x38:      sethi   %hi(0x20400), %o7  :s  stopped at      main+0x3c:      st      %o5, [%o7 + 0x3a8]  :s  stopped at      main+0x40:      ret  dreamcar/fDD  dreamcar:  dreamcar:   +1.2350000e+02  6               10  $q  Hiya... 

Let's now discuss in more detail what happened during this adb session.

Unlike what we will do with the postmortem files, we start adb specifying only the executable object file that contains a symbol table. The dash says that we don't want to examine a core file. If we were to analyze a core dump of tiny, then we would specify the core file in addition to the object file.

Note again that adb doesn't give us a prompt.

We start the session by setting a breakpoint at the beginning of main() and then begin execution of tiny by giving adb the :r command to run. Immediately, we stop at main(), where our breakpoint was set. Listing the first 20 instructions from the object file, we can see that the return instruction, ret , is down near the end. main() is a short routine, even in assembly code.

Before we go any farther, we check the contents of our variables in the core file, which in this case is simply memory. Since dreamcar consists of a floating-point word followed by two integers, we can specify /fDD to display it. The f says to display one single-precision (32-bit), floating-point word. The DD says to show two full-word (32-bit) integers in decimal.

While still at this breakpoint, we have adb display the current contents of beach_factor as a floating-point word, whistles as a full-word decimal value as well as the variable tickets . Since tickets is not in the symbol table, adb reports that it cannot be found.

Both beach_factor and whistles were assigned initial values when they were defined in our program. We can confirm this by using adb. Tiny hasn't started executing yet, but we see values assigned to both of these variables. Conversely, dreamcar has been allocated storage space in memory, but the memory still contains zeroes.

Let's execute some instructions. The :s command tells adb to step, executing only one assembly instruction at a time. As we step through the program, we can see where variables are being set via the store instruction, st . The first store instruction we encounter sets the variable tickets to 6. Tickets is a local symbol that is stored in the stack frame. There is no symbol name for it.

Stepping further, we check the value of dreamcar again after the next store. We can see that the first element of dreamcar has now been set. Continuing, we watch as dreamcar's elements are assigned values. Soon we are done, so we exit adb.



PANIC. UNIX System Crash Dump Analysis Handbook
PANIC! UNIX System Crash Dump Analysis Handbook (Bk/CD-ROM)
ISBN: 0131493868
EAN: 2147483647
Year: 1994
Pages: 289
Authors: Chris Drake

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net