public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "mcermak at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug tapsets/30407] Tapset function print_ubacktrace_fileline() no longer works on kernel 6.2/6.1
Date: Thu, 08 Jun 2023 14:27:44 +0000	[thread overview]
Message-ID: <bug-30407-6586-v8oHRil9e7@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-30407-6586@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=30407

Martin Cermak <mcermak at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcermak at redhat dot com

--- Comment #2 from Martin Cermak <mcermak at redhat dot com> ---
This can be replicated with rhel8 (works) versusus rhel9 (doesn't work).  But I
don't think it's related to kernel:  After copying my test binary from rhel8
over to rhel9 (and making sure it's md5-identical, things started to work even
on rhel9!

The following comes from my rhel8 binary where things work fine:

> 8 x86_64 # eu-readelf --debug-dump=info a.out 
> 
> DWARF section [26] '.debug_info' at offset 0x2e70:
>  [Offset]
>  Compilation unit at offset 0:
>  Version: 4, Abbreviation section offset: 0, Address size: 8, Offset size: 4
>  [     b]  compile_unit         abbrev: 1
>            producer             (strp) "GNU C17 8.5.0 20210514 (Red Hat 8.5.0-19) -mtune=generic -march=x86-64 -g"
>            language             (data1) C99 (12)
>            name                 (strp) "test.c"
>            comp_dir             (strp) "/root/build"
>            low_pc               (addr) 0x0000000000400536 <main>
>            high_pc              (data8) 11 (0x0000000000400541)
>            stmt_list            (sec_offset) 0
>  [    2d]    subprogram           abbrev: 2
>              external             (flag_present) yes
>              name                 (strp) "main"
>              decl_file            (data1) test.c (1)
>              decl_line            (data1) 1
>              decl_column          (data1) 5
>              prototyped           (flag_present) yes
>              type                 (ref4) [    4b]
>              low_pc               (addr) 0x0000000000400536 <main>
>              high_pc              (data8) 11 (0x0000000000400541)
>              frame_base           (exprloc) 
>               [ 0] call_frame_cfa
>              GNU_all_call_sites   (flag_present) yes
>  [    4b]    base_type            abbrev: 3
>              byte_size            (data1) 4
>              encoding             (data1) signed (5)
>              name                 (string) "int"
> 8 x86_64 #

Now here's what my rhel9 binary shows:

> 9 x86_64 # eu-readelf --debug-dump=info a.out 
> 
> DWARF section [27] '.debug_info' at offset 0x47a0:
>  [Offset]
>  Compilation unit at offset 0:
>  Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4
>  Unit type: compile (1)
>  [     c]  compile_unit         abbrev: 1
>            producer             (strp) "GNU C17 11.3.1 20221121 (Red Hat 11.3.1-4) -mtune=generic -march=x86-64-v2 -g"
>            language             (data1) C11 (29)
>            name                 (line_strp) "test.c"
>            comp_dir             (line_strp) "/root/build"
>            low_pc               (addr) 0x0000000000401106 <main>
>            high_pc              (data8) 11 (0x0000000000401111)
>            stmt_list            (sec_offset) 0
>  [    2e]    subprogram           abbrev: 2
>              external             (flag_present) yes
>              name                 (strp) "main"
>              decl_file            (data1) test.c (1)
>              decl_line            (data1) 1
>              decl_column          (data1) 5
>              prototyped           (flag_present) yes
>              type                 (ref4) [    4c]
>              low_pc               (addr) 0x0000000000401106 <main>
>              high_pc              (data8) 11 (0x0000000000401111)
>              frame_base           (exprloc) 
>               [ 0] call_frame_cfa
>              call_all_calls       (flag_present) yes
>  [    4c]    base_type            abbrev: 3
>              byte_size            (data1) 4
>              encoding             (data1) signed (5)
>              name                 (string) "int"
> 9 x86_64 # 

I've verified that -march, doesn't cause the difference.  But enforcing DWARF4
on rhel9 with `gcc -gdwarf-4` makes things work again on rhel9!  So I think
it's the DWARF version that makes the difference :)


The print_ubacktrace_fileline() call propagates down to
_stp_linenumber_lookup(address, task, &filename, ...) which already returns the
NULL filename.  Stepping in, this calls _stp_linenumber_lookup(), which returns
struct _stp_module with a NULL debug_line member.  Looking farther...

-- 
You are receiving this mail because:
You are the assignee for the bug.

  parent reply	other threads:[~2023-06-08 14:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-30  6:08 [Bug tapsets/30407] New: Tapset function print_ubacktrace_fileline() no longer works on kernel 6.2 agentzh at gmail dot com
2023-05-02 22:29 ` [Bug tapsets/30407] " agentzh at gmail dot com
2023-05-02 22:32 ` [Bug tapsets/30407] Tapset function print_ubacktrace_fileline() no longer works on kernel 6.2/6.1 agentzh at gmail dot com
2023-06-08 14:27 ` mcermak at redhat dot com [this message]
2023-06-08 14:39 ` [Bug tapsets/30407] Tapset function print_ubacktrace_fileline() no longer works with DWARF5 mcermak at redhat dot com
2023-07-12 14:47 ` wcohen at redhat dot com
2023-07-14 15:25 ` mcermak at redhat dot com
2023-07-26 14:40 ` mark at klomp dot org
2023-10-10  9:14 ` mcermak at redhat dot com
2023-10-10  9:14 ` mcermak at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-30407-6586-v8oHRil9e7@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).