Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | |
2 | Debugging on Linux for s/390 & z/Architecture | |
3 | by | |
4 | Denis Joseph Barrow (djbarrow@de.ibm.com,barrow_dj@yahoo.com) | |
5 | Copyright (C) 2000-2001 IBM Deutschland Entwicklung GmbH, IBM Corporation | |
6 | Best viewed with fixed width fonts | |
7 | ||
8 | Overview of Document: | |
9 | ===================== | |
2254f5a7 | 10 | This document is intended to give a good overview of how to debug |
fff9289b ML |
11 | Linux for s/390 & z/Architecture. It isn't intended as a complete reference & not a |
12 | tutorial on the fundamentals of C & assembly. It doesn't go into | |
1da177e4 LT |
13 | 390 IO in any detail. It is intended to complement the documents in the |
14 | reference section below & any other worthwhile references you get. | |
15 | ||
16 | It is intended like the Enterprise Systems Architecture/390 Reference Summary | |
17 | to be printed out & used as a quick cheat sheet self help style reference when | |
18 | problems occur. | |
19 | ||
20 | Contents | |
21 | ======== | |
22 | Register Set | |
23 | Address Spaces on Intel Linux | |
24 | Address Spaces on Linux for s/390 & z/Architecture | |
25 | The Linux for s/390 & z/Architecture Kernel Task Structure | |
26 | Register Usage & Stackframes on Linux for s/390 & z/Architecture | |
27 | A sample program with comments | |
28 | Compiling programs for debugging on Linux for s/390 & z/Architecture | |
1da177e4 LT |
29 | Debugging under VM |
30 | s/390 & z/Architecture IO Overview | |
31 | Debugging IO on s/390 & z/Architecture under VM | |
32 | GDB on s/390 & z/Architecture | |
33 | Stack chaining in gdb by hand | |
34 | Examining core dumps | |
35 | ldd | |
36 | Debugging modules | |
37 | The proc file system | |
38 | Starting points for debugging scripting languages etc. | |
1da177e4 LT |
39 | SysRq |
40 | References | |
41 | Special Thanks | |
42 | ||
43 | Register Set | |
44 | ============ | |
45 | The current architectures have the following registers. | |
46 | ||
47 | 16 General propose registers, 32 bit on s/390 64 bit on z/Architecture, r0-r15 or gpr0-gpr15 used for arithmetic & addressing. | |
48 | ||
49 | 16 Control registers, 32 bit on s/390 64 bit on z/Architecture, ( cr0-cr15 kernel usage only ) used for memory management, | |
50 | interrupt control,debugging control etc. | |
51 | ||
52 | 16 Access registers ( ar0-ar15 ) 32 bit on s/390 & z/Architecture | |
53 | not used by normal programs but potentially could | |
54 | be used as temporary storage. Their main purpose is their 1 to 1 | |
55 | association with general purpose registers and are used in | |
56 | the kernel for copying data between kernel & user address spaces. | |
57 | Access register 0 ( & access register 1 on z/Architecture ( needs 64 bit | |
58 | pointer ) ) is currently used by the pthread library as a pointer to | |
59 | the current running threads private area. | |
60 | ||
61 | 16 64 bit floating point registers (fp0-fp15 ) IEEE & HFP floating | |
62 | point format compliant on G5 upwards & a Floating point control reg (FPC) | |
63 | 4 64 bit registers (fp0,fp2,fp4 & fp6) HFP only on older machines. | |
64 | Note: | |
65 | Linux (currently) always uses IEEE & emulates G5 IEEE format on older machines, | |
66 | ( provided the kernel is configured for this ). | |
67 | ||
68 | ||
69 | The PSW is the most important register on the machine it | |
70 | is 64 bit on s/390 & 128 bit on z/Architecture & serves the roles of | |
71 | a program counter (pc), condition code register,memory space designator. | |
72 | In IBM standard notation I am counting bit 0 as the MSB. | |
73 | It has several advantages over a normal program counter | |
74 | in that you can change address translation & program counter | |
75 | in a single instruction. To change address translation, | |
76 | e.g. switching address translation off requires that you | |
77 | have a logical=physical mapping for the address you are | |
78 | currently running at. | |
79 | ||
80 | Bit Value | |
81 | s/390 z/Architecture | |
82 | 0 0 Reserved ( must be 0 ) otherwise specification exception occurs. | |
83 | ||
84 | 1 1 Program Event Recording 1 PER enabled, | |
a2ffd275 | 85 | PER is used to facilitate debugging e.g. single stepping. |
1da177e4 LT |
86 | |
87 | 2-4 2-4 Reserved ( must be 0 ). | |
88 | ||
89 | 5 5 Dynamic address translation 1=DAT on. | |
90 | ||
91 | 6 6 Input/Output interrupt Mask | |
92 | ||
93 | 7 7 External interrupt Mask used primarily for interprocessor signalling & | |
94 | clock interrupts. | |
95 | ||
96 | 8-11 8-11 PSW Key used for complex memory protection mechanism not used under linux | |
97 | ||
98 | 12 12 1 on s/390 0 on z/Architecture | |
99 | ||
100 | 13 13 Machine Check Mask 1=enable machine check interrupts | |
101 | ||
102 | 14 14 Wait State set this to 1 to stop the processor except for interrupts & give | |
103 | time to other LPARS used in CPU idle in the kernel to increase overall | |
104 | usage of processor resources. | |
105 | ||
106 | 15 15 Problem state ( if set to 1 certain instructions are disabled ) | |
107 | all linux user programs run with this bit 1 | |
108 | ( useful info for debugging under VM ). | |
109 | ||
110 | 16-17 16-17 Address Space Control | |
111 | ||
b1955623 TH |
112 | 00 Primary Space Mode: |
113 | The register CR1 contains the primary address-space control ele- | |
114 | ment (PASCE), which points to the primary space region/segment | |
115 | table origin. | |
116 | ||
117 | 01 Access register mode | |
118 | ||
119 | 10 Secondary Space Mode: | |
120 | The register CR7 contains the secondary address-space control | |
121 | element (SASCE), which points to the secondary space region or | |
122 | segment table origin. | |
123 | ||
124 | 11 Home Space Mode: | |
125 | The register CR13 contains the home space address-space control | |
126 | element (HASCE), which points to the home space region/segment | |
127 | table origin. | |
128 | ||
129 | See "Address Spaces on Linux for s/390 & z/Architecture" below | |
130 | for more information about address space usage in Linux. | |
1da177e4 LT |
131 | |
132 | 18-19 18-19 Condition codes (CC) | |
133 | ||
134 | 20 20 Fixed point overflow mask if 1=FPU exceptions for this event | |
135 | occur ( normally 0 ) | |
136 | ||
137 | 21 21 Decimal overflow mask if 1=FPU exceptions for this event occur | |
138 | ( normally 0 ) | |
139 | ||
140 | 22 22 Exponent underflow mask if 1=FPU exceptions for this event occur | |
141 | ( normally 0 ) | |
142 | ||
143 | 23 23 Significance Mask if 1=FPU exceptions for this event occur | |
144 | ( normally 0 ) | |
145 | ||
146 | 24-31 24-30 Reserved Must be 0. | |
147 | ||
148 | 31 Extended Addressing Mode | |
149 | 32 Basic Addressing Mode | |
150 | Used to set addressing mode | |
151 | PSW 31 PSW 32 | |
152 | 0 0 24 bit | |
153 | 0 1 31 bit | |
154 | 1 1 64 bit | |
155 | ||
156 | 32 1=31 bit addressing mode 0=24 bit addressing mode (for backward | |
6c28f2c0 | 157 | compatibility), linux always runs with this bit set to 1 |
1da177e4 LT |
158 | |
159 | 33-64 Instruction address. | |
160 | 33-63 Reserved must be 0 | |
161 | 64-127 Address | |
162 | In 24 bits mode bits 64-103=0 bits 104-127 Address | |
163 | In 31 bits mode bits 64-96=0 bits 97-127 Address | |
164 | Note: unlike 31 bit mode on s/390 bit 96 must be zero | |
165 | when loading the address with LPSWE otherwise a | |
166 | specification exception occurs, LPSW is fully backward | |
167 | compatible. | |
168 | ||
169 | ||
170 | Prefix Page(s) | |
171 | -------------- | |
172 | This per cpu memory area is too intimately tied to the processor not to mention. | |
173 | It exists between the real addresses 0-4096 on s/390 & 0-8192 z/Architecture & is exchanged | |
174 | with a 1 page on s/390 or 2 pages on z/Architecture in absolute storage by the set | |
175 | prefix instruction in linux'es startup. | |
176 | This page is mapped to a different prefix for each processor in an SMP configuration | |
177 | ( assuming the os designer is sane of course :-) ). | |
178 | Bytes 0-512 ( 200 hex ) on s/390 & 0-512,4096-4544,4604-5119 currently on z/Architecture | |
179 | are used by the processor itself for holding such information as exception indications & | |
180 | entry points for exceptions. | |
181 | Bytes after 0xc00 hex are used by linux for per processor globals on s/390 & z/Architecture | |
3f6dee9b | 182 | ( there is a gap on z/Architecture too currently between 0xc00 & 1000 which linux uses ). |
1da177e4 LT |
183 | The closest thing to this on traditional architectures is the interrupt |
184 | vector table. This is a good thing & does simplify some of the kernel coding | |
185 | however it means that we now cannot catch stray NULL pointers in the | |
186 | kernel without hard coded checks. | |
187 | ||
188 | ||
189 | ||
190 | Address Spaces on Intel Linux | |
191 | ============================= | |
192 | ||
193 | The traditional Intel Linux is approximately mapped as follows forgive | |
194 | the ascii art. | |
195 | 0xFFFFFFFF 4GB Himem ***************** | |
196 | * * | |
197 | * Kernel Space * | |
198 | * * | |
199 | ***************** **************** | |
200 | User Space Himem (typically 0xC0000000 3GB )* User Stack * * * | |
201 | ***************** * * | |
202 | * Shared Libs * * Next Process * | |
203 | ***************** * to * | |
204 | * * <== * Run * <== | |
205 | * User Program * * * | |
206 | * Data BSS * * * | |
207 | * Text * * * | |
208 | * Sections * * * | |
209 | 0x00000000 ***************** **************** | |
210 | ||
211 | Now it is easy to see that on Intel it is quite easy to recognise a kernel address | |
212 | as being one greater than user space himem ( in this case 0xC0000000). | |
213 | & addresses of less than this are the ones in the current running program on this | |
214 | processor ( if an smp box ). | |
215 | If using the virtual machine ( VM ) as a debugger it is quite difficult to | |
216 | know which user process is running as the address space you are looking at | |
217 | could be from any process in the run queue. | |
218 | ||
219 | The limitation of Intels addressing technique is that the linux | |
220 | kernel uses a very simple real address to virtual addressing technique | |
221 | of Real Address=Virtual Address-User Space Himem. | |
222 | This means that on Intel the kernel linux can typically only address | |
223 | Himem=0xFFFFFFFF-0xC0000000=1GB & this is all the RAM these machines | |
224 | can typically use. | |
225 | They can lower User Himem to 2GB or lower & thus be | |
226 | able to use 2GB of RAM however this shrinks the maximum size | |
227 | of User Space from 3GB to 2GB they have a no win limit of 4GB unless | |
228 | they go to 64 Bit. | |
229 | ||
230 | ||
231 | On 390 our limitations & strengths make us slightly different. | |
232 | For backward compatibility we are only allowed use 31 bits (2GB) | |
6c28f2c0 | 233 | of our 32 bit addresses, however, we use entirely separate address |
1da177e4 LT |
234 | spaces for the user & kernel. |
235 | ||
236 | This means we can support 2GB of non Extended RAM on s/390, & more | |
237 | with the Extended memory management swap device & | |
238 | currently 4TB of physical memory currently on z/Architecture. | |
239 | ||
240 | ||
241 | Address Spaces on Linux for s/390 & z/Architecture | |
242 | ================================================== | |
243 | ||
b1955623 | 244 | Our addressing scheme is basically as follows: |
1da177e4 | 245 | |
b1955623 | 246 | Primary Space Home Space |
1da177e4 LT |
247 | Himem 0x7fffffff 2GB on s/390 ***************** **************** |
248 | currently 0x3ffffffffff (2^42)-1 * User Stack * * * | |
249 | on z/Architecture. ***************** * * | |
250 | * Shared Libs * * * | |
251 | ***************** * * | |
252 | * * * Kernel * | |
253 | * User Program * * * | |
254 | * Data BSS * * * | |
255 | * Text * * * | |
256 | * Sections * * * | |
257 | 0x00000000 ***************** **************** | |
258 | ||
b1955623 TH |
259 | This also means that we need to look at the PSW problem state bit and the |
260 | addressing mode to decide whether we are looking at user or kernel space. | |
261 | ||
262 | User space runs in primary address mode (or access register mode within | |
263 | the vdso code). | |
264 | ||
265 | The kernel usually also runs in home space mode, however when accessing | |
266 | user space the kernel switches to primary or secondary address mode if | |
267 | the mvcos instruction is not available or if a compare-and-swap (futex) | |
268 | instruction on a user space address is performed. | |
269 | ||
270 | When also looking at the ASCE control registers, this means: | |
271 | ||
272 | User space: | |
273 | - runs in primary or access register mode | |
274 | - cr1 contains the user asce | |
275 | - cr7 contains the user asce | |
276 | - cr13 contains the kernel asce | |
277 | ||
278 | Kernel space: | |
279 | - runs in home space mode | |
280 | - cr1 contains the user or kernel asce | |
281 | -> the kernel asce is loaded when a uaccess requires primary or | |
282 | secondary address mode | |
283 | - cr7 contains the user or kernel asce, (changed with set_fs()) | |
284 | - cr13 contains the kernel asce | |
285 | ||
286 | In case of uaccess the kernel changes to: | |
287 | - primary space mode in case of a uaccess (copy_to_user) and uses | |
288 | e.g. the mvcp instruction to access user space. However the kernel | |
289 | will stay in home space mode if the mvcos instruction is available | |
290 | - secondary space mode in case of futex atomic operations, so that the | |
291 | instructions come from primary address space and data from secondary | |
292 | space | |
293 | ||
294 | In case of KVM, the kernel runs in home space mode, but cr1 gets switched | |
295 | to contain the gmap asce before the SIE instruction gets executed. When | |
296 | the SIE instruction is finished, cr1 will be switched back to contain the | |
297 | user asce. | |
298 | ||
1da177e4 LT |
299 | |
300 | Virtual Addresses on s/390 & z/Architecture | |
301 | =========================================== | |
302 | ||
303 | A virtual address on s/390 is made up of 3 parts | |
304 | The SX ( segment index, roughly corresponding to the PGD & PMD in linux terminology ) | |
305 | being bits 1-11. | |
306 | The PX ( page index, corresponding to the page table entry (pte) in linux terminology ) | |
307 | being bits 12-19. | |
308 | The remaining bits BX (the byte index are the offset in the page ) | |
309 | i.e. bits 20 to 31. | |
310 | ||
311 | On z/Architecture in linux we currently make up an address from 4 parts. | |
312 | The region index bits (RX) 0-32 we currently use bits 22-32 | |
313 | The segment index (SX) being bits 33-43 | |
314 | The page index (PX) being bits 44-51 | |
315 | The byte index (BX) being bits 52-63 | |
316 | ||
317 | Notes: | |
318 | 1) s/390 has no PMD so the PMD is really the PGD also. | |
319 | A lot of this stuff is defined in pgtable.h. | |
320 | ||
321 | 2) Also seeing as s/390's page indexes are only 1k in size | |
322 | (bits 12-19 x 4 bytes per pte ) we use 1 ( page 4k ) | |
323 | to make the best use of memory by updating 4 segment indices | |
324 | entries each time we mess with a PMD & use offsets | |
325 | 0,1024,2048 & 3072 in this page as for our segment indexes. | |
326 | On z/Architecture our page indexes are now 2k in size | |
327 | ( bits 12-19 x 8 bytes per pte ) we do a similar trick | |
328 | but only mess with 2 segment indices each time we mess with | |
329 | a PMD. | |
330 | ||
2254f5a7 | 331 | 3) As z/Architecture supports up to a massive 5-level page table lookup we |
1da177e4 LT |
332 | can only use 3 currently on Linux ( as this is all the generic kernel |
333 | currently supports ) however this may change in future | |
334 | this allows us to access ( according to my sums ) | |
335 | 4TB of virtual storage per process i.e. | |
336 | 4096*512(PTES)*1024(PMDS)*2048(PGD) = 4398046511104 bytes, | |
337 | enough for another 2 or 3 of years I think :-). | |
338 | to do this we use a region-third-table designation type in | |
339 | our address space control registers. | |
340 | ||
341 | ||
342 | The Linux for s/390 & z/Architecture Kernel Task Structure | |
343 | ========================================================== | |
344 | Each process/thread under Linux for S390 has its own kernel task_struct | |
345 | defined in linux/include/linux/sched.h | |
346 | The S390 on initialisation & resuming of a process on a cpu sets | |
347 | the __LC_KERNEL_STACK variable in the spare prefix area for this cpu | |
53cb4726 | 348 | (which we use for per-processor globals). |
1da177e4 | 349 | |
53cb4726 | 350 | The kernel stack pointer is intimately tied with the task structure for |
1da177e4 LT |
351 | each processor as follows. |
352 | ||
353 | s/390 | |
354 | ************************ | |
355 | * 1 page kernel stack * | |
356 | * ( 4K ) * | |
357 | ************************ | |
358 | * 1 page task_struct * | |
359 | * ( 4K ) * | |
360 | 8K aligned ************************ | |
361 | ||
362 | z/Architecture | |
363 | ************************ | |
364 | * 2 page kernel stack * | |
365 | * ( 8K ) * | |
366 | ************************ | |
367 | * 2 page task_struct * | |
368 | * ( 8K ) * | |
369 | 16K aligned ************************ | |
370 | ||
371 | What this means is that we don't need to dedicate any register or global variable | |
372 | to point to the current running process & can retrieve it with the following | |
373 | very simple construct for s/390 & one very similar for z/Architecture. | |
374 | ||
375 | static inline struct task_struct * get_current(void) | |
376 | { | |
377 | struct task_struct *current; | |
378 | __asm__("lhi %0,-8192\n\t" | |
379 | "nr %0,15" | |
380 | : "=r" (current) ); | |
381 | return current; | |
382 | } | |
383 | ||
384 | i.e. just anding the current kernel stack pointer with the mask -8192. | |
fff9289b | 385 | Thankfully because Linux doesn't have support for nested IO interrupts |
1da177e4 LT |
386 | & our devices have large buffers can survive interrupts being shut for |
387 | short amounts of time we don't need a separate stack for interrupts. | |
388 | ||
389 | ||
390 | ||
391 | ||
392 | Register Usage & Stackframes on Linux for s/390 & z/Architecture | |
393 | ================================================================= | |
394 | Overview: | |
395 | --------- | |
396 | This is the code that gcc produces at the top & the bottom of | |
992caacf ML |
397 | each function. It usually is fairly consistent & similar from |
398 | function to function & if you know its layout you can probably | |
1da177e4 LT |
399 | make some headway in finding the ultimate cause of a problem |
400 | after a crash without a source level debugger. | |
401 | ||
402 | Note: To follow stackframes requires a knowledge of C or Pascal & | |
403 | limited knowledge of one assembly language. | |
404 | ||
405 | It should be noted that there are some differences between the | |
406 | s/390 & z/Architecture stack layouts as the z/Architecture stack layout didn't have | |
407 | to maintain compatibility with older linkage formats. | |
408 | ||
409 | Glossary: | |
410 | --------- | |
411 | alloca: | |
412 | This is a built in compiler function for runtime allocation | |
413 | of extra space on the callers stack which is obviously freed | |
414 | up on function exit ( e.g. the caller may choose to allocate nothing | |
415 | of a buffer of 4k if required for temporary purposes ), it generates | |
416 | very efficient code ( a few cycles ) when compared to alternatives | |
417 | like malloc. | |
418 | ||
419 | automatics: These are local variables on the stack, | |
420 | i.e they aren't in registers & they aren't static. | |
421 | ||
422 | back-chain: | |
423 | This is a pointer to the stack pointer before entering a | |
424 | framed functions ( see frameless function ) prologue got by | |
fff9289b | 425 | dereferencing the address of the current stack pointer, |
1da177e4 LT |
426 | i.e. got by accessing the 32 bit value at the stack pointers |
427 | current location. | |
428 | ||
429 | base-pointer: | |
430 | This is a pointer to the back of the literal pool which | |
431 | is an area just behind each procedure used to store constants | |
432 | in each function. | |
433 | ||
434 | call-clobbered: The caller probably needs to save these registers if there | |
435 | is something of value in them, on the stack or elsewhere before making a | |
436 | call to another procedure so that it can restore it later. | |
437 | ||
438 | epilogue: | |
439 | The code generated by the compiler to return to the caller. | |
440 | ||
441 | frameless-function | |
442 | A frameless function in Linux for s390 & z/Architecture is one which doesn't | |
443 | need more than the register save area ( 96 bytes on s/390, 160 on z/Architecture ) | |
444 | given to it by the caller. | |
445 | A frameless function never: | |
446 | 1) Sets up a back chain. | |
447 | 2) Calls alloca. | |
448 | 3) Calls other normal functions | |
449 | 4) Has automatics. | |
450 | ||
451 | GOT-pointer: | |
452 | This is a pointer to the global-offset-table in ELF | |
453 | ( Executable Linkable Format, Linux'es most common executable format ), | |
454 | all globals & shared library objects are found using this pointer. | |
455 | ||
456 | lazy-binding | |
457 | ELF shared libraries are typically only loaded when routines in the shared | |
458 | library are actually first called at runtime. This is lazy binding. | |
459 | ||
460 | procedure-linkage-table | |
461 | This is a table found from the GOT which contains pointers to routines | |
462 | in other shared libraries which can't be called to by easier means. | |
463 | ||
464 | prologue: | |
465 | The code generated by the compiler to set up the stack frame. | |
466 | ||
467 | outgoing-args: | |
468 | This is extra area allocated on the stack of the calling function if the | |
469 | parameters for the callee's cannot all be put in registers, the same | |
470 | area can be reused by each function the caller calls. | |
471 | ||
472 | routine-descriptor: | |
473 | A COFF executable format based concept of a procedure reference | |
474 | actually being 8 bytes or more as opposed to a simple pointer to the routine. | |
475 | This is typically defined as follows | |
476 | Routine Descriptor offset 0=Pointer to Function | |
477 | Routine Descriptor offset 4=Pointer to Table of Contents | |
478 | The table of contents/TOC is roughly equivalent to a GOT pointer. | |
479 | & it means that shared libraries etc. can be shared between several | |
480 | environments each with their own TOC. | |
481 | ||
482 | ||
483 | static-chain: This is used in nested functions a concept adopted from pascal | |
484 | by gcc not used in ansi C or C++ ( although quite useful ), basically it | |
485 | is a pointer used to reference local variables of enclosing functions. | |
486 | You might come across this stuff once or twice in your lifetime. | |
487 | ||
488 | e.g. | |
489 | The function below should return 11 though gcc may get upset & toss warnings | |
490 | about unused variables. | |
491 | int FunctionA(int a) | |
492 | { | |
493 | int b; | |
494 | FunctionC(int c) | |
495 | { | |
496 | b=c+1; | |
497 | } | |
498 | FunctionC(10); | |
499 | return(b); | |
500 | } | |
501 | ||
502 | ||
503 | s/390 & z/Architecture Register usage | |
504 | ===================================== | |
505 | r0 used by syscalls/assembly call-clobbered | |
506 | r1 used by syscalls/assembly call-clobbered | |
507 | r2 argument 0 / return value 0 call-clobbered | |
508 | r3 argument 1 / return value 1 (if long long) call-clobbered | |
509 | r4 argument 2 call-clobbered | |
510 | r5 argument 3 call-clobbered | |
d8c351a9 | 511 | r6 argument 4 saved |
1da177e4 LT |
512 | r7 pointer-to arguments 5 to ... saved |
513 | r8 this & that saved | |
514 | r9 this & that saved | |
515 | r10 static-chain ( if nested function ) saved | |
516 | r11 frame-pointer ( if function used alloca ) saved | |
517 | r12 got-pointer saved | |
518 | r13 base-pointer saved | |
519 | r14 return-address saved | |
520 | r15 stack-pointer saved | |
521 | ||
522 | f0 argument 0 / return value ( float/double ) call-clobbered | |
523 | f2 argument 1 call-clobbered | |
524 | f4 z/Architecture argument 2 saved | |
525 | f6 z/Architecture argument 3 saved | |
526 | The remaining floating points | |
527 | f1,f3,f5 f7-f15 are call-clobbered. | |
528 | ||
529 | Notes: | |
530 | ------ | |
531 | 1) The only requirement is that registers which are used | |
532 | by the callee are saved, e.g. the compiler is perfectly | |
2254f5a7 | 533 | capable of using r11 for purposes other than a frame a |
1da177e4 LT |
534 | frame pointer if a frame pointer is not needed. |
535 | 2) In functions with variable arguments e.g. printf the calling procedure | |
536 | is identical to one without variable arguments & the same number of | |
537 | parameters. However, the prologue of this function is somewhat more | |
538 | hairy owing to it having to move these parameters to the stack to | |
539 | get va_start, va_arg & va_end to work. | |
540 | 3) Access registers are currently unused by gcc but are used in | |
541 | the kernel. Possibilities exist to use them at the moment for | |
542 | temporary storage but it isn't recommended. | |
543 | 4) Only 4 of the floating point registers are used for | |
544 | parameter passing as older machines such as G3 only have only 4 | |
545 | & it keeps the stack frame compatible with other compilers. | |
546 | However with IEEE floating point emulation under linux on the | |
547 | older machines you are free to use the other 12. | |
548 | 5) A long long or double parameter cannot be have the | |
549 | first 4 bytes in a register & the second four bytes in the | |
550 | outgoing args area. It must be purely in the outgoing args | |
551 | area if crossing this boundary. | |
552 | 6) Floating point parameters are mixed with outgoing args | |
553 | on the outgoing args area in the order the are passed in as parameters. | |
554 | 7) Floating point arguments 2 & 3 are saved in the outgoing args area for | |
555 | z/Architecture | |
556 | ||
557 | ||
558 | Stack Frame Layout | |
559 | ------------------ | |
560 | s/390 z/Architecture | |
561 | 0 0 back chain ( a 0 here signifies end of back chain ) | |
562 | 4 8 eos ( end of stack, not used on Linux for S390 used in other linkage formats ) | |
563 | 8 16 glue used in other s/390 linkage formats for saved routine descriptors etc. | |
564 | 12 24 glue used in other s/390 linkage formats for saved routine descriptors etc. | |
565 | 16 32 scratch area | |
566 | 20 40 scratch area | |
567 | 24 48 saved r6 of caller function | |
568 | 28 56 saved r7 of caller function | |
569 | 32 64 saved r8 of caller function | |
570 | 36 72 saved r9 of caller function | |
571 | 40 80 saved r10 of caller function | |
572 | 44 88 saved r11 of caller function | |
573 | 48 96 saved r12 of caller function | |
574 | 52 104 saved r13 of caller function | |
575 | 56 112 saved r14 of caller function | |
576 | 60 120 saved r15 of caller function | |
577 | 64 128 saved f4 of caller function | |
578 | 72 132 saved f6 of caller function | |
579 | 80 undefined | |
580 | 96 160 outgoing args passed from caller to callee | |
581 | 96+x 160+x possible stack alignment ( 8 bytes desirable ) | |
582 | 96+x+y 160+x+y alloca space of caller ( if used ) | |
583 | 96+x+y+z 160+x+y+z automatics of caller ( if used ) | |
584 | 0 back-chain | |
585 | ||
586 | A sample program with comments. | |
587 | =============================== | |
588 | ||
589 | Comments on the function test | |
590 | ----------------------------- | |
591 | 1) It didn't need to set up a pointer to the constant pool gpr13 as it isn't used | |
592 | ( :-( ). | |
593 | 2) This is a frameless function & no stack is bought. | |
594 | 3) The compiler was clever enough to recognise that it could return the | |
595 | value in r2 as well as use it for the passed in parameter ( :-) ). | |
596 | 4) The basr ( branch relative & save ) trick works as follows the instruction | |
597 | has a special case with r0,r0 with some instruction operands is understood as | |
598 | the literal value 0, some risc architectures also do this ). So now | |
599 | we are branching to the next address & the address new program counter is | |
600 | in r13,so now we subtract the size of the function prologue we have executed | |
601 | + the size of the literal pool to get to the top of the literal pool | |
602 | 0040037c int test(int b) | |
603 | { # Function prologue below | |
604 | 40037c: 90 de f0 34 stm %r13,%r14,52(%r15) # Save registers r13 & r14 | |
605 | 400380: 0d d0 basr %r13,%r0 # Set up pointer to constant pool using | |
606 | 400382: a7 da ff fa ahi %r13,-6 # basr trick | |
607 | return(5+b); | |
608 | # Huge main program | |
609 | 400386: a7 2a 00 05 ahi %r2,5 # add 5 to r2 | |
610 | ||
611 | # Function epilogue below | |
612 | 40038a: 98 de f0 34 lm %r13,%r14,52(%r15) # restore registers r13 & 14 | |
613 | 40038e: 07 fe br %r14 # return | |
614 | } | |
615 | ||
616 | Comments on the function main | |
617 | ----------------------------- | |
618 | 1) The compiler did this function optimally ( 8-) ) | |
619 | ||
620 | Literal pool for main. | |
621 | 400390: ff ff ff ec .long 0xffffffec | |
622 | main(int argc,char *argv[]) | |
623 | { # Function prologue below | |
624 | 400394: 90 bf f0 2c stm %r11,%r15,44(%r15) # Save necessary registers | |
625 | 400398: 18 0f lr %r0,%r15 # copy stack pointer to r0 | |
626 | 40039a: a7 fa ff a0 ahi %r15,-96 # Make area for callee saving | |
627 | 40039e: 0d d0 basr %r13,%r0 # Set up r13 to point to | |
628 | 4003a0: a7 da ff f0 ahi %r13,-16 # literal pool | |
629 | 4003a4: 50 00 f0 00 st %r0,0(%r15) # Save backchain | |
630 | ||
631 | return(test(5)); # Main Program Below | |
632 | 4003a8: 58 e0 d0 00 l %r14,0(%r13) # load relative address of test from | |
633 | # literal pool | |
634 | 4003ac: a7 28 00 05 lhi %r2,5 # Set first parameter to 5 | |
635 | 4003b0: 4d ee d0 00 bas %r14,0(%r14,%r13) # jump to test setting r14 as return | |
636 | # address using branch & save instruction. | |
637 | ||
638 | # Function Epilogue below | |
639 | 4003b4: 98 bf f0 8c lm %r11,%r15,140(%r15)# Restore necessary registers. | |
640 | 4003b8: 07 fe br %r14 # return to do program exit | |
641 | } | |
642 | ||
643 | ||
644 | Compiler updates | |
645 | ---------------- | |
646 | ||
647 | main(int argc,char *argv[]) | |
648 | { | |
649 | 4004fc: 90 7f f0 1c stm %r7,%r15,28(%r15) | |
650 | 400500: a7 d5 00 04 bras %r13,400508 <main+0xc> | |
651 | 400504: 00 40 04 f4 .long 0x004004f4 | |
652 | # compiler now puts constant pool in code to so it saves an instruction | |
653 | 400508: 18 0f lr %r0,%r15 | |
654 | 40050a: a7 fa ff a0 ahi %r15,-96 | |
655 | 40050e: 50 00 f0 00 st %r0,0(%r15) | |
656 | return(test(5)); | |
657 | 400512: 58 10 d0 00 l %r1,0(%r13) | |
658 | 400516: a7 28 00 05 lhi %r2,5 | |
659 | 40051a: 0d e1 basr %r14,%r1 | |
660 | # compiler adds 1 extra instruction to epilogue this is done to | |
661 | # avoid processor pipeline stalls owing to data dependencies on g5 & | |
662 | # above as register 14 in the old code was needed directly after being loaded | |
663 | # by the lm %r11,%r15,140(%r15) for the br %14. | |
664 | 40051c: 58 40 f0 98 l %r4,152(%r15) | |
665 | 400520: 98 7f f0 7c lm %r7,%r15,124(%r15) | |
666 | 400524: 07 f4 br %r4 | |
667 | } | |
668 | ||
669 | ||
670 | Hartmut ( our compiler developer ) also has been threatening to take out the | |
671 | stack backchain in optimised code as this also causes pipeline stalls, you | |
672 | have been warned. | |
673 | ||
674 | 64 bit z/Architecture code disassembly | |
675 | -------------------------------------- | |
676 | ||
677 | If you understand the stuff above you'll understand the stuff | |
678 | below too so I'll avoid repeating myself & just say that | |
679 | some of the instructions have g's on the end of them to indicate | |
680 | they are 64 bit & the stack offsets are a bigger, | |
681 | the only other difference you'll find between 32 & 64 bit is that | |
682 | we now use f4 & f6 for floating point arguments on 64 bit. | |
683 | 00000000800005b0 <test>: | |
684 | int test(int b) | |
685 | { | |
686 | return(5+b); | |
687 | 800005b0: a7 2a 00 05 ahi %r2,5 | |
688 | 800005b4: b9 14 00 22 lgfr %r2,%r2 # downcast to integer | |
689 | 800005b8: 07 fe br %r14 | |
690 | 800005ba: 07 07 bcr 0,%r7 | |
691 | ||
692 | ||
693 | } | |
694 | ||
695 | 00000000800005bc <main>: | |
696 | main(int argc,char *argv[]) | |
697 | { | |
698 | 800005bc: eb bf f0 58 00 24 stmg %r11,%r15,88(%r15) | |
699 | 800005c2: b9 04 00 1f lgr %r1,%r15 | |
700 | 800005c6: a7 fb ff 60 aghi %r15,-160 | |
701 | 800005ca: e3 10 f0 00 00 24 stg %r1,0(%r15) | |
702 | return(test(5)); | |
703 | 800005d0: a7 29 00 05 lghi %r2,5 | |
704 | # brasl allows jumps > 64k & is overkill here bras would do fune | |
705 | 800005d4: c0 e5 ff ff ff ee brasl %r14,800005b0 <test> | |
706 | 800005da: e3 40 f1 10 00 04 lg %r4,272(%r15) | |
707 | 800005e0: eb bf f0 f8 00 04 lmg %r11,%r15,248(%r15) | |
708 | 800005e6: 07 f4 br %r4 | |
709 | } | |
710 | ||
711 | ||
712 | ||
713 | Compiling programs for debugging on Linux for s/390 & z/Architecture | |
714 | ==================================================================== | |
715 | -gdwarf-2 now works it should be considered the default debugging | |
716 | format for s/390 & z/Architecture as it is more reliable for debugging | |
717 | shared libraries, normal -g debugging works much better now | |
718 | Thanks to the IBM java compiler developers bug reports. | |
719 | ||
720 | This is typically done adding/appending the flags -g or -gdwarf-2 to the | |
721 | CFLAGS & LDFLAGS variables Makefile of the program concerned. | |
722 | ||
723 | If using gdb & you would like accurate displays of registers & | |
724 | stack traces compile without optimisation i.e make sure | |
725 | that there is no -O2 or similar on the CFLAGS line of the Makefile & | |
726 | the emitted gcc commands, obviously this will produce worse code | |
727 | ( not advisable for shipment ) but it is an aid to the debugging process. | |
728 | ||
729 | This aids debugging because the compiler will copy parameters passed in | |
730 | in registers onto the stack so backtracing & looking at passed in | |
731 | parameters will work, however some larger programs which use inline functions | |
732 | will not compile without optimisation. | |
733 | ||
734 | Debugging with optimisation has since much improved after fixing | |
735 | some bugs, please make sure you are using gdb-5.0 or later developed | |
736 | after Nov'2000. | |
737 | ||
1da177e4 | 738 | |
1da177e4 LT |
739 | |
740 | Debugging under VM | |
741 | ================== | |
742 | ||
743 | Notes | |
744 | ----- | |
745 | Addresses & values in the VM debugger are always hex never decimal | |
746 | Address ranges are of the format <HexValue1>-<HexValue2> or <HexValue1>.<HexValue2> | |
670e9f34 | 747 | e.g. The address range 0x2000 to 0x3000 can be described as 2000-3000 or 2000.1000 |
1da177e4 LT |
748 | |
749 | The VM Debugger is case insensitive. | |
750 | ||
751 | VM's strengths are usually other debuggers weaknesses you can get at any resource | |
752 | no matter how sensitive e.g. memory management resources,change address translation | |
753 | in the PSW. For kernel hacking you will reap dividends if you get good at it. | |
754 | ||
755 | The VM Debugger displays operators but not operands, probably because some | |
756 | of it was written when memory was expensive & the programmer was probably proud that | |
757 | it fitted into 2k of memory & the programmers & didn't want to shock hardcore VM'ers by | |
758 | changing the interface :-), also the debugger displays useful information on the same line & | |
759 | the author of the code probably felt that it was a good idea not to go over | |
760 | the 80 columns on the screen. | |
761 | ||
762 | As some of you are probably in a panic now this isn't as unintuitive as it may seem | |
763 | as the 390 instructions are easy to decode mentally & you can make a good guess at a lot | |
764 | of them as all the operands are nibble ( half byte aligned ) & if you have an objdump listing | |
765 | also it is quite easy to follow, if you don't have an objdump listing keep a copy of | |
766 | the s/390 Reference Summary & look at between pages 2 & 7 or alternatively the | |
767 | s/390 principles of operation. | |
768 | e.g. even I can guess that | |
769 | 0001AFF8' LR 180F CC 0 | |
770 | is a ( load register ) lr r0,r15 | |
771 | ||
772 | Also it is very easy to tell the length of a 390 instruction from the 2 most significant | |
773 | bits in the instruction ( not that this info is really useful except if you are trying to | |
774 | make sense of a hexdump of code ). | |
775 | Here is a table | |
776 | Bits Instruction Length | |
777 | ------------------------------------------ | |
778 | 00 2 Bytes | |
779 | 01 4 Bytes | |
780 | 10 4 Bytes | |
781 | 11 6 Bytes | |
782 | ||
783 | ||
784 | ||
785 | ||
786 | The debugger also displays other useful info on the same line such as the | |
787 | addresses being operated on destination addresses of branches & condition codes. | |
788 | e.g. | |
789 | 00019736' AHI A7DAFF0E CC 1 | |
790 | 000198BA' BRC A7840004 -> 000198C2' CC 0 | |
791 | 000198CE' STM 900EF068 >> 0FA95E78 CC 2 | |
792 | ||
793 | ||
794 | ||
795 | Useful VM debugger commands | |
796 | --------------------------- | |
797 | ||
798 | I suppose I'd better mention this before I start | |
799 | to list the current active traces do | |
800 | Q TR | |
801 | there can be a maximum of 255 of these per set | |
802 | ( more about trace sets later ). | |
803 | To stop traces issue a | |
804 | TR END. | |
805 | To delete a particular breakpoint issue | |
806 | TR DEL <breakpoint number> | |
807 | ||
808 | The PA1 key drops to CP mode so you can issue debugger commands, | |
809 | Doing alt c (on my 3270 console at least ) clears the screen. | |
810 | hitting b <enter> comes back to the running operating system | |
811 | from cp mode ( in our case linux ). | |
812 | It is typically useful to add shortcuts to your profile.exec file | |
813 | if you have one ( this is roughly equivalent to autoexec.bat in DOS ). | |
814 | file here are a few from mine. | |
815 | /* this gives me command history on issuing f12 */ | |
816 | set pf12 retrieve | |
817 | /* this continues */ | |
818 | set pf8 imm b | |
819 | /* goes to trace set a */ | |
820 | set pf1 imm tr goto a | |
821 | /* goes to trace set b */ | |
822 | set pf2 imm tr goto b | |
823 | /* goes to trace set c */ | |
824 | set pf3 imm tr goto c | |
825 | ||
826 | ||
827 | ||
828 | Instruction Tracing | |
829 | ------------------- | |
830 | Setting a simple breakpoint | |
831 | TR I PSWA <address> | |
832 | To debug a particular function try | |
833 | TR I R <function address range> | |
834 | TR I on its own will single step. | |
835 | TR I DATA <MNEMONIC> <OPTIONAL RANGE> will trace for particular mnemonics | |
836 | e.g. | |
837 | TR I DATA 4D R 0197BC.4000 | |
838 | will trace for BAS'es ( opcode 4D ) in the range 0197BC.4000 | |
839 | if you were inclined you could add traces for all branch instructions & | |
840 | suffix them with the run prefix so you would have a backtrace on screen | |
841 | when a program crashes. | |
842 | TR BR <INTO OR FROM> will trace branches into or out of an address. | |
843 | e.g. | |
844 | TR BR INTO 0 is often quite useful if a program is getting awkward & deciding | |
845 | to branch to 0 & crashing as this will stop at the address before in jumps to 0. | |
846 | TR I R <address range> RUN cmd d g | |
847 | single steps a range of addresses but stays running & | |
848 | displays the gprs on each step. | |
849 | ||
850 | ||
851 | ||
852 | Displaying & modifying Registers | |
853 | -------------------------------- | |
854 | D G will display all the gprs | |
855 | Adding a extra G to all the commands is necessary to access the full 64 bit | |
856 | content in VM on z/Architecture obviously this isn't required for access registers | |
857 | as these are still 32 bit. | |
858 | e.g. DGG instead of DG | |
859 | D X will display all the control registers | |
860 | D AR will display all the access registers | |
861 | D AR4-7 will display access registers 4 to 7 | |
862 | CPU ALL D G will display the GRPS of all CPUS in the configuration | |
863 | D PSW will display the current PSW | |
864 | st PSW 2000 will put the value 2000 into the PSW & | |
865 | cause crash your machine. | |
866 | D PREFIX displays the prefix offset | |
867 | ||
868 | ||
869 | Displaying Memory | |
870 | ----------------- | |
871 | To display memory mapped using the current PSW's mapping try | |
872 | D <range> | |
873 | To make VM display a message each time it hits a particular address & continue try | |
874 | D I<range> will disassemble/display a range of instructions. | |
875 | ST addr 32 bit word will store a 32 bit aligned address | |
876 | D T<range> will display the EBCDIC in an address ( if you are that way inclined ) | |
877 | D R<range> will display real addresses ( without DAT ) but with prefixing. | |
878 | There are other complex options to display if you need to get at say home space | |
879 | but are in primary space the easiest thing to do is to temporarily | |
880 | modify the PSW to the other addressing mode, display the stuff & then | |
881 | restore it. | |
882 | ||
883 | ||
884 | ||
885 | Hints | |
886 | ----- | |
887 | If you want to issue a debugger command without halting your virtual machine with the | |
888 | PA1 key try prefixing the command with #CP e.g. | |
889 | #cp tr i pswa 2000 | |
890 | also suffixing most debugger commands with RUN will cause them not | |
891 | to stop just display the mnemonic at the current instruction on the console. | |
892 | If you have several breakpoints you want to put into your program & | |
893 | you get fed up of cross referencing with System.map | |
894 | you can do the following trick for several symbols. | |
895 | grep do_signal System.map | |
896 | which emits the following among other things | |
897 | 0001f4e0 T do_signal | |
898 | now you can do | |
899 | ||
900 | TR I PSWA 0001f4e0 cmd msg * do_signal | |
901 | This sends a message to your own console each time do_signal is entered. | |
902 | ( As an aside I wrote a perl script once which automatically generated a REXX | |
903 | script with breakpoints on every kernel procedure, this isn't a good idea | |
904 | because there are thousands of these routines & VM can only set 255 breakpoints | |
905 | at a time so you nearly had to spend as long pruning the file down as you would | |
906 | entering the msg's by hand ),however, the trick might be useful for a single object file. | |
907 | On linux'es 3270 emulator x3270 there is a very useful option under the file ment | |
908 | Save Screens In File this is very good of keeping a copy of traces. | |
909 | ||
910 | From CMS help <command name> will give you online help on a particular command. | |
911 | e.g. | |
912 | HELP DISPLAY | |
913 | ||
914 | Also CP has a file called profile.exec which automatically gets called | |
915 | on startup of CMS ( like autoexec.bat ), keeping on a DOS analogy session | |
916 | CP has a feature similar to doskey, it may be useful for you to | |
917 | use profile.exec to define some keystrokes. | |
918 | e.g. | |
919 | SET PF9 IMM B | |
920 | This does a single step in VM on pressing F8. | |
921 | SET PF10 ^ | |
922 | This sets up the ^ key. | |
923 | which can be used for ^c (ctrl-c),^z (ctrl-z) which can't be typed directly into some 3270 consoles. | |
924 | SET PF11 ^- | |
925 | This types the starting keystrokes for a sysrq see SysRq below. | |
926 | SET PF12 RETRIEVE | |
927 | This retrieves command history on pressing F12. | |
928 | ||
929 | ||
930 | Sometimes in VM the display is set up to scroll automatically this | |
931 | can be very annoying if there are messages you wish to look at | |
932 | to stop this do | |
933 | TERM MORE 255 255 | |
934 | This will nearly stop automatic screen updates, however it will | |
935 | cause a denial of service if lots of messages go to the 3270 console, | |
936 | so it would be foolish to use this as the default on a production machine. | |
937 | ||
938 | ||
939 | Tracing particular processes | |
940 | ---------------------------- | |
941 | The kernel's text segment is intentionally at an address in memory that it will | |
942 | very seldom collide with text segments of user programs ( thanks Martin ), | |
943 | this simplifies debugging the kernel. | |
944 | However it is quite common for user processes to have addresses which collide | |
945 | this can make debugging a particular process under VM painful under normal | |
946 | circumstances as the process may change when doing a | |
947 | TR I R <address range>. | |
948 | Thankfully after reading VM's online help I figured out how to debug | |
949 | I particular process. | |
950 | ||
951 | Your first problem is to find the STD ( segment table designation ) | |
952 | of the program you wish to debug. | |
953 | There are several ways you can do this here are a few | |
954 | 1) objdump --syms <program to be debugged> | grep main | |
955 | To get the address of main in the program. | |
956 | tr i pswa <address of main> | |
957 | Start the program, if VM drops to CP on what looks like the entry | |
958 | point of the main function this is most likely the process you wish to debug. | |
959 | Now do a D X13 or D XG13 on z/Architecture. | |
960 | On 31 bit the STD is bits 1-19 ( the STO segment table origin ) | |
961 | & 25-31 ( the STL segment table length ) of CR13. | |
962 | now type | |
963 | TR I R STD <CR13's value> 0.7fffffff | |
964 | e.g. | |
965 | TR I R STD 8F32E1FF 0.7fffffff | |
966 | Another very useful variation is | |
967 | TR STORE INTO STD <CR13's value> <address range> | |
968 | for finding out when a particular variable changes. | |
969 | ||
970 | An alternative way of finding the STD of a currently running process | |
971 | is to do the following, ( this method is more complex but | |
6c28f2c0 | 972 | could be quite convenient if you aren't updating the kernel much & |
1da177e4 LT |
973 | so your kernel structures will stay constant for a reasonable period of |
974 | time ). | |
975 | ||
976 | grep task /proc/<pid>/status | |
977 | from this you should see something like | |
978 | task: 0f160000 ksp: 0f161de8 pt_regs: 0f161f68 | |
979 | This now gives you a pointer to the task structure. | |
980 | Now make CC:="s390-gcc -g" kernel/sched.s | |
981 | To get the task_struct stabinfo. | |
982 | ( task_struct is defined in include/linux/sched.h ). | |
983 | Now we want to look at | |
984 | task->active_mm->pgd | |
985 | on my machine the active_mm in the task structure stab is | |
986 | active_mm:(4,12),672,32 | |
987 | its offset is 672/8=84=0x54 | |
988 | the pgd member in the mm_struct stab is | |
989 | pgd:(4,6)=*(29,5),96,32 | |
990 | so its offset is 96/8=12=0xc | |
991 | ||
992 | so we'll | |
993 | hexdump -s 0xf160054 /dev/mem | more | |
994 | i.e. task_struct+active_mm offset | |
995 | to look at the active_mm member | |
996 | f160054 0fee cc60 0019 e334 0000 0000 0000 0011 | |
997 | hexdump -s 0x0feecc6c /dev/mem | more | |
998 | i.e. active_mm+pgd offset | |
999 | feecc6c 0f2c 0000 0000 0001 0000 0001 0000 0010 | |
1000 | we get something like | |
1001 | now do | |
1002 | TR I R STD <pgd|0x7f> 0.7fffffff | |
1003 | i.e. the 0x7f is added because the pgd only | |
1004 | gives the page table origin & we need to set the low bits | |
1005 | to the maximum possible segment table length. | |
1006 | TR I R STD 0f2c007f 0.7fffffff | |
1007 | on z/Architecture you'll probably need to do | |
1008 | TR I R STD <pgd|0x7> 0.ffffffffffffffff | |
1009 | to set the TableType to 0x1 & the Table length to 3. | |
1010 | ||
1011 | ||
1012 | ||
1013 | Tracing Program Exceptions | |
1014 | -------------------------- | |
1015 | If you get a crash which says something like | |
1016 | illegal operation or specification exception followed by a register dump | |
1017 | You can restart linux & trace these using the tr prog <range or value> trace option. | |
1018 | ||
1019 | ||
1020 | ||
1021 | The most common ones you will normally be tracing for is | |
1022 | 1=operation exception | |
1023 | 2=privileged operation exception | |
1024 | 4=protection exception | |
1025 | 5=addressing exception | |
1026 | 6=specification exception | |
1027 | 10=segment translation exception | |
1028 | 11=page translation exception | |
1029 | ||
1030 | The full list of these is on page 22 of the current s/390 Reference Summary. | |
1031 | e.g. | |
1032 | tr prog 10 will trace segment translation exceptions. | |
1033 | tr prog on its own will trace all program interruption codes. | |
1034 | ||
1035 | Trace Sets | |
1036 | ---------- | |
1037 | On starting VM you are initially in the INITIAL trace set. | |
1038 | You can do a Q TR to verify this. | |
1039 | If you have a complex tracing situation where you wish to wait for instance | |
1040 | till a driver is open before you start tracing IO, but know in your | |
1041 | heart that you are going to have to make several runs through the code till you | |
1042 | have a clue whats going on. | |
1043 | ||
1044 | What you can do is | |
1045 | TR I PSWA <Driver open address> | |
1046 | hit b to continue till breakpoint | |
1047 | reach the breakpoint | |
1048 | now do your | |
1049 | TR GOTO B | |
1050 | TR IO 7c08-7c09 inst int run | |
1051 | or whatever the IO channels you wish to trace are & hit b | |
1052 | ||
1053 | To got back to the initial trace set do | |
1054 | TR GOTO INITIAL | |
1055 | & the TR I PSWA <Driver open address> will be the only active breakpoint again. | |
1056 | ||
1057 | ||
1058 | Tracing linux syscalls under VM | |
1059 | ------------------------------- | |
1060 | Syscalls are implemented on Linux for S390 by the Supervisor call instruction (SVC) there 256 | |
1061 | possibilities of these as the instruction is made up of a 0xA opcode & the second byte being | |
1062 | the syscall number. They are traced using the simple command. | |
1063 | TR SVC <Optional value or range> | |
58cc855c | 1064 | the syscalls are defined in linux/arch/s390/include/asm/unistd.h |
1da177e4 LT |
1065 | e.g. to trace all file opens just do |
1066 | TR SVC 5 ( as this is the syscall number of open ) | |
1067 | ||
1068 | ||
1069 | SMP Specific commands | |
1070 | --------------------- | |
1071 | To find out how many cpus you have | |
1072 | Q CPUS displays all the CPU's available to your virtual machine | |
1073 | To find the cpu that the current cpu VM debugger commands are being directed at do | |
670e9f34 | 1074 | Q CPU to change the current cpu VM debugger commands are being directed at do |
1da177e4 LT |
1075 | CPU <desired cpu no> |
1076 | ||
1077 | On a SMP guest issue a command to all CPUs try prefixing the command with cpu all. | |
1078 | To issue a command to a particular cpu try cpu <cpu number> e.g. | |
1079 | CPU 01 TR I R 2000.3000 | |
1080 | If you are running on a guest with several cpus & you have a IO related problem | |
2254f5a7 | 1081 | & cannot follow the flow of code but you know it isn't smp related. |
1da177e4 LT |
1082 | from the bash prompt issue |
1083 | shutdown -h now or halt. | |
1084 | do a Q CPUS to find out how many cpus you have | |
1085 | detach each one of them from cp except cpu 0 | |
1086 | by issuing a | |
1087 | DETACH CPU 01-(number of cpus in configuration) | |
1088 | & boot linux again. | |
1089 | TR SIGP will trace inter processor signal processor instructions. | |
1090 | DEFINE CPU 01-(number in configuration) | |
1091 | will get your guests cpus back. | |
1092 | ||
1093 | ||
1094 | Help for displaying ascii textstrings | |
1095 | ------------------------------------- | |
1096 | On the very latest VM Nucleus'es VM can now display ascii | |
1097 | ( thanks Neale for the hint ) by doing | |
1098 | D TX<lowaddr>.<len> | |
1099 | e.g. | |
1100 | D TX0.100 | |
1101 | ||
1102 | Alternatively | |
1103 | ============= | |
1104 | Under older VM debuggers ( I love EBDIC too ) you can use this little program I wrote which | |
1105 | will convert a command line of hex digits to ascii text which can be compiled under linux & | |
1106 | you can copy the hex digits from your x3270 terminal to your xterm if you are debugging | |
1107 | from a linuxbox. | |
1108 | ||
1109 | This is quite useful when looking at a parameter passed in as a text string | |
1110 | under VM ( unless you are good at decoding ASCII in your head ). | |
1111 | ||
1112 | e.g. consider tracing an open syscall | |
1113 | TR SVC 5 | |
1114 | We have stopped at a breakpoint | |
1115 | 000151B0' SVC 0A05 -> 0001909A' CC 0 | |
1116 | ||
1117 | D 20.8 to check the SVC old psw in the prefix area & see was it from userspace | |
1118 | ( for the layout of the prefix area consult P18 of the s/390 390 Reference Summary | |
1119 | if you have it available ). | |
1120 | V00000020 070C2000 800151B2 | |
1121 | The problem state bit wasn't set & it's also too early in the boot sequence | |
1122 | for it to be a userspace SVC if it was we would have to temporarily switch the | |
1123 | psw to user space addressing so we could get at the first parameter of the open in | |
1124 | gpr2. | |
1125 | Next do a | |
1126 | D G2 | |
1127 | GPR 2 = 00014CB4 | |
1128 | Now display what gpr2 is pointing to | |
1129 | D 00014CB4.20 | |
1130 | V00014CB4 2F646576 2F636F6E 736F6C65 00001BF5 | |
1131 | V00014CC4 FC00014C B4001001 E0001000 B8070707 | |
1132 | Now copy the text till the first 00 hex ( which is the end of the string | |
1133 | to an xterm & do hex2ascii on it. | |
1134 | hex2ascii 2F646576 2F636F6E 736F6C65 00 | |
1135 | outputs | |
1136 | Decoded Hex:=/ d e v / c o n s o l e 0x00 | |
1137 | We were opening the console device, | |
1138 | ||
1139 | You can compile the code below yourself for practice :-), | |
1140 | /* | |
1141 | * hex2ascii.c | |
1142 | * a useful little tool for converting a hexadecimal command line to ascii | |
1143 | * | |
1144 | * Author(s): Denis Joseph Barrow (djbarrow@de.ibm.com,barrow_dj@yahoo.com) | |
1145 | * (C) 2000 IBM Deutschland Entwicklung GmbH, IBM Corporation. | |
1146 | */ | |
1147 | #include <stdio.h> | |
1148 | ||
1149 | int main(int argc,char *argv[]) | |
1150 | { | |
1151 | int cnt1,cnt2,len,toggle=0; | |
1152 | int startcnt=1; | |
1153 | unsigned char c,hex; | |
1154 | ||
1155 | if(argc>1&&(strcmp(argv[1],"-a")==0)) | |
1156 | startcnt=2; | |
1157 | printf("Decoded Hex:="); | |
1158 | for(cnt1=startcnt;cnt1<argc;cnt1++) | |
1159 | { | |
1160 | len=strlen(argv[cnt1]); | |
1161 | for(cnt2=0;cnt2<len;cnt2++) | |
1162 | { | |
1163 | c=argv[cnt1][cnt2]; | |
1164 | if(c>='0'&&c<='9') | |
1165 | c=c-'0'; | |
1166 | if(c>='A'&&c<='F') | |
1167 | c=c-'A'+10; | |
1168 | if(c>='a'&&c<='f') | |
1169 | c=c-'a'+10; | |
1170 | switch(toggle) | |
1171 | { | |
1172 | case 0: | |
1173 | hex=c<<4; | |
1174 | toggle=1; | |
1175 | break; | |
1176 | case 1: | |
1177 | hex+=c; | |
1178 | if(hex<32||hex>127) | |
1179 | { | |
1180 | if(startcnt==1) | |
1181 | printf("0x%02X ",(int)hex); | |
1182 | else | |
1183 | printf("."); | |
1184 | } | |
1185 | else | |
1186 | { | |
1187 | printf("%c",hex); | |
1188 | if(startcnt==1) | |
1189 | printf(" "); | |
1190 | } | |
1191 | toggle=0; | |
1192 | break; | |
1193 | } | |
1194 | } | |
1195 | } | |
1196 | printf("\n"); | |
1197 | } | |
1198 | ||
1199 | ||
1200 | ||
1201 | ||
1202 | Stack tracing under VM | |
1203 | ---------------------- | |
1204 | A basic backtrace | |
1205 | ----------------- | |
1206 | ||
1207 | Here are the tricks I use 9 out of 10 times it works pretty well, | |
1208 | ||
1209 | When your backchain reaches a dead end | |
1210 | -------------------------------------- | |
1211 | This can happen when an exception happens in the kernel & the kernel is entered twice | |
1212 | if you reach the NULL pointer at the end of the back chain you should be | |
1213 | able to sniff further back if you follow the following tricks. | |
1214 | 1) A kernel address should be easy to recognise since it is in | |
1215 | primary space & the problem state bit isn't set & also | |
1216 | The Hi bit of the address is set. | |
1217 | 2) Another backchain should also be easy to recognise since it is an | |
1218 | address pointing to another address approximately 100 bytes or 0x70 hex | |
1219 | behind the current stackpointer. | |
1220 | ||
1221 | ||
1222 | Here is some practice. | |
1223 | boot the kernel & hit PA1 at some random time | |
1224 | d g to display the gprs, this should display something like | |
1225 | GPR 0 = 00000001 00156018 0014359C 00000000 | |
1226 | GPR 4 = 00000001 001B8888 000003E0 00000000 | |
1227 | GPR 8 = 00100080 00100084 00000000 000FE000 | |
1228 | GPR 12 = 00010400 8001B2DC 8001B36A 000FFED8 | |
1229 | Note that GPR14 is a return address but as we are real men we are going to | |
1230 | trace the stack. | |
1231 | display 0x40 bytes after the stack pointer. | |
1232 | ||
1233 | V000FFED8 000FFF38 8001B838 80014C8E 000FFF38 | |
1234 | V000FFEE8 00000000 00000000 000003E0 00000000 | |
1235 | V000FFEF8 00100080 00100084 00000000 000FE000 | |
1236 | V000FFF08 00010400 8001B2DC 8001B36A 000FFED8 | |
1237 | ||
1238 | ||
1239 | Ah now look at whats in sp+56 (sp+0x38) this is 8001B36A our saved r14 if | |
1240 | you look above at our stackframe & also agrees with GPR14. | |
1241 | ||
1242 | now backchain | |
1243 | d 000FFF38.40 | |
1244 | we now are taking the contents of SP to get our first backchain. | |
1245 | ||
1246 | V000FFF38 000FFFA0 00000000 00014995 00147094 | |
1247 | V000FFF48 00147090 001470A0 000003E0 00000000 | |
1248 | V000FFF58 00100080 00100084 00000000 001BF1D0 | |
1249 | V000FFF68 00010400 800149BA 80014CA6 000FFF38 | |
1250 | ||
1251 | This displays a 2nd return address of 80014CA6 | |
1252 | ||
1253 | now do d 000FFFA0.40 for our 3rd backchain | |
1254 | ||
1255 | V000FFFA0 04B52002 0001107F 00000000 00000000 | |
1256 | V000FFFB0 00000000 00000000 FF000000 0001107F | |
1257 | V000FFFC0 00000000 00000000 00000000 00000000 | |
1258 | V000FFFD0 00010400 80010802 8001085A 000FFFA0 | |
1259 | ||
1260 | ||
1261 | our 3rd return address is 8001085A | |
1262 | ||
1263 | as the 04B52002 looks suspiciously like rubbish it is fair to assume that the kernel entry routines | |
2254f5a7 | 1264 | for the sake of optimisation don't set up a backchain. |
1da177e4 LT |
1265 | |
1266 | now look at System.map to see if the addresses make any sense. | |
1267 | ||
1268 | grep -i 0001b3 System.map | |
1269 | outputs among other things | |
1270 | 0001b304 T cpu_idle | |
1271 | so 8001B36A | |
1272 | is cpu_idle+0x66 ( quiet the cpu is asleep, don't wake it ) | |
1273 | ||
1274 | ||
1275 | grep -i 00014 System.map | |
1276 | produces among other things | |
1277 | 00014a78 T start_kernel | |
1278 | so 0014CA6 is start_kernel+some hex number I can't add in my head. | |
1279 | ||
1280 | grep -i 00108 System.map | |
1281 | this produces | |
1282 | 00010800 T _stext | |
1283 | so 8001085A is _stext+0x5a | |
1284 | ||
1285 | Congrats you've done your first backchain. | |
1286 | ||
1287 | ||
1288 | ||
1289 | s/390 & z/Architecture IO Overview | |
1290 | ================================== | |
1291 | ||
1292 | I am not going to give a course in 390 IO architecture as this would take me quite a | |
1293 | while & I'm no expert. Instead I'll give a 390 IO architecture summary for Dummies if you have | |
1294 | the s/390 principles of operation available read this instead. If nothing else you may find a few | |
1295 | useful keywords in here & be able to use them on a web search engine like altavista to find | |
1296 | more useful information. | |
1297 | ||
1298 | Unlike other bus architectures modern 390 systems do their IO using mostly | |
1299 | fibre optics & devices such as tapes & disks can be shared between several mainframes, | |
2254f5a7 | 1300 | also S390 can support up to 65536 devices while a high end PC based system might be choking |
1da177e4 LT |
1301 | with around 64. Here is some of the common IO terminology |
1302 | ||
1303 | Subchannel: | |
2254f5a7 | 1304 | This is the logical number most IO commands use to talk to an IO device there can be up to |
1da177e4 LT |
1305 | 0x10000 (65536) of these in a configuration typically there is a few hundred. Under VM |
1306 | for simplicity they are allocated contiguously, however on the native hardware they are not | |
1307 | they typically stay consistent between boots provided no new hardware is inserted or removed. | |
1308 | Under Linux for 390 we use these as IRQ's & also when issuing an IO command (CLEAR SUBCHANNEL, | |
1309 | HALT SUBCHANNEL,MODIFY SUBCHANNEL,RESUME SUBCHANNEL,START SUBCHANNEL,STORE SUBCHANNEL & | |
1310 | TEST SUBCHANNEL ) we use this as the ID of the device we wish to talk to, the most | |
1311 | important of these instructions are START SUBCHANNEL ( to start IO ), TEST SUBCHANNEL ( to check | |
1312 | whether the IO completed successfully ), & HALT SUBCHANNEL ( to kill IO ), a subchannel | |
2254f5a7 | 1313 | can have up to 8 channel paths to a device this offers redundancy if one is not available. |
1da177e4 LT |
1314 | |
1315 | ||
1316 | Device Number: | |
1317 | This number remains static & Is closely tied to the hardware, there are 65536 of these | |
1318 | also they are made up of a CHPID ( Channel Path ID, the most significant 8 bits ) | |
1319 | & another lsb 8 bits. These remain static even if more devices are inserted or removed | |
1320 | from the hardware, there is a 1 to 1 mapping between Subchannels & Device Numbers provided | |
2254f5a7 | 1321 | devices aren't inserted or removed. |
1da177e4 LT |
1322 | |
1323 | Channel Control Words: | |
1324 | CCWS are linked lists of instructions initially pointed to by an operation request block (ORB), | |
1325 | which is initially given to Start Subchannel (SSCH) command along with the subchannel number | |
1326 | for the IO subsystem to process while the CPU continues executing normal code. | |
1327 | These come in two flavours, Format 0 ( 24 bit for backward ) | |
1328 | compatibility & Format 1 ( 31 bit ). These are typically used to issue read & write | |
1329 | ( & many other instructions ) they consist of a length field & an absolute address field. | |
1330 | For each IO typically get 1 or 2 interrupts one for channel end ( primary status ) when the | |
1331 | channel is idle & the second for device end ( secondary status ) sometimes you get both | |
1332 | concurrently, you check how the IO went on by issuing a TEST SUBCHANNEL at each interrupt, | |
1333 | from which you receive an Interruption response block (IRB). If you get channel & device end | |
1334 | status in the IRB without channel checks etc. your IO probably went okay. If you didn't you | |
fff9289b | 1335 | probably need a doctor to examine the IRB & extended status word etc. |
2254f5a7 | 1336 | If an error occurs, more sophisticated control units have a facility known as |
1da177e4 LT |
1337 | concurrent sense this means that if an error occurs Extended sense information will |
1338 | be presented in the Extended status word in the IRB if not you have to issue a | |
1339 | subsequent SENSE CCW command after the test subchannel. | |
1340 | ||
1341 | ||
1342 | TPI( Test pending interrupt) can also be used for polled IO but in multitasking multiprocessor | |
1343 | systems it isn't recommended except for checking special cases ( i.e. non looping checks for | |
1344 | pending IO etc. ). | |
1345 | ||
1346 | Store Subchannel & Modify Subchannel can be used to examine & modify operating characteristics | |
1347 | of a subchannel ( e.g. channel paths ). | |
1348 | ||
1349 | Other IO related Terms: | |
1350 | Sysplex: S390's Clustering Technology | |
1351 | QDIO: S390's new high speed IO architecture to support devices such as gigabit ethernet, | |
1352 | this architecture is also designed to be forward compatible with up & coming 64 bit machines. | |
1353 | ||
1354 | ||
1355 | General Concepts | |
1356 | ||
1357 | Input Output Processors (IOP's) are responsible for communicating between | |
1358 | the mainframe CPU's & the channel & relieve the mainframe CPU's from the | |
1359 | burden of communicating with IO devices directly, this allows the CPU's to | |
1360 | concentrate on data processing. | |
1361 | ||
1362 | IOP's can use one or more links ( known as channel paths ) to talk to each | |
1363 | IO device. It first checks for path availability & chooses an available one, | |
1364 | then starts ( & sometimes terminates IO ). | |
992caacf | 1365 | There are two types of channel path: ESCON & the Parallel IO interface. |
1da177e4 LT |
1366 | |
1367 | IO devices are attached to control units, control units provide the | |
1368 | logic to interface the channel paths & channel path IO protocols to | |
1369 | the IO devices, they can be integrated with the devices or housed separately | |
1370 | & often talk to several similar devices ( typical examples would be raid | |
1371 | controllers or a control unit which connects to 1000 3270 terminals ). | |
1372 | ||
1373 | ||
1374 | +---------------------------------------------------------------+ | |
1375 | | +-----+ +-----+ +-----+ +-----+ +----------+ +----------+ | | |
1376 | | | CPU | | CPU | | CPU | | CPU | | Main | | Expanded | | | |
1377 | | | | | | | | | | | Memory | | Storage | | | |
1378 | | +-----+ +-----+ +-----+ +-----+ +----------+ +----------+ | | |
1379 | |---------------------------------------------------------------+ | |
1380 | | IOP | IOP | IOP | | |
1381 | |--------------------------------------------------------------- | |
1382 | | C | C | C | C | C | C | C | C | C | C | C | C | C | C | C | C | | |
1383 | ---------------------------------------------------------------- | |
1384 | || || | |
1385 | || Bus & Tag Channel Path || ESCON | |
1386 | || ====================== || Channel | |
1387 | || || || || Path | |
1388 | +----------+ +----------+ +----------+ | |
1389 | | | | | | | | |
1390 | | CU | | CU | | CU | | |
1391 | | | | | | | | |
1392 | +----------+ +----------+ +----------+ | |
1393 | | | | | | | |
1394 | +----------+ +----------+ +----------+ +----------+ +----------+ | |
1395 | |I/O Device| |I/O Device| |I/O Device| |I/O Device| |I/O Device| | |
1396 | +----------+ +----------+ +----------+ +----------+ +----------+ | |
1397 | CPU = Central Processing Unit | |
1398 | C = Channel | |
1399 | IOP = IP Processor | |
1400 | CU = Control Unit | |
1401 | ||
1402 | The 390 IO systems come in 2 flavours the current 390 machines support both | |
1403 | ||
992caacf | 1404 | The Older 360 & 370 Interface,sometimes called the Parallel I/O interface, |
1da177e4 LT |
1405 | sometimes called Bus-and Tag & sometimes Original Equipment Manufacturers |
1406 | Interface (OEMI). | |
1407 | ||
992caacf | 1408 | This byte wide Parallel channel path/bus has parity & data on the "Bus" cable |
1da177e4 LT |
1409 | & control lines on the "Tag" cable. These can operate in byte multiplex mode for |
1410 | sharing between several slow devices or burst mode & monopolize the channel for the | |
2254f5a7 | 1411 | whole burst. Up to 256 devices can be addressed on one of these cables. These cables are |
1da177e4 LT |
1412 | about one inch in diameter. The maximum unextended length supported by these cables is |
1413 | 125 Meters but this can be extended up to 2km with a fibre optic channel extended | |
1414 | such as a 3044. The maximum burst speed supported is 4.5 megabytes per second however | |
1415 | some really old processors support only transfer rates of 3.0, 2.0 & 1.0 MB/sec. | |
1416 | One of these paths can be daisy chained to up to 8 control units. | |
1417 | ||
1418 | ||
1419 | ESCON if fibre optic it is also called FICON | |
1420 | Was introduced by IBM in 1990. Has 2 fibre optic cables & uses either leds or lasers | |
2254f5a7 | 1421 | for communication at a signaling rate of up to 200 megabits/sec. As 10bits are transferred |
1da177e4 LT |
1422 | for every 8 bits info this drops to 160 megabits/sec & to 18.6 Megabytes/sec once |
1423 | control info & CRC are added. ESCON only operates in burst mode. | |
1424 | ||
1425 | ESCONs typical max cable length is 3km for the led version & 20km for the laser version | |
1426 | known as XDF ( extended distance facility ). This can be further extended by using an | |
1427 | ESCON director which triples the above mentioned ranges. Unlike Bus & Tag as ESCON is | |
1428 | serial it uses a packet switching architecture the standard Bus & Tag control protocol | |
2254f5a7 | 1429 | is however present within the packets. Up to 256 devices can be attached to each control |
1da177e4 LT |
1430 | unit that uses one of these interfaces. |
1431 | ||
1432 | Common 390 Devices include: | |
1433 | Network adapters typically OSA2,3172's,2116's & OSA-E gigabit ethernet adapters, | |
1434 | Consoles 3270 & 3215 ( a teletype emulated under linux for a line mode console ). | |
1435 | DASD's direct access storage devices ( otherwise known as hard disks ). | |
1436 | Tape Drives. | |
1437 | CTC ( Channel to Channel Adapters ), | |
992caacf | 1438 | ESCON or Parallel Cables used as a very high speed serial link |
1da177e4 LT |
1439 | between 2 machines. We use 2 cables under linux to do a bi-directional serial link. |
1440 | ||
1441 | ||
1442 | Debugging IO on s/390 & z/Architecture under VM | |
1443 | =============================================== | |
1444 | ||
1445 | Now we are ready to go on with IO tracing commands under VM | |
1446 | ||
1447 | A few self explanatory queries: | |
1448 | Q OSA | |
1449 | Q CTC | |
1450 | Q DISK ( This command is CMS specific ) | |
1451 | Q DASD | |
1452 | ||
1453 | ||
1454 | ||
1455 | ||
1456 | ||
1457 | ||
1458 | Q OSA on my machine returns | |
1459 | OSA 7C08 ON OSA 7C08 SUBCHANNEL = 0000 | |
1460 | OSA 7C09 ON OSA 7C09 SUBCHANNEL = 0001 | |
1461 | OSA 7C14 ON OSA 7C14 SUBCHANNEL = 0002 | |
1462 | OSA 7C15 ON OSA 7C15 SUBCHANNEL = 0003 | |
1463 | ||
992caacf ML |
1464 | If you have a guest with certain privileges you may be able to see devices |
1465 | which don't belong to you. To avoid this, add the option V. | |
1da177e4 LT |
1466 | e.g. |
1467 | Q V OSA | |
1468 | ||
1469 | Now using the device numbers returned by this command we will | |
1470 | Trace the io starting up on the first device 7c08 & 7c09 | |
1471 | In our simplest case we can trace the | |
1472 | start subchannels | |
1473 | like TR SSCH 7C08-7C09 | |
1474 | or the halt subchannels | |
1475 | or TR HSCH 7C08-7C09 | |
1476 | MSCH's ,STSCH's I think you can guess the rest | |
1477 | ||
1478 | Ingo's favourite trick is tracing all the IO's & CCWS & spooling them into the reader of another | |
1479 | VM guest so he can ftp the logfile back to his own machine.I'll do a small bit of this & give you | |
1480 | a look at the output. | |
1481 | ||
1482 | 1) Spool stdout to VM reader | |
1483 | SP PRT TO (another vm guest ) or * for the local vm guest | |
1484 | 2) Fill the reader with the trace | |
1485 | TR IO 7c08-7c09 INST INT CCW PRT RUN | |
1486 | 3) Start up linux | |
1487 | i 00c | |
1488 | 4) Finish the trace | |
1489 | TR END | |
1490 | 5) close the reader | |
1491 | C PRT | |
1492 | 6) list reader contents | |
1493 | RDRLIST | |
1494 | 7) copy it to linux4's minidisk | |
1495 | RECEIVE / LOG TXT A1 ( replace | |
1496 | 8) | |
1497 | filel & press F11 to look at it | |
53cb4726 | 1498 | You should see something like: |
1da177e4 LT |
1499 | |
1500 | 00020942' SSCH B2334000 0048813C CC 0 SCH 0000 DEV 7C08 | |
1501 | CPA 000FFDF0 PARM 00E2C9C4 KEY 0 FPI C0 LPM 80 | |
1502 | CCW 000FFDF0 E4200100 00487FE8 0000 E4240100 ........ | |
1503 | IDAL 43D8AFE8 | |
1504 | IDAL 0FB76000 | |
1505 | 00020B0A' I/O DEV 7C08 -> 000197BC' SCH 0000 PARM 00E2C9C4 | |
1506 | 00021628' TSCH B2354000 >> 00488164 CC 0 SCH 0000 DEV 7C08 | |
1507 | CCWA 000FFDF8 DEV STS 0C SCH STS 00 CNT 00EC | |
1508 | KEY 0 FPI C0 CC 0 CTLS 4007 | |
1509 | 00022238' STSCH B2344000 >> 00488108 CC 0 SCH 0000 DEV 7C08 | |
1510 | ||
1511 | If you don't like messing up your readed ( because you possibly booted from it ) | |
1512 | you can alternatively spool it to another readers guest. | |
1513 | ||
1514 | ||
1515 | Other common VM device related commands | |
1516 | --------------------------------------------- | |
1517 | These commands are listed only because they have | |
1518 | been of use to me in the past & may be of use to | |
1519 | you too. For more complete info on each of the commands | |
1520 | use type HELP <command> from CMS. | |
1521 | detaching devices | |
1522 | DET <devno range> | |
1523 | ATT <devno range> <guest> | |
1524 | attach a device to guest * for your own guest | |
1525 | READY <devno> cause VM to issue a fake interrupt. | |
1526 | ||
1527 | The VARY command is normally only available to VM administrators. | |
1528 | VARY ON PATH <path> TO <devno range> | |
1529 | VARY OFF PATH <PATH> FROM <devno range> | |
1530 | This is used to switch on or off channel paths to devices. | |
1531 | ||
1532 | Q CHPID <channel path ID> | |
1533 | This displays state of devices using this channel path | |
1534 | D SCHIB <subchannel> | |
1535 | This displays the subchannel information SCHIB block for the device. | |
1536 | this I believe is also only available to administrators. | |
1537 | DEFINE CTC <devno> | |
1538 | defines a virtual CTC channel to channel connection | |
1539 | 2 need to be defined on each guest for the CTC driver to use. | |
1540 | COUPLE devno userid remote devno | |
1541 | Joins a local virtual device to a remote virtual device | |
1542 | ( commonly used for the CTC driver ). | |
1543 | ||
1544 | Building a VM ramdisk under CMS which linux can use | |
1545 | def vfb-<blocksize> <subchannel> <number blocks> | |
1546 | blocksize is commonly 4096 for linux. | |
1547 | Formatting it | |
1548 | format <subchannel> <driver letter e.g. x> (blksize <blocksize> | |
1549 | ||
1550 | Sharing a disk between multiple guests | |
1551 | LINK userid devno1 devno2 mode password | |
1552 | ||
1553 | ||
1554 | ||
1555 | GDB on S390 | |
1556 | =========== | |
1557 | N.B. if compiling for debugging gdb works better without optimisation | |
1558 | ( see Compiling programs for debugging ) | |
1559 | ||
1560 | invocation | |
1561 | ---------- | |
1562 | gdb <victim program> <optional corefile> | |
1563 | ||
1564 | Online help | |
1565 | ----------- | |
1566 | help: gives help on commands | |
1567 | e.g. | |
1568 | help | |
1569 | help display | |
1570 | Note gdb's online help is very good use it. | |
1571 | ||
1572 | ||
1573 | Assembly | |
1574 | -------- | |
1575 | info registers: displays registers other than floating point. | |
1576 | info all-registers: displays floating points as well. | |
fff9289b | 1577 | disassemble: disassembles |
1da177e4 LT |
1578 | e.g. |
1579 | disassemble without parameters will disassemble the current function | |
1580 | disassemble $pc $pc+10 | |
1581 | ||
1582 | Viewing & modifying variables | |
1583 | ----------------------------- | |
1584 | print or p: displays variable or register | |
1585 | e.g. p/x $sp will display the stack pointer | |
1586 | ||
1587 | display: prints variable or register each time program stops | |
1588 | e.g. | |
1589 | display/x $pc will display the program counter | |
1590 | display argc | |
1591 | ||
1592 | undisplay : undo's display's | |
1593 | ||
1594 | info breakpoints: shows all current breakpoints | |
1595 | ||
fff9289b | 1596 | info stack: shows stack back trace ( if this doesn't work too well, I'll show you the |
1da177e4 LT |
1597 | stacktrace by hand below ). |
1598 | ||
1599 | info locals: displays local variables. | |
1600 | ||
1601 | info args: display current procedure arguments. | |
1602 | ||
1603 | set args: will set argc & argv each time the victim program is invoked. | |
1604 | ||
1605 | set <variable>=value | |
1606 | set argc=100 | |
1607 | set $pc=0 | |
1608 | ||
1609 | ||
1610 | ||
1611 | Modifying execution | |
1612 | ------------------- | |
1613 | step: steps n lines of sourcecode | |
1614 | step steps 1 line. | |
1615 | step 100 steps 100 lines of code. | |
1616 | ||
1617 | next: like step except this will not step into subroutines | |
1618 | ||
1619 | stepi: steps a single machine code instruction. | |
1620 | e.g. stepi 100 | |
1621 | ||
1622 | nexti: steps a single machine code instruction but will not step into subroutines. | |
1623 | ||
1624 | finish: will run until exit of the current routine | |
1625 | ||
1626 | run: (re)starts a program | |
1627 | ||
1628 | cont: continues a program | |
1629 | ||
1630 | quit: exits gdb. | |
1631 | ||
1632 | ||
1633 | breakpoints | |
1634 | ------------ | |
1635 | ||
1636 | break | |
1637 | sets a breakpoint | |
1638 | e.g. | |
1639 | ||
1640 | break main | |
1641 | ||
1642 | break *$pc | |
1643 | ||
1644 | break *0x400618 | |
1645 | ||
19f59460 | 1646 | Here's a really useful one for large programs |
1da177e4 LT |
1647 | rbr |
1648 | Set a breakpoint for all functions matching REGEXP | |
1649 | e.g. | |
1650 | rbr 390 | |
1651 | will set a breakpoint with all functions with 390 in their name. | |
1652 | ||
1653 | info breakpoints | |
1654 | lists all breakpoints | |
1655 | ||
1656 | delete: delete breakpoint by number or delete them all | |
1657 | e.g. | |
1658 | delete 1 will delete the first breakpoint | |
1659 | delete will delete them all | |
1660 | ||
1661 | watch: This will set a watchpoint ( usually hardware assisted ), | |
1662 | This will watch a variable till it changes | |
1663 | e.g. | |
1664 | watch cnt, will watch the variable cnt till it changes. | |
1665 | As an aside unfortunately gdb's, architecture independent watchpoint code | |
1666 | is inconsistent & not very good, watchpoints usually work but not always. | |
1667 | ||
1668 | info watchpoints: Display currently active watchpoints | |
1669 | ||
1670 | condition: ( another useful one ) | |
1671 | Specify breakpoint number N to break only if COND is true. | |
1672 | Usage is `condition N COND', where N is an integer and COND is an | |
1673 | expression to be evaluated whenever breakpoint N is reached. | |
1674 | ||
1675 | ||
1676 | ||
1677 | User defined functions/macros | |
1678 | ----------------------------- | |
1679 | define: ( Note this is very very useful,simple & powerful ) | |
1680 | usage define <name> <list of commands> end | |
1681 | ||
1682 | examples which you should consider putting into .gdbinit in your home directory | |
1683 | define d | |
1684 | stepi | |
1685 | disassemble $pc $pc+10 | |
1686 | end | |
1687 | ||
1688 | define e | |
1689 | nexti | |
1690 | disassemble $pc $pc+10 | |
1691 | end | |
1692 | ||
1693 | ||
1694 | Other hard to classify stuff | |
1695 | ---------------------------- | |
1696 | signal n: | |
1697 | sends the victim program a signal. | |
1698 | e.g. signal 3 will send a SIGQUIT. | |
1699 | ||
1700 | info signals: | |
1701 | what gdb does when the victim receives certain signals. | |
1702 | ||
1703 | list: | |
1704 | e.g. | |
1705 | list lists current function source | |
6c28f2c0 | 1706 | list 1,10 list first 10 lines of current file. |
1da177e4 LT |
1707 | list test.c:1,10 |
1708 | ||
1709 | ||
1710 | directory: | |
1711 | Adds directories to be searched for source if gdb cannot find the source. | |
2254f5a7 | 1712 | (note it is a bit sensitive about slashes) |
1da177e4 LT |
1713 | e.g. To add the root of the filesystem to the searchpath do |
1714 | directory // | |
1715 | ||
1716 | ||
1717 | call <function> | |
1718 | This calls a function in the victim program, this is pretty powerful | |
1719 | e.g. | |
1720 | (gdb) call printf("hello world") | |
1721 | outputs: | |
1722 | $1 = 11 | |
1723 | ||
1724 | You might now be thinking that the line above didn't work, something extra had to be done. | |
1725 | (gdb) call fflush(stdout) | |
1726 | hello world$2 = 0 | |
1727 | As an aside the debugger also calls malloc & free under the hood | |
1728 | to make space for the "hello world" string. | |
1729 | ||
1730 | ||
1731 | ||
1732 | hints | |
1733 | ----- | |
1734 | 1) command completion works just like bash | |
1735 | ( if you are a bad typist like me this really helps ) | |
1736 | e.g. hit br <TAB> & cursor up & down :-). | |
1737 | ||
1738 | 2) if you have a debugging problem that takes a few steps to recreate | |
1739 | put the steps into a file called .gdbinit in your current working directory | |
1740 | if you have defined a few extra useful user defined commands put these in | |
1741 | your home directory & they will be read each time gdb is launched. | |
1742 | ||
1743 | A typical .gdbinit file might be. | |
1744 | break main | |
1745 | run | |
1746 | break runtime_exception | |
1747 | cont | |
1748 | ||
1749 | ||
1750 | stack chaining in gdb by hand | |
1751 | ----------------------------- | |
1752 | This is done using a the same trick described for VM | |
1753 | p/x (*($sp+56))&0x7fffffff get the first backchain. | |
1754 | ||
1755 | For z/Architecture | |
1756 | Replace 56 with 112 & ignore the &0x7fffffff | |
1757 | in the macros below & do nasty casts to longs like the following | |
1758 | as gdb unfortunately deals with printed arguments as ints which | |
1759 | messes up everything. | |
1760 | i.e. here is a 3rd backchain dereference | |
1761 | p/x *(long *)(***(long ***)$sp+112) | |
1762 | ||
1763 | ||
1764 | this outputs | |
1765 | $5 = 0x528f18 | |
1766 | on my machine. | |
1767 | Now you can use | |
1768 | info symbol (*($sp+56))&0x7fffffff | |
1769 | you might see something like. | |
1770 | rl_getc + 36 in section .text telling you what is located at address 0x528f18 | |
1771 | Now do. | |
1772 | p/x (*(*$sp+56))&0x7fffffff | |
1773 | This outputs | |
1774 | $6 = 0x528ed0 | |
1775 | Now do. | |
1776 | info symbol (*(*$sp+56))&0x7fffffff | |
1777 | rl_read_key + 180 in section .text | |
1778 | now do | |
1779 | p/x (*(**$sp+56))&0x7fffffff | |
1780 | & so on. | |
1781 | ||
1782 | Disassembling instructions without debug info | |
1783 | --------------------------------------------- | |
6c28f2c0 ML |
1784 | gdb typically complains if there is a lack of debugging |
1785 | symbols in the disassemble command with | |
1786 | "No function contains specified address." To get around | |
1da177e4 LT |
1787 | this do |
1788 | x/<number lines to disassemble>xi <address> | |
1789 | e.g. | |
1790 | x/20xi 0x400730 | |
1791 | ||
1792 | ||
1793 | ||
1794 | Note: Remember gdb has history just like bash you don't need to retype the | |
1795 | whole line just use the up & down arrows. | |
1796 | ||
1797 | ||
1798 | ||
1799 | For more info | |
1800 | ------------- | |
1801 | From your linuxbox do | |
1802 | man gdb or info gdb. | |
1803 | ||
1804 | core dumps | |
1805 | ---------- | |
1806 | What a core dump ?, | |
1807 | A core dump is a file generated by the kernel ( if allowed ) which contains the registers, | |
1808 | & all active pages of the program which has crashed. | |
1809 | From this file gdb will allow you to look at the registers & stack trace & memory of the | |
1810 | program as if it just crashed on your system, it is usually called core & created in the | |
1811 | current working directory. | |
1812 | This is very useful in that a customer can mail a core dump to a technical support department | |
1813 | & the technical support department can reconstruct what happened. | |
2254f5a7 | 1814 | Provided they have an identical copy of this program with debugging symbols compiled in & |
1da177e4 LT |
1815 | the source base of this build is available. |
1816 | In short it is far more useful than something like a crash log could ever hope to be. | |
1817 | ||
1818 | In theory all that is missing to restart a core dumped program is a kernel patch which | |
1819 | will do the following. | |
1820 | 1) Make a new kernel task structure | |
1821 | 2) Reload all the dumped pages back into the kernel's memory management structures. | |
1822 | 3) Do the required clock fixups | |
1823 | 4) Get all files & network connections for the process back into an identical state ( really difficult ). | |
1824 | 5) A few more difficult things I haven't thought of. | |
1825 | ||
1826 | ||
1827 | ||
1828 | Why have I never seen one ?. | |
1829 | Probably because you haven't used the command | |
1830 | ulimit -c unlimited in bash | |
1831 | to allow core dumps, now do | |
1832 | ulimit -a | |
1833 | to verify that the limit was accepted. | |
1834 | ||
1835 | A sample core dump | |
1836 | To create this I'm going to do | |
1837 | ulimit -c unlimited | |
1838 | gdb | |
1839 | to launch gdb (my victim app. ) now be bad & do the following from another | |
1840 | telnet/xterm session to the same machine | |
1841 | ps -aux | grep gdb | |
1842 | kill -SIGSEGV <gdb's pid> | |
1843 | or alternatively use killall -SIGSEGV gdb if you have the killall command. | |
1844 | Now look at the core dump. | |
670e9f34 | 1845 | ./gdb core |
1da177e4 LT |
1846 | Displays the following |
1847 | GNU gdb 4.18 | |
1848 | Copyright 1998 Free Software Foundation, Inc. | |
1849 | GDB is free software, covered by the GNU General Public License, and you are | |
1850 | welcome to change it and/or distribute copies of it under certain conditions. | |
1851 | Type "show copying" to see the conditions. | |
1852 | There is absolutely no warranty for GDB. Type "show warranty" for details. | |
1853 | This GDB was configured as "s390-ibm-linux"... | |
1854 | Core was generated by `./gdb'. | |
1855 | Program terminated with signal 11, Segmentation fault. | |
1856 | Reading symbols from /usr/lib/libncurses.so.4...done. | |
1857 | Reading symbols from /lib/libm.so.6...done. | |
1858 | Reading symbols from /lib/libc.so.6...done. | |
1859 | Reading symbols from /lib/ld-linux.so.2...done. | |
1860 | #0 0x40126d1a in read () from /lib/libc.so.6 | |
1861 | Setting up the environment for debugging gdb. | |
1862 | Breakpoint 1 at 0x4dc6f8: file utils.c, line 471. | |
1863 | Breakpoint 2 at 0x4d87a4: file top.c, line 2609. | |
1864 | (top-gdb) info stack | |
1865 | #0 0x40126d1a in read () from /lib/libc.so.6 | |
1866 | #1 0x528f26 in rl_getc (stream=0x7ffffde8) at input.c:402 | |
1867 | #2 0x528ed0 in rl_read_key () at input.c:381 | |
1868 | #3 0x5167e6 in readline_internal_char () at readline.c:454 | |
1869 | #4 0x5168ee in readline_internal_charloop () at readline.c:507 | |
1870 | #5 0x51692c in readline_internal () at readline.c:521 | |
be2a608b | 1871 | #6 0x5164fe in readline (prompt=0x7ffff810 "\177\81ÿ\81øx\177\81ÿ\81÷\81Ø\177\81ÿ\81øx\81À") |
1da177e4 | 1872 | at readline.c:349 |
19f59460 | 1873 | #7 0x4d7a8a in command_line_input (prompt=0x564420 "(gdb) ", repeat=1, |
1da177e4 LT |
1874 | annotation_suffix=0x4d6b44 "prompt") at top.c:2091 |
1875 | #8 0x4d6cf0 in command_loop () at top.c:1345 | |
1876 | #9 0x4e25bc in main (argc=1, argv=0x7ffffdf4) at main.c:635 | |
1877 | ||
1878 | ||
1879 | LDD | |
1880 | === | |
1881 | This is a program which lists the shared libraries which a library needs, | |
1882 | Note you also get the relocations of the shared library text segments which | |
1883 | help when using objdump --source. | |
1884 | e.g. | |
1885 | ldd ./gdb | |
1886 | outputs | |
1887 | libncurses.so.4 => /usr/lib/libncurses.so.4 (0x40018000) | |
1888 | libm.so.6 => /lib/libm.so.6 (0x4005e000) | |
1889 | libc.so.6 => /lib/libc.so.6 (0x40084000) | |
1890 | /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) | |
1891 | ||
1892 | ||
1893 | Debugging shared libraries | |
1894 | ========================== | |
1895 | Most programs use shared libraries, however it can be very painful | |
1896 | when you single step instruction into a function like printf for the | |
1897 | first time & you end up in functions like _dl_runtime_resolve this is | |
1898 | the ld.so doing lazy binding, lazy binding is a concept in ELF where | |
1899 | shared library functions are not loaded into memory unless they are | |
1900 | actually used, great for saving memory but a pain to debug. | |
1901 | To get around this either relink the program -static or exit gdb type | |
1902 | export LD_BIND_NOW=true this will stop lazy binding & restart the gdb'ing | |
1903 | the program in question. | |
1904 | ||
1905 | ||
1906 | ||
1907 | Debugging modules | |
1908 | ================= | |
1909 | As modules are dynamically loaded into the kernel their address can be | |
1910 | anywhere to get around this use the -m option with insmod to emit a load | |
1911 | map which can be piped into a file if required. | |
1912 | ||
1913 | The proc file system | |
1914 | ==================== | |
1915 | What is it ?. | |
1916 | It is a filesystem created by the kernel with files which are created on demand | |
1917 | by the kernel if read, or can be used to modify kernel parameters, | |
1918 | it is a powerful concept. | |
1919 | ||
1920 | e.g. | |
1921 | ||
1922 | cat /proc/sys/net/ipv4/ip_forward | |
1923 | On my machine outputs | |
1924 | 0 | |
1925 | telling me ip_forwarding is not on to switch it on I can do | |
1926 | echo 1 > /proc/sys/net/ipv4/ip_forward | |
1927 | cat it again | |
1928 | cat /proc/sys/net/ipv4/ip_forward | |
1929 | On my machine now outputs | |
1930 | 1 | |
1931 | IP forwarding is on. | |
1932 | There is a lot of useful info in here best found by going in & having a look around, | |
1933 | so I'll take you through some entries I consider important. | |
1934 | ||
f65e51d7 | 1935 | All the processes running on the machine have their own entry defined by |
1da177e4 LT |
1936 | /proc/<pid> |
1937 | So lets have a look at the init process | |
1938 | cd /proc/1 | |
1939 | ||
1940 | cat cmdline | |
1941 | emits | |
1942 | init [2] | |
1943 | ||
1944 | cd /proc/1/fd | |
1945 | This contains numerical entries of all the open files, | |
1946 | some of these you can cat e.g. stdout (2) | |
1947 | ||
1948 | cat /proc/29/maps | |
1949 | on my machine emits | |
1950 | ||
1951 | 00400000-00478000 r-xp 00000000 5f:00 4103 /bin/bash | |
1952 | 00478000-0047e000 rw-p 00077000 5f:00 4103 /bin/bash | |
1953 | 0047e000-00492000 rwxp 00000000 00:00 0 | |
1954 | 40000000-40015000 r-xp 00000000 5f:00 14382 /lib/ld-2.1.2.so | |
1955 | 40015000-40016000 rw-p 00014000 5f:00 14382 /lib/ld-2.1.2.so | |
1956 | 40016000-40017000 rwxp 00000000 00:00 0 | |
1957 | 40017000-40018000 rw-p 00000000 00:00 0 | |
1958 | 40018000-4001b000 r-xp 00000000 5f:00 14435 /lib/libtermcap.so.2.0.8 | |
1959 | 4001b000-4001c000 rw-p 00002000 5f:00 14435 /lib/libtermcap.so.2.0.8 | |
1960 | 4001c000-4010d000 r-xp 00000000 5f:00 14387 /lib/libc-2.1.2.so | |
1961 | 4010d000-40111000 rw-p 000f0000 5f:00 14387 /lib/libc-2.1.2.so | |
1962 | 40111000-40114000 rw-p 00000000 00:00 0 | |
1963 | 40114000-4011e000 r-xp 00000000 5f:00 14408 /lib/libnss_files-2.1.2.so | |
1964 | 4011e000-4011f000 rw-p 00009000 5f:00 14408 /lib/libnss_files-2.1.2.so | |
1965 | 7fffd000-80000000 rwxp ffffe000 00:00 0 | |
1966 | ||
1967 | ||
1968 | Showing us the shared libraries init uses where they are in memory | |
1969 | & memory access permissions for each virtual memory area. | |
1970 | ||
1971 | /proc/1/cwd is a softlink to the current working directory. | |
1972 | /proc/1/root is the root of the filesystem for this process. | |
1973 | ||
1974 | /proc/1/mem is the current running processes memory which you | |
1975 | can read & write to like a file. | |
1976 | strace uses this sometimes as it is a bit faster than the | |
2fe0ae78 | 1977 | rather inefficient ptrace interface for peeking at DATA. |
1da177e4 LT |
1978 | |
1979 | ||
1980 | cat status | |
1981 | ||
1982 | Name: init | |
1983 | State: S (sleeping) | |
1984 | Pid: 1 | |
1985 | PPid: 0 | |
1986 | Uid: 0 0 0 0 | |
1987 | Gid: 0 0 0 0 | |
1988 | Groups: | |
1989 | VmSize: 408 kB | |
1990 | VmLck: 0 kB | |
1991 | VmRSS: 208 kB | |
1992 | VmData: 24 kB | |
1993 | VmStk: 8 kB | |
1994 | VmExe: 368 kB | |
1995 | VmLib: 0 kB | |
1996 | SigPnd: 0000000000000000 | |
1997 | SigBlk: 0000000000000000 | |
1998 | SigIgn: 7fffffffd7f0d8fc | |
1999 | SigCgt: 00000000280b2603 | |
2000 | CapInh: 00000000fffffeff | |
2001 | CapPrm: 00000000ffffffff | |
2002 | CapEff: 00000000fffffeff | |
2003 | ||
2004 | User PSW: 070de000 80414146 | |
2005 | task: 004b6000 tss: 004b62d8 ksp: 004b7ca8 pt_regs: 004b7f68 | |
2006 | User GPRS: | |
2007 | 00000400 00000000 0000000b 7ffffa90 | |
2008 | 00000000 00000000 00000000 0045d9f4 | |
2009 | 0045cafc 7ffffa90 7fffff18 0045cb08 | |
2010 | 00010400 804039e8 80403af8 7ffff8b0 | |
2011 | User ACRS: | |
2012 | 00000000 00000000 00000000 00000000 | |
2013 | 00000001 00000000 00000000 00000000 | |
2014 | 00000000 00000000 00000000 00000000 | |
2015 | 00000000 00000000 00000000 00000000 | |
2016 | Kernel BackChain CallChain BackChain CallChain | |
2017 | 004b7ca8 8002bd0c 004b7d18 8002b92c | |
2018 | 004b7db8 8005cd50 004b7e38 8005d12a | |
2019 | 004b7f08 80019114 | |
2020 | Showing among other things memory usage & status of some signals & | |
2021 | the processes'es registers from the kernel task_structure | |
2022 | as well as a backchain which may be useful if a process crashes | |
2023 | in the kernel for some unknown reason. | |
2024 | ||
2025 | Some driver debugging techniques | |
2026 | ================================ | |
2027 | debug feature | |
2028 | ------------- | |
2029 | Some of our drivers now support a "debug feature" in | |
2030 | /proc/s390dbf see s390dbf.txt in the linux/Documentation directory | |
2031 | for more info. | |
2032 | e.g. | |
2033 | to switch on the lcs "debug feature" | |
2034 | echo 5 > /proc/s390dbf/lcs/level | |
2035 | & then after the error occurred. | |
2036 | cat /proc/s390dbf/lcs/sprintf >/logfile | |
2037 | the logfile now contains some information which may help | |
2038 | tech support resolve a problem in the field. | |
2039 | ||
2040 | ||
2041 | ||
2042 | high level debugging network drivers | |
2043 | ------------------------------------ | |
2044 | ifconfig is a quite useful command | |
2045 | it gives the current state of network drivers. | |
2046 | ||
2047 | If you suspect your network device driver is dead | |
2048 | one way to check is type | |
2049 | ifconfig <network device> | |
2050 | e.g. tr0 | |
2051 | You should see something like | |
2052 | tr0 Link encap:16/4 Mbps Token Ring (New) HWaddr 00:04:AC:20:8E:48 | |
2053 | inet addr:9.164.185.132 Bcast:9.164.191.255 Mask:255.255.224.0 | |
2054 | UP BROADCAST RUNNING MULTICAST MTU:2000 Metric:1 | |
2055 | RX packets:246134 errors:0 dropped:0 overruns:0 frame:0 | |
2056 | TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 | |
2057 | collisions:0 txqueuelen:100 | |
2058 | ||
2059 | if the device doesn't say up | |
2060 | try | |
2061 | /etc/rc.d/init.d/network start | |
2062 | ( this starts the network stack & hopefully calls ifconfig tr0 up ). | |
2063 | ifconfig looks at the output of /proc/net/dev & presents it in a more presentable form | |
2064 | Now ping the device from a machine in the same subnet. | |
2065 | if the RX packets count & TX packets counts don't increment you probably | |
2066 | have problems. | |
2067 | next | |
2068 | cat /proc/net/arp | |
2069 | Do you see any hardware addresses in the cache if not you may have problems. | |
2070 | Next try | |
2071 | ping -c 5 <broadcast_addr> i.e. the Bcast field above in the output of | |
2072 | ifconfig. Do you see any replies from machines other than the local machine | |
2073 | if not you may have problems. also if the TX packets count in ifconfig | |
2074 | hasn't incremented either you have serious problems in your driver | |
2075 | (e.g. the txbusy field of the network device being stuck on ) | |
2076 | or you may have multiple network devices connected. | |
2077 | ||
2078 | ||
2079 | chandev | |
2080 | ------- | |
2081 | There is a new device layer for channel devices, some | |
2082 | drivers e.g. lcs are registered with this layer. | |
2083 | If the device uses the channel device layer you'll be | |
2084 | able to find what interrupts it uses & the current state | |
2085 | of the device. | |
2086 | See the manpage chandev.8 &type cat /proc/chandev for more info. | |
2087 | ||
2088 | ||
2089 | ||
2090 | Starting points for debugging scripting languages etc. | |
2091 | ====================================================== | |
2092 | ||
2093 | bash/sh | |
2094 | ||
2095 | bash -x <scriptname> | |
2096 | e.g. bash -x /usr/bin/bashbug | |
2097 | displays the following lines as it executes them. | |
2098 | + MACHINE=i586 | |
2099 | + OS=linux-gnu | |
2100 | + CC=gcc | |
2101 | + CFLAGS= -DPROGRAM='bash' -DHOSTTYPE='i586' -DOSTYPE='linux-gnu' -DMACHTYPE='i586-pc-linux-gnu' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./lib -O2 -pipe | |
2102 | + RELEASE=2.01 | |
2103 | + PATCHLEVEL=1 | |
2104 | + RELSTATUS=release | |
2105 | + MACHTYPE=i586-pc-linux-gnu | |
2106 | ||
2fe0ae78 | 2107 | perl -d <scriptname> runs the perlscript in a fully interactive debugger |
1da177e4 LT |
2108 | <like gdb>. |
2109 | Type 'h' in the debugger for help. | |
2110 | ||
2111 | for debugging java type | |
2112 | jdb <filename> another fully interactive gdb style debugger. | |
2113 | & type ? in the debugger for help. | |
2114 | ||
2115 | ||
2116 | ||
1da177e4 LT |
2117 | SysRq |
2118 | ===== | |
2119 | This is now supported by linux for s/390 & z/Architecture. | |
2120 | To enable it do compile the kernel with | |
2121 | Kernel Hacking -> Magic SysRq Key Enabled | |
2122 | echo "1" > /proc/sys/kernel/sysrq | |
2123 | also type | |
2124 | echo "8" >/proc/sys/kernel/printk | |
2125 | To make printk output go to console. | |
2126 | On 390 all commands are prefixed with | |
2127 | ^- | |
2128 | e.g. | |
2129 | ^-t will show tasks. | |
2130 | ^-? or some unknown command will display help. | |
2131 | The sysrq key reading is very picky ( I have to type the keys in an | |
2132 | xterm session & paste them into the x3270 console ) | |
2133 | & it may be wise to predefine the keys as described in the VM hints above | |
2134 | ||
2135 | This is particularly useful for syncing disks unmounting & rebooting | |
2136 | if the machine gets partially hung. | |
2137 | ||
2138 | Read Documentation/sysrq.txt for more info | |
2139 | ||
2140 | References: | |
2141 | =========== | |
2142 | Enterprise Systems Architecture Reference Summary | |
2143 | Enterprise Systems Architecture Principles of Operation | |
2144 | Hartmut Penners s390 stack frame sheet. | |
2145 | IBM Mainframe Channel Attachment a technology brief from a CISCO webpage | |
2146 | Various bits of man & info pages of Linux. | |
2147 | Linux & GDB source. | |
2148 | Various info & man pages. | |
2149 | CMS Help on tracing commands. | |
2150 | Linux for s/390 Elf Application Binary Interface | |
2151 | Linux for z/Series Elf Application Binary Interface ( Both Highly Recommended ) | |
2152 | z/Architecture Principles of Operation SA22-7832-00 | |
2153 | Enterprise Systems Architecture/390 Reference Summary SA22-7209-01 & the | |
2154 | Enterprise Systems Architecture/390 Principles of Operation SA22-7201-05 | |
2155 | ||
2156 | Special Thanks | |
2157 | ============== | |
2158 | Special thanks to Neale Ferguson who maintains a much | |
2159 | prettier HTML version of this page at | |
0ea6e611 | 2160 | http://linuxvm.org/penguinvm/ |
1da177e4 | 2161 | Bob Grainger Stefan Bader & others for reporting bugs |