Re: [PATCH dwarves 2/4] dwarf_loader: add "artificial" and "top_level" variable flags

[Stephen Brennan <stephen.s.brennan@oracle.com>]

Alan Maguire <alan.maguire@oracle.com> writes:

> On 12/09/2024 20:08, Stephen Brennan wrote:
>> The "artificial" flag corresponds directly to DW_AT_artificial, which
>> indicates a compiler-generated variable (e.g. __func__) which shouldn't
>> be included in the output.
>>
>
> Nice, didn't know about this! Great to have such a clear criterion for
> filtering.

I've been finding llvm-dwarfdump invaluable for learning these things.
(Aside: thanks to Omar Sandoval to introducing it to me as I've tried to
wrap my head around some small parts of DWARF.)

I discovered this attribute when exploring those __func__ variables:

    $ llvm-dwarfdump vmlinux --name=__func__ | head -n 12
    vmlinux:        file format elf64-x86-64

    0x0001bfd3: DW_TAG_variable
                  DW_AT_name        ("__func__")
                  DW_AT_type        (0x0001c0f0 "const const char[18]")
                  DW_AT_artificial  (true)

    0x0001c148: DW_TAG_variable
                  DW_AT_name        ("__func__")
                  DW_AT_type        (0x0001c552 "const const char[12]")
                  DW_AT_artificial  (true)

Then it was just a quick ctrl-F through the specification to fill in the
gaps.

>> The "top_level" flag is intended to be a better proxy for global scoped
>> variables. Currently, the DWARF loader examines the DWARF location
>
> Looking at this, it appears that top_level means it is a top-level
> compilation unit tag, i.e. not associated with a subroutine tag (I
> think?). That's kind of implicit in your explanation so I think it would
> be helpful for the log to describe what it is as well as how you're
> using it.

Yeah, I'll spell it out more explicitly in this commit message. I do add
a comment in patch 4 which explains the differences between SCOPE_GLOBAL
and top_level (shown below) but something similar should be in the log
message for this change too.

    top_level: indicates that the variable is declared at the top
      level of the CU, and thus it is globally scoped.
    artificial: indicates that the variable is a compiler-generated
      "fake" variable that doesn't appear in the source.
    scope: set by pahole to indicate the type of storage the
      variable has. GLOBAL indicates it is stored in static
      memory (as opposed to a stack variable or register)
    
    Some variables are "top_level" but not GLOBAL:
      e.g. current_stack_pointer, which is a register variable,
      despite having global CU-declarations. We don't want that,
      since no code could actually find this variable.
    Some variables are GLOBAL but not top_level:
      e.g. function static variables

>> expression, and if the location is found to be at a constant memory
>> address (not stack, register, etc), then the variable is assumed to be
>> globally scoped. However, this includes a variety of variables that
>> aren't truly globally scoped: most commonly, static variables in
>> functions definitions. Their locations may be static, but they're not
>> globally accessible in any useful way.
>> 
>> These flags will be used by the BTF encoder to select global variables.
>> 
>> Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
>
>
> Reviewed-by: Alan Maguire <alan.maguire@oracle.com>

Thanks!
Stephen