debugging390.txt

嵌入式系统设计与实例开发实验教材二源码 多线程应用程序设计 串行端口程序设计 AD接口实验 CAN总线通信实验 GPS通信实验 Linux内核移植与编译实验 IC卡读写实验 SD驱动使

grep task /proc/<pid>/status
from this you should see something like
task: 0f160000 ksp: 0f161de8 pt_regs: 0f161f68
This now gives you a pointer to the task structure.
Now make CC:="s390-gcc -g" kernel/sched.s
To get the task_struct stabinfo.
( task_struct is defined in include/linux/sched.h ).
Now we want to look at
task->active_mm->pgd
on my machine the active_mm in the task structure stab is
active_mm:(4,12),672,32
its offset is 672/8=84=0x54
the pgd member in the mm_struct stab is
pgd:(4,6)=*(29,5),96,32
so its offset is 96/8=12=0xc

so we'll
hexdump -s 0xf160054 /dev/mem | more
i.e. task_struct+active_mm offset
to look at the active_mm member
f160054 0fee cc60 0019 e334 0000 0000 0000 0011
hexdump -s 0x0feecc6c /dev/mem | more
i.e. active_mm+pgd offset
feecc6c 0f2c 0000 0000 0001 0000 0001 0000 0010
we get something like
now do 
TR I R STD <pgd|0x7f> 0.7fffffff
i.e. the 0x7f is added because the pgd only
gives the page table origin & we need to set the low bits
to the maximum possible segment table length.
TR I R STD 0f2c007f 0.7fffffff
on z/Architecture you'll probably need to do
TR I R STD <pgd|0x7> 0.ffffffffffffffff
to set the TableType to 0x1 & the Table length to 3.



Tracing Program Exceptions
--------------------------
If you get a crash which says something like
illegal operation or specification exception followed by a register dump
You can restart linux & trace these using the tr prog <range or value> trace option.



The most common ones you will normally be tracing for is
1=operation exception
2=privileged operation exception
4=protection exception
5=addressing exception
6=specification exception
10=segment translation exception
11=page translation exception

The full list of these is on page 22 of the current s/390 Reference Summary.
e.g.
tr prog 10 will trace segment translation exceptions.
tr prog on its own will trace all program interruption codes.

Trace Sets
----------
On starting VM you are initially in the INITIAL trace set.
You can do a Q TR to verify this.
If you have a complex tracing situation where you wish to wait for instance 
till a driver is open before you start tracing IO, but know in your
heart that you are going to have to make several runs through the code till you
have a clue whats going on. 

What you can do is
TR I PSWA <Driver open address>
hit b to continue till breakpoint
reach the breakpoint
now do your
TR GOTO B 
TR IO 7c08-7c09 inst int run 
or whatever the IO channels you wish to trace are & hit b

To got back to the initial trace set do
TR GOTO INITIAL
& the TR I PSWA <Driver open address> will be the only active breakpoint again.


Tracing linux syscalls under VM
-------------------------------
Syscalls are implemented on Linux for S390 by the Supervisor call instruction (SVC) there 256 
possibilities of these as the instruction is made up of a  0xA opcode & the second byte being
the syscall number. They are traced using the simple command.
TR SVC  <Optional value or range>
the syscalls are defined in linux/include/asm-s390/unistd.h
e.g. to trace all file opens just do
TR SVC 5 ( as this is the syscall number of open )


SMP Specific commands
---------------------
To find out how many cpus you have
Q CPUS displays all the CPU's available to your virtual machine
To find the cpu that the current cpu VM debugger commands are being directed at do
Q CPU to change the current cpu cpu VM debugger commands are being directed at do
CPU <desired cpu no>

On a SMP guest issue a command to all CPUs try prefixing the command with cpu all.
To issue a command to a particular cpu try cpu <cpu number> e.g.
CPU 01 TR I R 2000.3000
If you are running on a guest with several cpus & you have a IO related problem
& cannot follow the flow of code but you know it isnt smp related.
from the bash prompt issue
shutdown -h now or halt.
do a Q CPUS to find out how many cpus you have
detach each one of them from cp except cpu 0 
by issueing a 
DETACH CPU 01-(number of cpus in configuration)
& boot linux again.
TR SIGP will trace inter processor signal processor instructions.
DEFINE CPU 01-(number in configuration) 
will get your guests cpus back.


Help for displaying ascii textstrings
-------------------------------------
On the very latest VM Nucleus'es VM can now display ascii
( thanks Neale for the hint ) by doing
D TX<lowaddr>.<len>
e.g.
D TX0.100

Alternatively
=============
Under older VM debuggers ( I love EBDIC too ) you can use this little program I wrote which
will convert a command line of hex digits to ascii text which can be compiled under linux & 
you can copy the hex digits from your x3270 terminal to your xterm if you are debugging
from a linuxbox.

This is quite useful when looking at a parameter passed in as a text string
under VM ( unless you are good at decoding ASCII in your head ).

e.g. consider tracing an open syscall
TR SVC 5
We have stopped at a breakpoint
000151B0' SVC   0A05     -> 0001909A'   CC 0

