semantic error: not accessible at this address

semantic error: not accessible at this address

[Vincent Bernat]

Hi!

I have the following error when trying to use iotop example with a 3.11
kernel:

semantic error: not accessible at this address [man error::dwarf] (0xffffffff811b42b0, dieoffset: 0x177422e): identifier '$file' at /usr/share/systemtap/tapset/linux/vfs.stp:855:9
        source:         file = $file
                               ^

Pass 2: analysis failed.  [man error::pass2]

I have read the wiki but if I use eu-readelf on vmlinux, I get the
appropriate stuff:

 [1774208]    subprogram
             external             (flag) Yes
             name                 (strp) "vfs_write"
             decl_file            (data1) 1
             decl_line            (data2) 459
             prototyped           (flag) Yes
             type                 (ref4) [17643bb]
             low_pc               (addr) 0xffffffff811b42b0
             high_pc              (addr) 0xffffffff811b44a9
             frame_base           (data4) location list [5ec58b]
             sibling              (ref4) [17744b9]
 [177422e]      formal_parameter
               name                 (strp) "file"
               decl_file            (data1) 1
               decl_line            (data2) 459
               type                 (ref4) [1769ace]
               location             (data4) location list [5ec5ff]

The kernel was compiled with gcc 4.6.3 (the one in Ubuntu Precise). I
have tried with gcc 4.7.3 instead but I get less complete information
(the formal parameter lose its name).

systemtap seems to use the right debug file:

