On 14 July 2016 at 05:16, Al Grant Al.Grant@arm.com wrote:
On ARM64 (because I _assume_ X86 folks didn't see this) we get 3 notifications. For example notification A will have address 0x7f93a60000 while, subsequently, notification B and C address 0x7f93a70000. Note that the latter two are 64K higher than the first one.
Once the last notification has been received the code in the main program is executed. That code (in the main program) jumps to library code mapped at the address it got from the first notification and not the last one, making the filter configuration all wrong.
As such I have to understand what notification B and C are for. Based on the vm_area_struct::vm_flags I'm guessing some sort of accounting feature but not sure yet.
Code and data segment(s)? They will be mapped in separately with separate permissions. If you look at /proc/self/maps or /proc/<pid>/maps you will see 2 or 3 entries per library, depending on system.
vm_pgoff will indicate the file offset within the ELF file. This will tend to be zero for the main code segment and non-zero for data segment(s).
vm_flags will indicate the segment permissions. You would normally get at least one without VM_WRITE and at least one with VM_WRITE. You might get R+X, R+W+X, R+W, just R etc.
Something worth knowing here is that you're more likely to see VM_EXEC on data sections on ARM64 than on X86_64, because the READ_MEANS_EXEC personality bit is inherited in the process tree on ARM64 and not X86_64. At worst, if your init process has an executable stack then practically every data segment mapping in the system gets VM_EXEC! You can't assume that you will only get one VM_EXEC mapping and that it will be "the" main code section; or act as if this was true by treating your last VM_EXEC notification as the code section. If you want to pick a single code section then use the one with vm_pgoff set to zero.
Again this is shows up in /proc/xxx/maps - if you see 'x's on writeable data segments and even on non executable files like /usr/lib/locale/locale-archive, then you've got sticky VM_EXEC. It's a bug really, I keep meaning to write a patch for this.
Could you dump out what you're seeing, complete with vm_flags and vm_pgoff, and also /proc/pid/maps? Hopefully things will then be clear.
That is very helpful, thanks for taking the time to write all this. Ok, I'll mofidy the example code (that I will also send) to execute for a little while - that way I can probe /proc/xyz/maps and correlate what's found there with the mapped addresses I get from the mm subsystem.
But it might not be today (I'll try really hard). The perf user space code no longer builds on the offical perf tree and I need to fix it right away.
Mathieu
Al
If I ignore notification B and C, things work amazingly well and one can really see the power offered by coresight.
That's where I'm at now.
Get back to me if you (or anyone else) want more information.
Mathieu
Al IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.