[Bug default/28584] Clang doesn't emit DW_AT_external for some global variables so they are dropped by libabigail

["dodji at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #5 from dodji at redhat dot com ---
Hello,

"gprocida at google dot com" <sourceware-bugzilla@sourceware.org>
writes:

> https://sourceware.org/bugzilla/show_bug.cgi?id=28584
>
> gprocida at google dot com changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>          Resolution|FIXED                       |---
>              Status|RESOLVED                    |REOPENED
>
> --- Comment #4 from gprocida at google dot com ---
> Hi.
>
> I don't think DW_AT_external is the real cause.
>
> For the second example below. Here are what GCC 10 and Clang 11 both give me as
> debug_info. They have exactly one DW_AT_external attribute.


I'll use a a DWARF dump emitted by elfutils, which is what
libabigail uses, so I am sure it shows me what libabigail sees.  I don't
know what DWARF dumper you have used.

When I run eu-readelf --debug-dump=info on the smv.o binary you
attached, here is what I am getting:

DWARF section [ 5] '.debug_info' at offset 0x91:
 [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) "Debian clang version 11.1.0-4+build1"
           language             (data2) C_plus_plus_14 (33)
           name                 (strp) "smv.cc"
           stmt_list            (sec_offset) 0
           comp_dir             (strp)
"/usr/local/google/home/gprocida/dev/stg/static_member_variable"
 [    1e]    namespace            abbrev: 2
             name                 (strp) "N"
 [    23]      variable             abbrev: 3
               specification        (ref4) [    3f]
               location             (exprloc) 
                [ 0] addr .data+0 <_ZN1N1S1DE>
               linkage_name         (strp) "_ZN1N1S1DE"

[...]

So, this is the variable DIE (the one at offset 0x23) that matters.
It's the one that carries a reference to the variable ELF symbol which
address is ".data+0 <_ZN1N1S1DE>".  Notice how it doesn't carry any
DW_AT_external attribute.  From its DW_AT_specification attribute
however, we see that it's a concrete "instance" of the member variable
DIE specified at Ox36 below:


 [    36]      structure_type       abbrev: 4
               calling_convention   (data1) pass_by_value (5)
               name                 (strp) "S"
               byte_size            (data1) 1
               decl_file            (data1) smv.cc (1)
               decl_line            (data1) 2
 [    3f]        member               abbrev: 5
                 name                 (strp) "D"
                 type                 (ref4) [    4c]
                 decl_file            (data1) smv.cc (1)
                 decl_line            (data1) 2
                 external             (flag_present) yes
                 declaration          (flag_present) yes

Here ^^^^.  This one carries a DW_AT_external declaration.

GCC (version 11.2.1) however emits this:

[...]

At offset 46, we have this DIE:

 [    46]    variable             abbrev: 6
             specification        (ref4) [    2f]
             decl_line            (data1) 3
             decl_column          (data1) 5
             location             (exprloc) 
              [ 0] addr .data+0 <_ZN1N1S1DE>

So, this is the variable which carries the reference to the ELF symbol.
It's the one we care about.  Notice how it carries a DW_AT_specification
property.

It's a concrete instance to the specification DIE at offset 0x2f, which
we can see below:

DWARF section [ 4] '.debug_info' at offset 0x44:
 [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 C++17 11.2.1 20210728 (Red Hat
11.2.1-1) -mtune=generic -march=x86-64 -g"
           language             (data1) C_plus_plus_14 (33)
           name                 (line_strp) "../smv.cc"
           comp_dir             (line_strp)
"/home/dodji/git/libabigail/PR28584/prtests/static_member_variable/gcc-binary"
           stmt_list            (sec_offset) 0
 [    1e]    namespace            abbrev: 2
             name                 (string) "N"
             decl_file            (data1) smv.cc (1)
             decl_line            (data1) 1
             decl_column          (data1) 11
             sibling              (ref4) [    3f]
 [    28]      structure_type       abbrev: 3
               name                 (string) "S"
               byte_size            (data1) 1
               decl_file            (data1) smv.cc (1)
               decl_line            (data1) 2
               decl_column          (data1) 8
 [    2f]        variable             abbrev: 4
                 name                 (string) "D"
                 decl_file            (data1) smv.cc (1)
                 decl_line            (data1) 2
                 decl_column          (data1) 23
                 linkage_name         (strp) "_ZN1N1S1DE"
                 type                 (ref4) [    3f]
                 external             (flag_present) yes
                 declaration          (flag_present) yes

Here ^^^^^.

Stricto sensu, I don't think Clang's DWARF is wrong.  Libabigail however
was relying on the DW_AT_external to be present on the concrete instance
it sees, even though the concrete instance references an ELF symbol that
is publicly exported.  I think there is enough information in there for
libabigail to make the right choice, which I hope it does now.

Besides, does this patch solve your problem in your environment or not?
(just curious.

I hope this helps.

-- 
You are receiving this mail because:
You are on the CC list for the bug.