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: semantic error: not accessible at this address


 â 28 septembre 2013 02:02 CEST, "Frank Ch. Eigler" <fche@redhat.com>Â:

>> > The -mfentry-compensation code should cause you to be seeing some
>> > messages like this:
>> >
>> > retrying variable location-list lookup at address pc+5
>> 
>> OK
>
> Yup, the entry below confirms it:
>
>
>> >> [...]
>>     005ec5ff ffffffff811b42b5 ffffffff811b42eb (DW_OP_reg5 (rdi))
>>     005ec5ff ffffffff811b42eb ffffffff811b43e8 (DW_OP_reg3 (rbx))
>>     005ec5ff ffffffff811b43fa ffffffff811b44a9 (DW_OP_reg3 (rbx))
>>     005ec5ff <End of list>
>
> Your vfs_write starts at 0xffffffff811b42b0, and "file" comes into scope
> five bytes later.  This is the PR15123 scenario.  Does your environment
> by any chance include $PR15123_DISABLE?  If so, unset that.  If not,
> maybe it's time to debug dwflpp.cxx:translate_location, line 2411-ish.

I don't hit this location. Should I hit it with "stap --vp 03 -L
'kernel.function("vfs_write")'"?

I have set the breakpoint to dwflpp::pr15123_retry_addr instead. I get
this:

(gdb) continue
Continuing.

Breakpoint 2, dwflpp::pr15123_retry_addr (this=0x206c880, pc=18446744071580631728, die=0x7fffffffa6c0) at dwflpp.cxx:3756
3756    {
(gdb) n
3773      if (getenv ("PR15123_DISABLE"))
(gdb) 
3756    {
(gdb) 
3774        return 0;
(gdb) 
3773      if (getenv ("PR15123_DISABLE"))
(gdb) 
3778      dwarf_diecu (die, &cudie, NULL, NULL);
(gdb) 
3779      if (! dwarf_attr_integrate(&cudie, DW_AT_producer, &cudie_producer))
(gdb) 
3782      const char* producer = dwarf_formstring(&cudie_producer);
(gdb) 
3783      if (!producer)
(gdb) 
3785      if (! strstr(producer, "-mfentry"))
(gdb) print producer
$1 = 0x7fffee850aaa "GNU C 4.6.3"
(gdb) n
3812    }
(gdb) 
dwarf_derived_probe::saveargs (this=0x434f210, q=..., scope_die=<optimized out>, dwfl_addr=18446744071580631728) at tapsets.cxx:4701
4701                        if (!dwfl_addr2 || (!(dwarf_getlocation_addr(&attr_mem, dwfl_addr2, &expr,
(gdb) bt
#0  dwarf_derived_probe::saveargs (this=0x434f210, q=..., scope_die=<optimized out>, dwfl_addr=18446744071580631728) at tapsets.cxx:4701
#1  0x00000000004c6a2b in dwarf_derived_probe::dwarf_derived_probe (this=0x434f210, funcname=..., filename=..., line=459, module=..., section=..., dwfl_addr=18446744071580631728, addr=1786088, q=..., scope_die=0x42093c8) at tapsets.cxx:4543
#2  0x00000000004c779d in dwarf_query::add_probe_point (this=0x7fffffffb920, dw_funcname=..., filename=0x40d3d58 "/home/bernat/src/linux-lts-saucy-3.11.0/fs/read_write.c", line=459, scope_die=0x42093c8, addr=18446744071580631728) at tapsets.cxx:1310
#3  0x00000000004c7bda in query_statement (func=..., file=<optimized out>, line=<optimized out>, scope_die=<optimized out>, stmt_addr=<optimized out>, q=0x7fffffffb920) at tapsets.cxx:1397
#4  0x00000000004c7d63 in query_func_info (entrypc=18446744071580631728, fi=..., q=0x7fffffffb920) at tapsets.cxx:1599
#5  0x00000000004c81df in query_cu (cudie=<optimized out>, arg=0x7fffffffb920) at tapsets.cxx:1887
#6  0x00000000004c86db in dwarf_query::query_module_functions (this=0x7fffffffb920) at tapsets.cxx:1944
#7  0x00000000004c98f3 in dwarf_query::query_module_dwarf (this=0x7fffffffb920) at tapsets.cxx:981
#8  0x00000000004cf398 in dwarf_query::handle_query_module (this=0x7fffffffb920) at tapsets.cxx:1092
#9  0x00000000004bdc47 in query_module (mod=0x206f0c0, name=0x2064cb0 "kernel", addr=18446744071578845184, arg=0x7fffffffb920) at tapsets.cxx:2131
#10 0x00007ffff7bbe080 in dwfl_getmodules () from /usr/lib/x86_64-linux-gnu/libdw.so.1
#11 0x00000000004cc1f5 in dwarf_builder::build (this=0x2064aa0, sess=..., base=0x1fd4250, location=0x1f7b910, parameters=..., finished_results=...) at tapsets.cxx:7139
#12 0x0000000000462cbe in match_node::find_and_build (this=0x20656b0, s=..., p=0x1fd4250, loc=0x1f7b910, pos=2, results=...) at elaborate.cxx:473
#13 0x0000000000462d41 in match_node::find_and_build (this=0x2061550, s=..., p=0x1fd4250, loc=0x1f7b910, pos=1, results=...) at elaborate.cxx:639
#14 0x0000000000462d41 in match_node::find_and_build (this=0x81eb10, s=..., p=0x1fd4250, loc=0x1f7b910, pos=0, results=...) at elaborate.cxx:639
#15 0x00000000004639a6 in derive_probes (s=..., p=0x1fd4250, dps=..., optional=false, rethrow_errors=false) at elaborate.cxx:995
#16 0x00000000004666d9 in semantic_pass_symbols (s=...) at elaborate.cxx:1625
#17 0x000000000046793c in semantic_pass (s=...) at elaborate.cxx:1979
#18 0x0000000000412c45 in passes_0_4 (s=...) at main.cxx:746
#19 0x000000000040e207 in main (argc=<optimized out>, argv=<optimized out>) at main.cxx:1103

So, no "-mfentry" in "producer" variable. Is that expected?
-- 
Treat end of file conditions in a uniform manner.
            - The Elements of Programming Style (Kernighan & Plauger)


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