This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fedora rawhide problems with kprobes/debuginfo addresses


On Sat, Mar 03, 2007 at 03:50:20PM -0800, Roland McGrath wrote:
> > Not very sure exactly what information you are looking for. But I am
> > assuming you are looking for run time virtual and physical address of the
> > kernel.
> 
> The virtual address, yes.  The physical address is not especially helpful
> unless I know how to convert it to a kernel virtual address (in userland).
> The lower and upper bounds are nice to have, as well as just the offset.
> 
> > For virtual address you can grab _text or _stext. 
> 
> This is essentially what I'm doing with:
> 
> awk 'NF > 3 { print a; exit 0 } { a=$1 } NR==1 { print a }' /proc/kallsyms 
> 
> > Alternatively you can parse /proc/kcore and look for ELF header where
> > kernel is mapped.
> 
> Sorry, I don't follow what you are suggesting here.  (Also, /proc/kcore is
> privileged which is a new inconvenience we don't want.)  In kcore I find
> out where all the memory is in virtual addresses, but I don't see how that
> tells me what part of it is the kernel image.
> 

Kernel text is mapped in a separate ELF program header and we can walk
through all the ELF program headers to find out where kernel is mapped. 
For ex, for x86_64 we know kernel will be mapped somewhere between
(__START_KERNEL_map) and (__START_KERNEL_map + KERNEL_TEXT_SIZE).

On one of my machines this is how "readelf -a /proc/kcore" looks like.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  NOTE           0x0000000000000190 0x0000000000000000 0x0000000000000000
                 0x0000000000000904 0x0000000000000000         0
  LOAD           0x0000ffffff601000 0xffffffffff600000 0x0000000000000000
                 0x0000000000800000 0x0000000000800000  RWE    1000
  LOAD           0x0000ffff88001000 0xffffffff88000000 0x0000000000000000
                 0x0000000077f00000 0x0000000077f00000  RWE    1000
  LOAD           0x0000ffff80201f20 0xffffffff80200f20 0x0000000000000000
				     ^^^^^ (Kernel Text)

                 0x00000000006b63e8 0x00000000006b63e8  RWE    1000
  LOAD           0x0000c20000001000 0xffffc20000000000 0x0000000000000000
                 0x00001fffffffffff 0x00001fffffffffff  RWE    1000
  LOAD           0x0000810000001000 0xffff810000000000 0x0000000000000000
                 0x0000000120000000 0x0000000120000000  RWE    1000


Looking at the virtual addresses, one can tell that third PT_LOAD prgram
header is mapping kernel text. 

> > Dave Anderson is already parsing /proc/kcore for determining kernel
> > virtual address in "crash" for x86_64  
> 
> I didn't find any code in crash-4.0 that looks at /proc/kcore.
> 

Sorry, It is kexec-tools which parses /proc/kcore. crash is just parsing
/proc/vmcore and looks at ELF headers to find out where kernel is mapped.

You can find latest kexec-tools at.

http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing.tar.gz

or

git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools-testing.git

or

http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools-testing.git;a=summary

You can have a look at kexec/arch/x86_64/crashdump-x86_64.c

Thanks
Vivek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]