D 20.8 to check the SVC old psw in the prefix area & see was it from userspace
( for the layout of the prefix area consult P18 of the s/390 390 Reference Summary 
if you have it available ).
V00000020  070C2000 800151B2
The problem state bit wasn't set &  it's also too early in the boot sequence
for it to be a userspace SVC if it was we would have to temporarily switch the 
psw to user space addressing so we could get at the first parameter of the open in
gpr2.
Next do a 
D G2
GPR  2 =  00014CB4
Now display what gpr2 is pointing to
D 00014CB4.20
V00014CB4  2F646576 2F636F6E 736F6C65 00001BF5
V00014CC4  FC00014C B4001001 E0001000 B8070707
Now copy the text till the first 00 hex ( which is the end of the string
to an xterm & do hex2ascii on it.
hex2ascii 2F646576 2F636F6E 736F6C65 00 
outputs
Decoded Hex:=/ d e v / c o n s o l e 0x00 
We were opening the console device,

You can compile the code below yourself for practice :-),
/*
 *    hex2ascii.c
 *    a useful little tool for converting a hexadecimal command line to ascii
 *
 *    Author(s): Denis Joseph Barrow ([e-mail],[e-mail])
 *    (C) 2000 IBM Deutschland Entwicklung GmbH, IBM Corporation.
 */   
#include <stdio.h>

int main(int argc,char *argv[])
{
  int cnt1,cnt2,len,toggle=0;
  int startcnt=1;
  unsigned char c,hex;
  
  if(argc>1&&(strcmp(argv[1],"-a")==0))
     startcnt=2;
  printf("Decoded Hex:=");
  for(cnt1=startcnt;cnt1<argc;cnt1++)
  {
    len=strlen(argv[cnt1]);
    for(cnt2=0;cnt2<len;cnt2++)
    {
       c=argv[cnt1][cnt2];
       if(c>='0'&&c<='9')
	  c=c-'0';
       if(c>='A'&&c<='F')
	  c=c-'A'+10;
       if(c>='a'&&c<='F')
	  c=c-'a'+10;
       switch(toggle)
       {
	  case 0:
	     hex=c<<4;
	     toggle=1;
	  break;
	  case 1:
	     hex+=c;
	     if(hex<32||hex>127)
	     {
		if(startcnt==1)
		   printf("0x%02X ",(int)hex);
		else
		   printf(".");
	     }
	     else
	     {
	       printf("%c",hex);
	       if(startcnt==1)
		  printf(" ");
	     }
	     toggle=0;
	  break;
       }
    }
  }
  printf("\n");
}




Stack tracing under VM
----------------------
A basic backtrace
-----------------

Here are the tricks I use 9 out of 10 times it works pretty well,

When your backchain reaches a dead end
--------------------------------------
This can happen when an exception happens in the kernel & the kernel is entered twice
if you reach the NULL pointer at the end of the back chain you should be
able to sniff further back if you follow the following tricks.
1) A kernel address should be easy to recognise since it is in
primary space & the problem state bit isn't set & also
The Hi bit of the address is set.
2) Another backchain should also be easy to recognise since it is an 
address pointing to another address approximately 100 bytes or 0x70 hex
behind the current stackpointer.


Here is some practice.
boot the kernel & hit PA1 at some random time
d g to display the gprs, this should display something like
GPR  0 =  00000001  00156018  0014359C  00000000
GPR  4 =  00000001  001B8888  000003E0  00000000
GPR  8 =  00100080  00100084  00000000  000FE000
GPR 12 =  00010400  8001B2DC  8001B36A  000FFED8
Note that GPR14 is a return address but as we are real men we are going to
trace the stack.
display 0x40 bytes after the stack pointer.

V000FFED8  000FFF38 8001B838 80014C8E 000FFF38
V000FFEE8  00000000 00000000 000003E0 00000000
V000FFEF8  00100080 00100084 00000000 000FE000
V000FFF08  00010400 8001B2DC 8001B36A 000FFED8


Ah now look at whats in sp+56 (sp+0x38) this is 8001B36A our saved r14 if
you look above at our stackframe & also agrees with GPR14.

now backchain 
d 000FFF38.40
we now are taking the contents of SP to get our first backchain.

V000FFF38  000FFFA0 00000000 00014995 00147094
V000FFF48  00147090 001470A0 000003E0 00000000
V000FFF58  00100080 00100084 00000000 001BF1D0
V000FFF68  00010400 800149BA 80014CA6 000FFF38

This displays a 2nd return address of 80014CA6

now do d 000FFFA0.40 for our 3rd backchain

V000FFFA0  04B52002 0001107F 00000000 00000000
V000FFFB0  00000000 00000000 FF000000 0001107F
V000FFFC0  00000000 00000000 00000000 00000000
V000FFFD0  00010400 80010802 8001085A 000FFFA0


our 3rd return address is 8001085A

as the 04B52002 looks suspiciously like rubbish it is fair to assume that the kernel entry routines
for the sake of optimisation dont set up a backchain.

now look at System.map to see if the addresses make any sense.

grep -i 0001b3 System.map
outputs among other things
0001b304 T cpu_idle 
so 8001B36A
is cpu_idle+0x66 ( quiet the cpu is asleep, don't wake it )


grep -i 00014 System.map 
produces among other things
00014a78 T start_kernel  
so 0014CA6 is start_kernel+some hex number I can't add in my head.

grep -i 00108 System.map 
this produces
00010800 T _stext
so   8001085A is _stext+0x5a

Congrats you've done your first backchain.



s/390 & z/Architecture IO Overview
==================================

I am not going to give a course in 390 IO architecture as this would take me quite a
while & I'm no expert. Instead I'll give a 390 IO architecture summary for Dummies if you have 
the s/390 principles of operation available read this instead. If nothing else you may find a few 
useful keywords in here & be able to use them on a web search engine like altavista to find 
more useful information.

Unlike other bus architectures modern 390 systems do their IO using mostly
fibre optics & devices such as tapes & disks can be shared between several mainframes,
also S390 can support upto 65536 devices while a high end PC based system might be choking 
with around 64. Here is some of the c