[ltt-dev] Question about instruction pointer and address attributes

[ltt-dev] Question about instruction pointer and address attributes

[Francis Giraldeau]

Hi,

I want to relate trace events to source code. For testing, I did a  
small C program that does a file access. In the event  
kernel.syscall_entry sys_access, I got the instruction pointer  
ip=0x7fa4fba26ee7. I dumped the process memory map from  
/proc/$PID/maps, and this address doesn't fit in the process memory  
space. It's somewhat close to libc addresses, that are in the range of  
0x7f6471f56000-0x7f64724fc000.

Another example, inside a TRAP, I got two addresses,  
ip=0xffffffff812c722b and address=0x7fa4fba2cbc0, those two addresses  
doesn't map in the process space.

First, what is the difference between ip and address attribute? And  
wow does the ip can be converted back to the process address space?

Cheer,

Francis

[ltt-dev] Question about instruction pointer and address attributes

[Mathieu Desnoyers]

* Francis Giraldeau (Francis.Giraldeau at USherbrooke.ca) wrote:
> Hi,
>
> I want to relate trace events to source code. For testing, I did a small 
> C program that does a file access. In the event kernel.syscall_entry 
> sys_access, I got the instruction pointer ip=0x7fa4fba26ee7. I dumped the 
> process memory map from /proc/$PID/maps, and this address doesn't fit in 
> the process memory space. It's somewhat close to libc addresses, that are 
> in the range of 0x7f6471f56000-0x7f64724fc000.
>
> Another example, inside a TRAP, I got two addresses,  
> ip=0xffffffff812c722b

This looks like the vDSO.

 and address=0x7fa4fba2cbc0, those two addresses  
> doesn't map in the process space.
>
> First, what is the difference between ip and address attribute? And wow 
> does the ip can be converted back to the process address space?

Make sure you cat the /proc/$PID/maps from the exact same process you
gather the trace from, because the addresses at which the libraries are
loaded and the stack is located are randomised between executions.

Cheers,

Mathieu

>
> Cheer,
>
> Francis
>
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

[ltt-dev] Question about instruction pointer and address attributes

[Michel Dagenais]

> In the event  
> kernel.syscall_entry sys_access, I got the instruction pointer  
> ip=0x7fa4fba26ee7. I dumped the process memory map from  
> /proc/$PID/maps, and this address doesn't fit in the process memory  
> space. It's somewhat close to libc addresses, that are in the range of

That makes sense, most system calls first go through libc.

> Another example, inside a TRAP, I got two addresses,  
> ip=0xffffffff812c722b and address=0x7fa4fba2cbc0, those two addresses 

> First, what is the difference between ip and address attribute? And  
> wow does the ip can be converted back to the process address space?

The ip is probably in the kernel space. The address could be the data access address causing a trap.

[ltt-dev] Question about instruction pointer and address attributes

[Francis Giraldeau]

> > > I want to relate trace events to source code. For testing, I did a small 
> > > C program that does a file access. In the event kernel.syscall_entry 
> > > sys_access, I got the instruction pointer ip=0x7fa4fba26ee7. I dumped the 
> > > process memory map from /proc/$PID/maps, and this address doesn't fit in 
> > > the process memory space. It's somewhat close to libc addresses, that are 
> > > in the range of 0x7f6471f56000-0x7f64724fc000.
> > 
> > Make sure you cat the /proc/$PID/maps from the exact same process you
> > gather the trace from, because the addresses at which the libraries are
> > loaded and the stack is located are randomised between executions.
> > 

That was the problem. Inside the C program, I dumped the process memory
map on disk and it matches the events ip field. Once the random offset
removed from ip in syscall event, it matches exactly the address in libc
objdump. 

Thanks for this info! 

Francis