Alan Maguire <alan.maguire@xxxxxxxxxx> 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@xxxxxxxxxx>
>
>
> Reviewed-by: Alan Maguire <alan.maguire@xxxxxxxxxx>
Thanks!
Stephen
