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