This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/16596] Support DW_OP_GNU_entry_value in location expressions
- From: "mjw at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Thu, 13 Mar 2014 17:13:57 +0000
- Subject: [Bug translator/16596] Support DW_OP_GNU_entry_value in location expressions
- Auto-submitted: auto-generated
- References: <bug-16596-6586 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16596
--- Comment #3 from Mark Wielaard <mjw at redhat dot com> ---
OK, with extra -vv we see:
focused on module 'kernel'
selected source file 'mm/memory.c'
selected inline instance of __handle_mm_fault
entry-pc lookup (dwarf_entrypc dieoffset: 0x170f191) = 0xffffffff811e11a9 (rc
0)
querying entrypc 0xffffffff811e11a9 of instance of inline '__handle_mm_fault'
probe __handle_mm_fault@mm/memory.c:3696 kernel reloc=.dynamic
pc=0xffffffff811e11a9
finding location for local 'flags' near address 0xffffffff811e11a9, module bias
0
get_cfa_ops @0xffffffff811e11a9, module_start @0xffffffff81000000
found cfa, info: 16 [start: 0xffffffff811e112b, end: 0xffffffff811e153a, nops:
1
[170f191] inlined_subroutine
abstract_origin (ref4) [170ee49]
entry_pc (addr) 0xffffffff811e11a9
ranges (sec_offset) range list [112810]
call_file (data1) 4
call_line (data2) 3799
sibling (ref4) [1711432]
[170f1a9] formal_parameter
abstract_origin (ref4) [170ee7d]
location (sec_offset) location list [5dac88]
[170f1b2] formal_parameter
abstract_origin (ref4) [170ee71]
location (sec_offset) location list [5dacf0]
[170f1bb] formal_parameter
abstract_origin (ref4) [170ee65]
location (sec_offset) location list [5dae6e]
[170f1c4] formal_parameter
abstract_origin (ref4) [170ee5a]
location (sec_offset) location list [5dafd6]
The abstract origin of this inlined_subroutine is (as expected):
[170ee49] subprogram
name (strp) "__handle_mm_fault"
decl_file (data1) 4
decl_line (data2) 3696
prototyped (flag_present) Yes
type (ref4) [16f3cb4]
inline (data1) inlined (1)
And the first formal_parameter [170f1a9] origin is flags:
[170ee7d] formal_parameter
name (strp) "flags"
decl_file (data1) 4
decl_line (data2) 3697
type (ref4) [16f3cc6]
Which can be found through location list [5dac88]:
[5dac88] 0xffffffff811e11a9..0xffffffff811e1544 [ 0] GNU_entry_value:
[ 0] reg2
[ 3] stack_value
0xffffffff811e1573..0xffffffff811e1e7c [ 0] GNU_entry_value:
[ 0] reg2
[ 3] stack_value
0xffffffff811e1e95..0xffffffff811e1fbe [ 0] GNU_entry_value:
[ 0] reg2
[ 3] stack_value
0xffffffff811e1fdc..0xffffffff811e205f [ 0] GNU_entry_value:
[ 0] reg2
[ 3] stack_value
And the pc (ffffffff811e11a9) we are interested in the first range, which (like
all other ranges) indeed tells us the value can be recovered through the value
of reg2 as it was on entry of the subprogram (where this was inlined). Which
is:
[170eff4] subprogram
external (flag_present) Yes
name (strp) "handle_mm_fault"
decl_file (data1) 4
decl_line (data2) 3779
prototyped (flag_present) Yes
type (ref4) [16f3cb4]
low_pc (addr) 0xffffffff811e1110
high_pc (data8) 3919 (0xffffffff811e205f)
frame_base (exprloc)
[ 0] call_frame_cfa
GNU_all_call_sites (flag_present) Yes
So if we look at the source and disassambly:
int handle_mm_fault(struct mm_struct *mm, struct vm_area_struct *vma,
unsigned long address, unsigned int flags)
{
int ret;
__set_current_state(TASK_RUNNING);
count_vm_event(PGFAULT);
mem_cgroup_count_vm_event(mm, PGFAULT);
/* do counter updates before entering really critical section. */
check_sync_rss_stat(current);
/*
* Enable the memcg OOM handling for faults triggered in user
* space. Kernel faults are handled more gracefully.
*/
if (flags & FAULT_FLAG_USER)
mem_cgroup_oom_enable();
ret = __handle_mm_fault(mm, vma, address, flags); // <= THIS INLINE
if (flags & FAULT_FLAG_USER) {
mem_cgroup_oom_disable();
/*
* The task may have entered a memcg OOM situation but
* if the allocation error was handled gracefully (no
* VM_FAULT_OOM), there is no need to kill anything.
* Just clean up the OOM state peacefully.
*/
if (task_in_memcg_oom(current) && !(ret & VM_FAULT_OOM))
mem_cgroup_oom_synchronize(false);
}
return ret;
}
ffffffff811e1110 <handle_mm_fault>:
handle_mm_fault():
/usr/src/debug/kernel-3.13.fc21/linux-3.14.0-0.rc5.git2.1.fc21.x86_64/mm/memory.c:3781
ffffffff811e1110: e8 2b 44 60 00 callq ffffffff817e5540
<__entry_text_start>
ffffffff811e1115: 55 push %rbp
ffffffff811e1116: 41 89 c9 mov %ecx,%r9d
ffffffff811e1119: 48 89 e5 mov %rsp,%rbp
ffffffff811e111c: 41 57 push %r15
ffffffff811e111e: 41 56 push %r14
ffffffff811e1120: 49 89 fe mov %rdi,%r14
ffffffff811e1123: 41 55 push %r13
ffffffff811e1125: 49 89 f5 mov %rsi,%r13
ffffffff811e1128: 41 54 push %r12
ffffffff811e112a: 53 push %rbx
ffffffff811e112b: 48 89 d3 mov %rdx,%rbx
ffffffff811e112e: 48 83 ec 70 sub $0x70,%rsp
ffffffff811e1132: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax
ffffffff811e1139: 00 00
ffffffff811e113b: 48 89 45 d0 mov %rax,-0x30(%rbp)
ffffffff811e113f: 31 c0 xor %eax,%eax
get_current():
/usr/src/debug/kernel-3.13.fc21/linux-3.14.0-0.rc5.git2.1.fc21.x86_64/arch/x86/include/asm/current.h:14
ffffffff811e1141: 65 48 8b 04 25 80 c9 mov %gs:0xc980,%rax
ffffffff811e1148: 00 00
handle_mm_fault():
/usr/src/debug/kernel-3.13.fc21/linux-3.14.0-0.rc5.git2.1.fc21.x86_64/mm/memory.c:3784
ffffffff811e114a: 48 c7 00 00 00 00 00 movq $0x0,(%rax)
mem_cgroup_disabled():
/usr/src/debug/kernel-3.13.fc21/linux-3.14.0-0.rc5.git2.1.fc21.x86_64/include/linux/memcontrol.h:165
ffffffff811e1151: 8b 3d dd a6 ba 00 mov 0xbaa6dd(%rip),%edi
# ffffffff81d8b834 <mem_cgroup_subsys+0x54>
count_vm_event():
/usr/src/debug/kernel-3.13.fc21/linux-3.14.0-0.rc5.git2.1.fc21.x86_64/include/linux/vmstat.h:37
ffffffff811e1157: 65 48 ff 04 25 58 0e incq %gs:0x1d0e58
ffffffff811e115e: 1d 00
mem_cgroup_disabled():
/usr/src/debug/kernel-3.13.fc21/linux-3.14.0-0.rc5.git2.1.fc21.x86_64/include/linux/memcontrol.h:165
ffffffff811e1160: 85 ff test %edi,%edi
ffffffff811e1162: 75 14 jne ffffffff811e1178
<handle_mm_fault+0x68>
mem_cgroup_count_vm_event():
/usr/src/debug/kernel-3.13.fc21/linux-3.14.0-0.rc5.git2.1.fc21.x86_64/include/linux/memcontrol.h:224
ffffffff811e1164: be 0b 00 00 00 mov $0xb,%esi
ffffffff811e1169: 4c 89 f7 mov %r14,%rdi
ffffffff811e116c: 89 4d c0 mov %ecx,-0x40(%rbp)
ffffffff811e116f: e8 2c e6 03 00 callq ffffffff8121f7a0
<__mem_cgroup_count_vm_event>
ffffffff811e1174: 44 8b 4d c0 mov -0x40(%rbp),%r9d
get_current():
/usr/src/debug/kernel-3.13.fc21/linux-3.14.0-0.rc5.git2.1.fc21.x86_64/arch/x86/include/asm/current.h:14
ffffffff811e1178: 65 48 8b 04 25 80 c9 mov %gs:0xc980,%rax
ffffffff811e117f: 00 00
check_sync_rss_stat():
/usr/src/debug/kernel-3.13.fc21/linux-3.14.0-0.rc5.git2.1.fc21.x86_64/mm/memory.c:164
ffffffff811e1181: 8b 90 a8 06 00 00 mov 0x6a8(%rax),%edx
ffffffff811e1187: 8d 4a 01 lea 0x1(%rdx),%ecx
ffffffff811e118a: 83 fa 40 cmp $0x40,%edx
ffffffff811e118d: 89 88 a8 06 00 00 mov %ecx,0x6a8(%rax)
ffffffff811e1193: 0f 8f e3 0c 00 00 jg ffffffff811e1e7c
<handle_mm_fault+0xd6c>
handle_mm_fault():
/usr/src/debug/kernel-3.13.fc21/linux-3.14.0-0.rc5.git2.1.fc21.x86_64/mm/memory.c:3796
ffffffff811e1199: 45 89 cf mov %r9d,%r15d
ffffffff811e119c: 41 81 e7 80 00 00 00 and $0x80,%r15d
ffffffff811e11a3: 0f 85 9f 03 00 00 jne ffffffff811e1548
<handle_mm_fault+0x438>
__handle_mm_fault():
/usr/src/debug/kernel-3.13.fc21/linux-3.14.0-0.rc5.git2.1.fc21.x86_64/mm/memory.c:3704
ffffffff811e11a9: 41 f6 45 52 40 testb $0x40,0x52(%r13)
ffffffff811e11ae: 0f 85 af 0c 00 00 jne ffffffff811e1e63
<handle_mm_fault+0xd53>
/usr/src/debug/kernel-3.13.fc21/linux-3.14.0-0.rc5.git2.1.fc21.x86_64/mm/memory.c:3707
ffffffff811e11b4: 49 89 dc mov %rbx,%r12
ffffffff811e11b7: 49 c1 ec 24 shr $0x24,%r12
ffffffff811e11bb: 41 81 e4 f8 0f 00 00 and $0xff8,%r12d
ffffffff811e11c2: 4d 03 66 40 add 0x40(%r14),%r12
ffffffff811e11c6: 49 8b 04 24 mov (%r12),%rax
So between the start of the function ffffffff811e1110 and the first inlined
address ffffffff811e11a9 a lot happens that probably clobbers reg2/rcx, which
makes it non-trivial to retrieve. It does look like the value of flags is used
later so maybe GCC could provide its value differently, but I am not sure.
--
You are receiving this mail because:
You are the assignee for the bug.