home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 11 Util / 11-Util.zip / GDT.ZIP / READ.ME < prev   
Text File  |  1988-12-31  |  11KB  |  241 lines
  1. GDT.EXE -- An OS/2 Global Descriptor Table Debugger
  2.         (may also be used to wrap fish or clean baseboards)
  3.  
  4.                         "To tell you the honest truth, I get a little
  5.                         uneasy at the thought of device drivers by the
  6.                         masses."
  7.                             -- Noel J. Bergman
  8.                                CIS PCmagnet, 25-Oct-1988
  9.  
  10.                         "Protected mode?  What protected mode?"
  11.                             -- Ross Nelson
  12.                                BIX os.2/kernel #909
  13.  
  14.     GDT.EXE (version 0.30103) walks through the 286 protected-mode
  15. Global Descriptor Table (GDT) as used by OS/2.  It relies on a small
  16. device driver, DEVHLP.SYS, which must be installed in your
  17. CONFIG.SYS file (device=devhlp.sys).  (DEVHLP.SYS has been
  18. undergoing changes, so you should use the version of DEVHLP.SYS found
  19. in GDT.ARC, even if you already have a version of DEVHLP.SYS.)
  20.  
  21.     GDT.EXE comes with a state-of-the-art graphical windowed
  22. user-interface.  Just kidding!  (Perhaps) it _should_ come with such
  23. an interface, but actually GDT.EXE works more like EDLIN or DEBUG.
  24.  
  25.     To print out the entire GDT, just type W (and a carriage
  26. return), and the programs does a "walk" through the entire 
  27. table.  The display looks like this:
  28.  
  29.     GDT at 11FE80 <limit 05095> <636 entries>
  30.     Type H for help
  31.     $ w
  32.     [seg 0008] 11FE80 <limit 05095> <lar 93> [Writable data]
  33.     [seg 0010] 009BE4 <limit 00043> <lar 83> [Busy TSS gate]
  34.     [seg 0018] 121A88 <limit 01023> <lar 92> [Writable data]
  35.     [seg 0020] 000000 <limit 01023> <lar 93> [Writable data]
  36.     [seg 0028] 1F5A60 <limit 02047> <lar 82> [LDT]
  37.     [seg 0030] 1F5A60 <limit 02047> <lar 93> [Writable data]
  38.     [seg 0038] 1F94A0 <limit 02897> <lar 93> [Writable data]
  39.     [seg 0040] 000400 <limit 00959> <lar 93> [Writable data]
  40.     [seg 0050] 009780 <limit 32501> <lar 93> [Writable data]
  41.     [seg 0060] 009A00 <limit 00071> <lar F1> [Read-only data]
  42.     [seg 0070] 009780 <limit 32501> <lar 90> [Read-only data]
  43.     [seg 0078] 1F1980 <limit 00145> <lar 93> [Writable data]
  44.     ....
  45.  
  46.     [seg] is the segment number in hex.  Since the protection level
  47. is encoded inside the segment number, for each segment number shown
  48. here, there are another three aliases.  The segment numbers shown by
  49. GDT.EXE are for Ring 0.
  50.  
  51.     The next entry, which looks like 123456, is the 24-bit physical
  52. address of the base of this segment.  (Note that these are 24-bit
  53. physical addresses, not the 20-bit ones you're used to from DOS.)
  54. This number is in hex.
  55.  
  56.     In a 286 operating system (and OS/2 is right now very much a 286
  57. OS, even if you're running it on a 386 machine), a segment can be
  58. from 0 to 64k bytes long.  The offset into the segment of the very
  59. last byte is indicated by the next entry in GDT.EXE's display, which
  60. looks like <limit 65535>.  This number is in decimal.
  61.  
  62.     Segments can have various attributes, also known as access
  63. rights.  The next entry displays the hex code for a segment's access
  64. rights, for example <lar 93>.  Since this is available using the LAR
  65. instruction, in GDT.EXE the information itself is called the LAR,
  66. even though that isn't quite right.
  67.  
  68.     Since few people can be expected to remember that, e.g., E4 is a
  69. call gate, the next (and last) entry displayed when you do a walk is
  70. a brief textual description of the segment like "Readable code",
  71. "Writable data," "Pungent aroma."
  72.  
  73.     One type of segment is so different from the others that it's
  74. displayed quite differently, however.  This is the call gate.  (This
  75. documentation is not intended to teach the workings of the 286.  For
  76. that, turn to a good book on the 286, repeat, 286, not 386 [trying to
  77. decipher the GDT under OS/2 using documentation for the 386 is a
  78. mistake; take my word for it], such as Stephen P. Morse and Douglas
  79. J. Albert, THE 80286 ARCHITECTURE; Ed Strauss, INSIDE THE 80286, or
  80. Marcel Proust, A LA RECHERCHE DU 286.)
  81.  
  82.     For a call gate, the display looks like this:
  83.  
  84. <Call gate 0F10:0000> <code 00B0:0B4E> <phys 115AEE> DOSALLOCSHRSEG (5 wds)
  85. <Call gate 0F18:0000> <code 00B0:0B8A> <phys 115B2A> DOSGETSHRSEG (4 wds)
  86. <Call gate 0F20:0000> <code 00B0:0BC2> <phys 115B62> DOSGIVESEG (4 wds)
  87. <Call gate 0F28:0000> <code 00B0:0BF8> <phys 115B98> DOSGETSEG (1 wds)
  88.  
  89.     Rather than display the segment number as [seg 0F10], for a call
  90. gate the same information is displayed as <Call gate 0F10:0000>.  This
  91. is the address you would get back from calling DosGetProcAddr on a
  92. DOSCALLS (OS/2 kernel) function.  Actually, it's not quite what you
  93. would get back:  0F10:0000 represents a Ring 0 segment; its Ring 3
  94. equivalent is 0F13:0000.
  95.  
  96.     The next field, e.g., <code 00B0:0B4E>, shows the code that
  97. the call gate points to.  Note that segment 00B0 (in this case) is
  98. just another entry in the GDT.  (I'll jump ahead of myself and
  99. tell you that if you just wanted to find out about segment 00B0,
  100. you could type . b0 [a dot followed by a space followed by B0,
  101. followed of course by the carriage return].)  This other entry had
  102. better be code, or we're in trouble.
  103.  
  104.     The next field, e.g., <phys 115AEE>, is the 24-bit physical
  105. address for the first opcode of the code pointed to by the call gate
  106. in the house that Jack built.  (In fact, all this code seems to have
  107. as its first instruction yet another CALL, so there's even one more
  108. level of indirection.)  This physical address is derived by adding
  109. together the physical address of the base of segment 00B0 (in this
  110. case) and the offset given in the call gate itself.
  111.  
  112.     The next field, e.g., DOSGETFRAMIS, represents the name of the
  113. OS/2 function for which the call gate is the entry point.  If the
  114. name is followed by an asterisk, this indicates that this is either
  115. a new and/or undocumented function, e.g., DOSICANONICALIZE or 
  116. DOSR2STACKREALLOC.
  117.  
  118.     The final field, e.g., (4 wds), indicates that this function 
  119. expects 4 words (8 bytes) worth of arguments.  Of course, this isn't
  120. such a revelation when you're talking about DOSGETFRAMIS (which,
  121. as we all know, does in fact take 4 words:  WORD, PTR WORD, WORD),
  122. but it might be useful for someone to know that the undocumented (?)
  123. DOSQSYSINFO takes 4 words.
  124.  
  125.     The LAR for a call gate is E4, and if you just wanted to display
  126. all call gates, you could ask GDT.EXE to "search" for them:
  127.  
  128.         $ s e4
  129.  
  130.     Likewise, if you were interested in finding segments marked
  131. as read-only data, one thing to try would be:
  132.  
  133.         $ s f1
  134.         [seg 0060] 009A00 <limit 00071> <lar F1> [Read-only data]
  135.         [seg 03E0] 1FBE20 <limit 00481> <lar F1> [Read-only data]
  136.     
  137.     Now, segment 0x60 is sort of interesting: it's the global
  138. information segment maintained by OS/2 (so far most of the data
  139. structures we've been looking at are pure 286, having little or
  140. nothing to do with OS/2 per se, but this one is certainly an OS/2
  141. data structure).
  142.  
  143.     To actually look at the bytes in segment 0x60, we can once
  144. again rely on the intuitive user-friendly interface of GDT.EXE.
  145. In this case, use the ? command:
  146.  
  147. $ ? 60
  148. [seg 0060] 009A00 <limit 00071> <lar F1> [Read-only data]
  149. 009A00  55 97 AD 23 84 2A 7B 00 17 39 09 03 FF FF 36 01    U...............
  150. 009A10  13 0C C4 07 01 0A 0A 00 05 10 05 01 09 00 01 03    ................
  151. 009A20  20 00 F8 00 01 00 00 00 00 00 00 00 00 00 00 00    ................
  152. 009A30  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
  153. 009A40  00 00 00 00 00 00 10                               .......
  154.  
  155.     You can continually type ? x60 at the $ prompt (or, if you have
  156. the ALIAS command-line editor, you can just press the up-arrow key),
  157. and each time you display the GIS it will be a little different, since
  158. OS/2 updates the time kept in the GIS.
  159.  
  160.     One can use the ? command to display any segment.  However, in
  161. the case of a call gate, it won't do you much good since (a) it's
  162. code you want, and (b) in a call gate the fields are all mixed up.
  163. Therefore, GDT.EXE provides the U command (for unassemble).
  164.  
  165.     Actually, it's not GDT.EXE that provides this -- I wouldn't know
  166. where to begin to write an unassembler, so CodeView (CVP.EXE) is run
  167. as a child process.  In the case of the call gate:
  168.  
  169. <Call gate 0F10:0000> <code 00B0:0B4E> <phys 115AEE> DOSALLOCSHRSEG (5 wds)
  170.  
  171. you would issue the command:
  172.  
  173.         $ u 00b0:0b4e
  174.  
  175. because you want to disassemble the code at 00B0:0B4E (remember, it's
  176. "just" a call gate at 0F10:0000).  GDT.EXE will bring up CodeView
  177. (which takes quite a while!), and all sorts of trash will be spewed
  178. out to your screen, including a line like 
  179.  
  180.         garbage     RET                            ; BR0
  181.  
  182. Ignore that!  It's just control returning to the debugger, at which
  183. point it picks up our instruction to unassemble.  With most of
  184. these DOSxxxx call gates, what you'll probably see as the first
  185. instruction is a line like
  186.  
  187.         garbage garbage garbage     CALL 74A0
  188.  
  189. At the CodeView prompt, you can now type
  190.  
  191.         > u 74a0
  192.  
  193. and so on.  Just q (quit) when you're done.  You'll be returned to
  194. the GDT.EXE $ prompt.
  195.  
  196.     When you tire of GDT.EXE, type q to quit back to OS/2.
  197.  
  198.     Other GDT.EXE commands include:
  199.  
  200.         ! <string> -- run another OS/2 program
  201.             $ ! cd \os2\forth && start forth
  202.             $ ! cd \os2\xlisp && start os2xlisp
  203.             $ ! dir
  204.  
  205.         H -- displays an out-of-date help message
  206.  
  207.         P -- displays bytes at an arbitrary physical address
  208.             $ p b 8000 40
  209.             $ p f e008 100
  210.  
  211.         R -- change radix (radix always entered in decimal)
  212.             $ r 10
  213.             $ r 16
  214.  
  215. Not-so-blue-sky:  Since in GDT.EXE we can manipulate call gates as data,
  216. we can probably also make them point to our own code, just an interrupt
  217. handler under MS-DOS.  This would be useful for writing front-ends to,
  218. or replacements for, various DOSxxxx calls.  Presumably one would name
  219. this facility DosSetProcAddr, since we already have DosGetProcAddr.
  220. Or, since there is VioRegister and KbdRegister, perhaps the facilities
  221. provided in DEVHLP.SYS could be used to build a DosRegister (not to
  222. be confused with a bridal registry, by the way).  I can think of one
  223. DOSxxx function that could use a better front-end, for example:
  224. DosGetProcAddr doesn't accept ASCIIZ names for DOSCALLS; couldn't
  225. we just write a preprocessor for it, point the call gate at our
  226. code (presumably fiddling around with protection levels), have our
  227. code call ("chain_intr," as it were) to the code that the call gate
  228. originally pointed to?  This would also be handy for writing home-brew
  229. profilers.
  230.  
  231. -- Andrew Schulman
  232.    32 Andrew (!) Street
  233.    Cambridge MA 02139
  234.    617-876-2102
  235.  
  236.    18 December 1988     // twas the week before Xmas...
  237.    31 December 1988        // revised: the great new year's eve debug session
  238.  
  239.  
  240.  
  241.