focused on module 'kernel' = [0xffffffff81000000-0xffffffff8240e000, bias 0 
file /usr/lib/debug/boot/vmlinux-3.11.0-7-generic ELF machine |x86_64 (code 
62)

How could I fix this?
-- 
Use library functions.
            - The Elements of Programming Style (Kernighan & Plauger)

Re: semantic error: not accessible at this address

[David Smith]

On 09/27/2013 03:14 PM, Vincent Bernat wrote:
> Hi!
> 
> I have the following error when trying to use iotop example with a 3.11
> kernel:
> 
> semantic error: not accessible at this address [man error::dwarf] (0xffffffff811b42b0, dieoffset: 0x177422e): identifier '$file' at /usr/share/systemtap/tapset/linux/vfs.stp:855:9
>         source:         file = $file
>                                ^
> 
> Pass 2: analysis failed.  [man error::pass2]
> 
> I have read the wiki but if I use eu-readelf on vmlinux, I get the
> appropriate stuff:
> 
>  [1774208]    subprogram
>              external             (flag) Yes
>              name                 (strp) "vfs_write"
>              decl_file            (data1) 1
>              decl_line            (data2) 459
>              prototyped           (flag) Yes
>              type                 (ref4) [17643bb]
>              low_pc               (addr) 0xffffffff811b42b0
>              high_pc              (addr) 0xffffffff811b44a9
>              frame_base           (data4) location list [5ec58b]
>              sibling              (ref4) [17744b9]
>  [177422e]      formal_parameter
>                name                 (strp) "file"
>                decl_file            (data1) 1
>                decl_line            (data2) 459
>                type                 (ref4) [1769ace]
>                location             (data4) location list [5ec5ff]
> 
> The kernel was compiled with gcc 4.6.3 (the one in Ubuntu Precise). I
> have tried with gcc 4.7.3 instead but I get less complete information
> (the formal parameter lose its name).
> 
> systemtap seems to use the right debug file:
> 
> focused on module 'kernel' = [0xffffffff81000000-0xffffffff8240e000, bias 0 
> file /usr/lib/debug/boot/vmlinux-3.11.0-7-generic ELF machine |x86_64 (code 
> 62)
> 
> How could I fix this?

This could certainly be a systemtap problem. To help narrow this down a
bit, could you show us the output of the following 2 commands?

# stap -V
# stap -L 'kernel.function("vfs_write").*'

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: semantic error: not accessible at this address

[Vincent Bernat]

 ❦ 27 septembre 2013 22:30 CEST, David Smith <dsmith@redhat.com> :

> This could certainly be a systemtap problem. To help narrow this down a
> bit, could you show us the output of the following 2 commands?
>
> # stap -V
> # stap -L 'kernel.function("vfs_write").*'

Here it is:

$ stap -V
Systemtap translator/driver (version 2.3/0.152, Debian version 2.3-1)
Copyright (C) 2005-2013 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
enabled features: AVAHI LIBSQLITE3 NSS BOOST_SHARED_PTR TR1_UNORDERED_MAP NLS
$ stap -L 'kernel.function("vfs_write").*'
kernel.function("vfs_write@/home/bernat/src/linux-lts-saucy-3.11.0/fs/read_write.c:459").call
kernel.function("vfs_write@/home/bernat/src/linux-lts-saucy-3.11.0/fs/read_write.c:459").exported
kernel.function("vfs_write@/home/bernat/src/linux-lts-saucy-3.11.0/fs/read_write.c:459").return
$return:ssize_t

systemtap is a backport to Ubuntu Precise of what is currently in Debian
Unstable. You can find the differences with upstream version here:
 http://patch-tracker.debian.org/package/systemtap/2.3-1

The kernel is the upcoming kernel for Ubuntu Saucy backported for
Precise (by Ubuntu kernel maintainers) but compiled by me (to get debug
symbols). The kernel in Precise (3.2) is not recent enough to have user
probes (but works for vfs_write) and 3.5 and 3.8 which are available
have incomplete debug symbols.
-- 
Write clearly - don't sacrifice clarity for "efficiency".
            - The Elements of Programming Style (Kernighan & Plauger)

Re: semantic error: not accessible at this address

[Frank Ch. Eigler]

Hi -

> > Also, the output of stap-report (pasted somewhere online) would be
> > helpful.
> 
> Here it is:
>  https://gist.github.com/vincentbernat/8e50f9156f03184cde40
> [...]

This sounds a little bit like http://sourceware.org/PR15123, because
your kernel is compiled with CONFIG_HAVE_FENTRY=Y but is built with a
buggy gcc version.  If so, stap 2.3 is supposed to have a workaround,
but perhaps it's not working for you.

The extra information that would be handy is:

% stap --vp 03 -L 'kernel.function("vfs_write")'
% readelf -w ../vmlinux # like you had, but focusing on location list item
                        # (offset) [5ec5ff] from .debug_loc

- FChE

Re: semantic error: not accessible at this address

[Vincent Bernat]

 ❦ 28 septembre 2013 01:04 CEST, "Frank Ch. Eigler" <fche@redhat.com> :

>> > Also, the output of stap-report (pasted somewhere online) would be
>> > helpful.
>> 
>> Here it is:
>>  https://gist.github.com/vincentbernat/8e50f9156f03184cde40
>> [...]
>
> This sounds a little bit like http://sourceware.org/PR15123, because
> your kernel is compiled with CONFIG_HAVE_FENTRY=Y but is built with a
> buggy gcc version.  If so, stap 2.3 is supposed to have a workaround,
> but perhaps it's not working for you.

I also tried with a GCC 4.7.3 but ends up with even less symbols.

> The extra information that would be handy is:
>
> % stap --vp 03 -L 'kernel.function("vfs_write")'

Attempting to extract kernel debuginfo build ID from /lib/modules/3.11.0-7-generic/build/vmlinux.id
Attempting to extract kernel debuginfo build ID from /sys/kernel/notes
blacklist regexps:
blfn: ^(atomic_notifier_call_chain|default_do_nmi|__die|die_nmi|do_debug|do_general_protection|do_int3|do_IRQ|do_page_fault|do_sparc64_fault|do_trap|dummy_nmi_callback|flush_icache_range|ia64_bad_break|ia64_do_page_fault|ia64_fault|io_check_error|mem_parity_error|nmi_watchdog_tick|notifier_call_chain|oops_begin|oops_end|program_check_exception|single_step_exception|sync_regs|unhandled_fault|unknown_nmi_error|xen_[gs]et_debugreg|xen_irq_.*|xen_.*_fl_direct.*|check_events|xen_adjust_exception_frame|xen_iret.*|xen_sysret64.*|test_ti_thread_flag.*|inat_get_opcode_attribute|system_call_after_swapgs|HYPERVISOR_[gs]et_debugreg|HYPERVISOR_event_channel_op|hash_64|hash_ptr|native_set_pte|.*raw_.*_lock.*|.*raw_.*_unlock.*|.*raw_.*_trylock.*|.*read_lock.*|.*read_unlock.*|.*read_trylock.*|.*write_lock.*|.*write_unlock.*|.*write_trylock.*|.*write_seqlock.*|.*write_sequnlock.*|.*spin_lock.*|.*spin_unlock.*|.*spin_trylock.*|.*spin_is_locked.*|rwsem_.*lock.*|.*mutex_.*lock.*|raw_.*|atomic_.*|atomic64_.*|get_bh|put_bh|.*apic.*|.*APIC.*|.*softirq.*|.*IRQ.*|.*_intr.*|__delay|.*kernel_text.*|get_current|current_.*|.*exception_tables.*|.*setup_rt_frame.*|.*preempt_count.*|preempt_schedule|__switch_to|special_mapping_.*|.*_pte_.*)$
blfn_ret: ^(do_exit|sys_exit|sys_exit_group)$
blfile: ^(kernel/kprobes\.c|arch/.*/kernel/kprobes\.c|.*/include/asm/io\.h|.*/include/asm/io_64\.h|.*/include/asm/bitops\.h|drivers/ide/ide-iops\.c|arch/.*/kernel/paravirt\.c|.*/include/asm/paravirt\.h|fs/seq_file\.c)$
blsection: ^(\.init\.|\.exit\.|\.devinit\.|\.devexit\.|\.cpuinit\.|\.cpuexit\.|\.meminit\.|\.memexit\.)
parse 'vfs_write', func 'vfs_write'
focused on module 'kernel' = [0xffffffff81000000-0xffffffff8240e000, bias 0 file /usr/lib/debug/boot/vmlinux-3.11.0-7-generic ELF machine |x86_64 (code 62)
focused on module 'kernel'
selected function vfs_write
selected function vfs_write
probe vfs_write@/home/bernat/src/linux-lts-saucy-3.11.0/fs/read_write.c:459 kernel reloc=.dynamic pc=0xffffffff811b42b0
saveargs: examining 'vfs_write' (dieoffset: 0x1774208)
saveargs: finding location for local 'file' (dieoffset: 0x177422e)
saveargs: local 'file' (dieoffset: 0x177422e) is not available at this address (0xffffffff811b42b0)
saveargs: finding location for local 'buf' (dieoffset: 0x177423e)
saveargs: local 'buf' (dieoffset: 0x177423e) is not available at this address (0xffffffff811b42b0)
saveargs: finding location for local 'count' (dieoffset: 0x177424e)
saveargs: local 'count' (dieoffset: 0x177424e) is not available at this address (0xffffffff811b42b0)
saveargs: finding location for local 'pos' (dieoffset: 0x177425e)
saveargs: local 'pos' (dieoffset: 0x177425e) is not available at this address (0xffffffff811b42b0)
saveargs: finding location for local 'ret' (dieoffset: 0x177426e)
saveargs: local 'ret' (dieoffset: 0x177426e) is not available at this address (0xffffffff811b42b0)
kernel.function("vfs_write@/home/bernat/src/linux-lts-saucy-3.11.0/fs/read_write.c:459") /* pc=_stext+0x1b40e8 */ /* <- kernel.function("vfs_write") */
chain[2]:
  [0]:
        locations[1]:
          [0]: kernel.function("vfs_write@/home/bernat/src/linux-lts-saucy-3.11.0/fs/read_write.c:459")
  [1]:
        locations[1]:
          [0]: kernel.function("vfs_write")
kernel.function("vfs_write@/home/bernat/src/linux-lts-saucy-3.11.0/fs/read_write.c:459")
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s) using 355052virt/181416res/119928shr/61840data kb, in 540usr/20sys/565real ms.
Running rm -rf /tmp/stapYuXWt6
Spawn waitpid result (0x0): 0
Removed temporary directory "/tmp/stapYuXWt6"

> % readelf -w ../vmlinux # like you had, but focusing on location list item
>                         # (offset) [5ec5ff] from .debug_loc

 [5ec5ff]      member
               name                 (strp) "spin_lock"
               decl_file            (data1) 18
               decl_line            (data2) 333
               type                 (ref4) [5ec679]
               data_member_location (block1)                 [   0] plus_uconst 16

Thanks!
-- 
 /* Nobody will ever see this message :-) */
panic("Cannot initialize video hardware\n");
	2.0.38 /usr/src/linux/arch/m68k/atari/atafb.c

Re: semantic error: not accessible at this address

[Frank Ch. Eigler]

Hi, Vincent -


> I also tried with a GCC 4.7.3 but ends up with even less symbols.

I wonder why.  In any case, GCC 4.8 is more current, and we've had
fine luck with it.



> probe vfs_write@/home/bernat/src/linux-lts-saucy-3.11.0/fs/read_write.c:459 kernel reloc=.dynamic pc=0xffffffff811b42b0
> saveargs: examining 'vfs_write' (dieoffset: 0x1774208)
> saveargs: finding location for local 'file' (dieoffset: 0x177422e)
> saveargs: local 'file' (dieoffset: 0x177422e) is not available at this address (0xffffffff811b42b0)
> saveargs: finding location for local 'buf' (dieoffset: 0x177423e)
> saveargs: local 'buf' (dieoffset: 0x177423e) is not available at this address (0xffffffff811b42b0)
> saveargs: finding location for local 'count' (dieoffset: 0x177424e)
> [...]

The -mfentry-compensation code should cause you to be seeing some
messages like this:

retrying variable location-list lookup at address pc+5

> [...]
> > % readelf -w ../vmlinux # like you had, but focusing on location list item
> >                         # (offset) [5ec5ff] from .debug_loc
> 
>  [5ec5ff]      member
>                name                 (strp) "spin_lock"
>                decl_file            (data1) 18
>                decl_line            (data2) 333
>                type                 (ref4) [5ec679]
>                data_member_location (block1)                 [   0] plus_uconst 16

That's an unrelated .debug_info tidbit.  I'd like to see the
location_list entries associated with one of the sys_write variables.
That's far later in the readelf -w output, in the .debug_loc section,
specifically for the two offsets listed below: 

             frame_base     (data4) location list [5ec58b]
"file" var   location       (data4) location list [5ec5ff]


- FChE

Re: semantic error: not accessible at this address

[Vincent Bernat]

 ❦ 28 septembre 2013 01:25 CEST, "Frank Ch. Eigler" <fche@redhat.com> :

>> I also tried with a GCC 4.7.3 but ends up with even less symbols.
>
> I wonder why.  In any case, GCC 4.8 is more current, and we've had
> fine luck with it.

I'll try with it.

>> probe
>> vfs_write@/home/bernat/src/linux-lts-saucy-3.11.0/fs/read_write.c:459
>> kernel reloc=.dynamic pc=0xffffffff811b42b0
>> saveargs: examining 'vfs_write' (dieoffset: 0x1774208)
>> saveargs: finding location for local 'file' (dieoffset: 0x177422e)
>> saveargs: local 'file' (dieoffset: 0x177422e) is not available at
>> this address (0xffffffff811b42b0)
>> saveargs: finding location for local 'buf' (dieoffset: 0x177423e)
>> saveargs: local 'buf' (dieoffset: 0x177423e) is not available at
>> this address (0xffffffff811b42b0)
>> saveargs: finding location for local 'count' (dieoffset: 0x177424e)
>> [...]
>
> The -mfentry-compensation code should cause you to be seeing some
> messages like this:
>
> retrying variable location-list lookup at address pc+5

OK

>> [...]
>> > % readelf -w ../vmlinux # like you had, but focusing on location list item
>> >                         # (offset) [5ec5ff] from .debug_loc
>> 
>>  [5ec5ff]      member
>>                name                 (strp) "spin_lock"
>>                decl_file            (data1) 18
>>                decl_line            (data2) 333
>>                type                 (ref4) [5ec679]
>>                data_member_location (block1)                 [   0] plus_uconst 16
>
> That's an unrelated .debug_info tidbit.  I'd like to see the
> location_list entries associated with one of the sys_write variables.
> That's far later in the readelf -w output, in the .debug_loc section,
> specifically for the two offsets listed below: 
>
>              frame_base     (data4) location list [5ec58b]
> "file" var   location       (data4) location list [5ec5ff]

Is that this?

    005ec58b ffffffff811b42b0 ffffffff811b42b6 (DW_OP_breg7 (rsp): 8)
    005ec58b ffffffff811b42b6 ffffffff811b42b9 (DW_OP_breg7 (rsp): 16)
    005ec58b ffffffff811b42b9 ffffffff811b43f9 (DW_OP_breg6 (rbp): 16)
    005ec58b ffffffff811b43f9 ffffffff811b4400 (DW_OP_breg7 (rsp): 8)
    005ec58b ffffffff811b4400 ffffffff811b44a9 (DW_OP_breg6 (rbp): 16)
    005ec58b <End of list>
    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>

Thanks!
-- 
Let the machine do the dirty work.
            - The Elements of Programming Style (Kernighan & Plauger)

Re: semantic error: not accessible at this address

[Frank Ch. Eigler]

Hi -

> > 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.

- FChE

Re: semantic error: not accessible at this address

[Vincent Bernat]

 ❦ 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)

Re: semantic error: not accessible at this address

[Frank Ch. Eigler]

Hi -

On Sat, Sep 28, 2013 at 09:48:48AM +0200, Vincent Bernat wrote:
> [...]
> So, no "-mfentry" in "producer" variable. Is that expected?

Aha, good catch.  That was one of the safeguards we dropped into
the stap code, but it relies on the CFLAGS=-grecord-gcc-switches.
Would you be interested in adding code to that function to suppot
a PR15123_ASSUME_MFENTRY-ish environment variable, that bypasses
that subtest?

- FChE

[PATCH] PR15123: when PR15123_ASSUME_MFENTRY is set, don't check for -mfentry flag

[Vincent Bernat]

-mfentry flag is recorded in `DW_AT_producer` only if
`CFLAGS=-grecord-gcc-switches` was used at compilation-time. We
provide PR15123_ASSUME_MFENTRY as an environment variable to override
this detection. The user is expected to set this variable only if it
is confident that that CFLAGS=-mfentry was used.
---
 dwflpp.cxx | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/dwflpp.cxx b/dwflpp.cxx
index 176b602..bef33fa 100644
--- a/dwflpp.cxx
+++ b/dwflpp.cxx
@@ -3768,7 +3768,11 @@ dwflpp::pr15123_retry_addr (Dwarf_Addr pc, Dwarf_Die* die)
   // - if the architecture is familiar enough that we can have a
   // hard-coded constant to skip over the prologue.
   //
-  // Otherwise, we could give a false-positive - return corrupted data.
+  // Otherwise, we could give a false-positive - return corrupted
+  // data. Use of -mfentry is detected only if
+  // CFLAGS=-grecord-gcc-switches was used. The detection can
+  // therefore be overriden if PR15123_ASSUME_MFENTRY environment
+  // variable is present.
 
   if (getenv ("PR15123_DISABLE"))
     return 0;
@@ -3779,11 +3783,13 @@ dwflpp::pr15123_retry_addr (Dwarf_Addr pc, Dwarf_Die* die)
   if (! dwarf_attr_integrate(&cudie, DW_AT_producer, &cudie_producer))
     return 0;
 
-  const char* producer = dwarf_formstring(&cudie_producer);
-  if (!producer)
-    return 0;
-  if (! strstr(producer, "-mfentry"))
-    return 0;
+  if (!getenv ("PR15123_ASSUME_MFENTRY")) {
+    const char* producer = dwarf_formstring(&cudie_producer);
+    if (!producer)
+      return 0;
+    if (! strstr(producer, "-mfentry"))
+      return 0;
+  }
 
   // Determine if this pc maps to the beginning of a
   // real function (not some inlined doppelganger.  This
-- 
1.8.4.rc3

Re: semantic error: not accessible at this address

[Vincent Bernat]

 ❦ 28 septembre 2013 14:46 CEST, "Frank Ch. Eigler" <fche@redhat.com> :

>> [...]
>> So, no "-mfentry" in "producer" variable. Is that expected?
>
> Aha, good catch.  That was one of the safeguards we dropped into
> the stap code, but it relies on the CFLAGS=-grecord-gcc-switches.
> Would you be interested in adding code to that function to suppot
> a PR15123_ASSUME_MFENTRY-ish environment variable, that bypasses
> that subtest?

I have sent a proposition of patch (that works for me) but maybe you
prefer that I go through the bugzilla?

I am also concerned that a global environment variable for this would be
unsafe if you have to debug a combination of binaries compiled with and
without -mfentry (a kernel and some userland programs). I will just
recompile the kernel with CFLAGS=-grecord-gcc-switches. This seems
safer.

I can also advocate to Debian and Ubuntu to use this CFLAGS for future
kernel releases. Is there any drawback to this flag (I assume not)? Is
it still useful when GCC version is fixed? I mean, can we assume that we
will run in future GCC bugs and that will help to workaround them in the
future?

Thanks for the troubleshooting!
-- 
printk("Penguin %d is stuck in the bottle.\n", i);
	2.0.38 /usr/src/linux/arch/sparc/kernel/smp.c

Re: semantic error: not accessible at this address

[Frank Ch. Eigler]

Hi -

bernat wrote:
> [...]
> I have sent a proposition of patch (that works for me) but maybe you
> prefer that I go through the bugzilla?

Looks good, merged.

> I am also concerned that a global environment variable for this would be
> unsafe if you have to debug a combination of binaries compiled with and
> without -mfentry (a kernel and some userland programs). I will just
> recompile the kernel with CFLAGS=-grecord-gcc-switches. This seems
> safer.

Sure is.  This environment variable knob would be just for those who
cannot recompile.

> I can also advocate to Debian and Ubuntu to use this CFLAGS for future
> kernel releases. Is there any drawback to this flag (I assume not)? Is
> it still useful when GCC version is fixed? I mean, can we assume that we
> will run in future GCC bugs and that will help to workaround them in the
> future?

I believe it is purely advantageous and worth advocating elsewhere.

- FChE

Re: semantic error: not accessible at this address

[Vincent Bernat]

 ❦ 29 septembre 2013 16:11 CEST, "Frank Ch. Eigler" <fche@redhat.com> :

>> I can also advocate to Debian and Ubuntu to use this CFLAGS for future
>> kernel releases. Is there any drawback to this flag (I assume not)? Is
>> it still useful when GCC version is fixed? I mean, can we assume that we
>> will run in future GCC bugs and that will help to workaround them in the
>> future?
>
> I believe it is purely advantageous and worth advocating elsewhere.

I have asked both Ubuntu and Debian to use this flag:

 http://bugs.debian.org/724976
 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1233014
-- 
Use the "telephone test" for readability.
            - The Elements of Programming Style (Kernighan & Plauger)

Re: semantic error: not accessible at this address

[Vincent Bernat]

 ❦ 30 septembre 2013 09:05 CEST, Vincent Bernat <bernat@luffy.cx> :

>>> I can also advocate to Debian and Ubuntu to use this CFLAGS for future
>>> kernel releases. Is there any drawback to this flag (I assume not)? Is
>>> it still useful when GCC version is fixed? I mean, can we assume that we
>>> will run in future GCC bugs and that will help to workaround them in the
>>> future?
>>
>> I believe it is purely advantageous and worth advocating elsewhere.
>
> I have asked both Ubuntu and Debian to use this flag:
>
>  http://bugs.debian.org/724976
>  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1233014

Unfortunately, I discovered that this option was added to GCC 4.7 and
hence is not available in GCC 4.6.3.
-- 
Make it clear before you make it faster.
            - The Elements of Programming Style (Kernighan & Plauger)