Re: [PATCH dwarves 1/2] dwarf_loader: Trust the entry value register over the first location entry

[Yonghong Song <yonghong.song@linux.dev>]

On 9/26/26 12:45 AM, Alexei Starovoitov wrote:
> On Fri, Sep 25, 2026 at 02:36 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>> DW_OP_entry_value(DW_OP_regN) says the parameter still holds the value regN
>> had on entry to the function, so regN is by definition the register the
>> parameter was passed in.  That is better evidence than the first location
>> list entry, so prefer it.
> my bot is saying that this is not quite the case.
>
> gcc 13 -O2 for
>
> long f6(long a, long b)
> {
> 	b = a;
> 	ext();
> 	ext();
> 	return 0;
> }
>
> describes 'b' as:
>    [0x40, 0x44): DW_OP_reg4 RSI
>    [0x44, 0x4c): DW_OP_reg5 RDI
>    [0x4c, 0x59): DW_OP_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value

I tried with the above example.

$ cat t1.c
void ext(void);
long f6(long a, long b)
{
         b = a;
         ext();
         ext();
         return 0;
}

$ gcc -O2 -c -g t1.c.  # gcc14
$ llvm-dwarfdump t1.o
...

0x00000053:     DW_TAG_formal_parameter
                   DW_AT_name    ("a")
                   DW_AT_decl_file       ("/home/yhs/tmp/t1.c")
                   DW_AT_decl_line       (2)
                   DW_AT_decl_column     (14)
                   DW_AT_type    (0x0000008e "long int")
                   DW_AT_location        (0x00000010:
                      [0x0000000000000000, 0x0000000000000008): DW_OP_reg5 RDI
                      [0x0000000000000008, 0x0000000000000015): DW_OP_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value)
                   DW_AT_GNU_locviews    (0x0000000c)

0x00000063:     DW_TAG_formal_parameter
                   DW_AT_name    ("b")
                   DW_AT_decl_file       ("/home/yhs/tmp/t1.c")
                   DW_AT_decl_line       (2)
                   DW_AT_decl_column     (22)
                   DW_AT_type    (0x0000008e "long int")
                   DW_AT_location        (0x0000002d:
                      [0x0000000000000000, 0x0000000000000000): DW_OP_reg4 RSI
                      [0x0000000000000000, 0x0000000000000008): DW_OP_reg5 RDI
                      [0x0000000000000008, 0x0000000000000015): DW_OP_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value)
                   DW_AT_GNU_locviews    (0x00000027)

Maybe we need to poke into locations to get precise parameter register.
For example, for argument 'b', we have
	[0x0000000000000000, 0x0000000000000000): DW_OP_reg4 RSI
	...
	[0x0000000000000008, 0x0000000000000015): DW_OP_entry_value(DW_OP_reg5 RDI), DW_OP_stack_value)
RSI has location starts from 0x0, RDI starts from 0x8 although it has DW_OP_entry_value.

But this makes things complicated, and there is no garantee across different compilers due to
code gen.

>
> pahole encodes f6() today. With this patch loc_reg of 'b' becomes RDI,
> RSI is expected, and f6() is dropped.

Okay, that means my patch actually not working.

>
>> +	if (entry_value_reg != PARAMETER_UNKNOWN_REG && !parameter__has_piece_info(parm))
>> +		parm->loc_reg = entry_value_reg;
> This fixes only the functions where clang happened to emit
> an entry value. clang -O2 for
>
> bool g_lazy(struct task *p, bool lazy)
> {
> 	rcu_lock();
> 	__atomic_store_n(&p->lazy, lazy, __ATOMIC_RELAXED);
> 	rcu_unlock();
> 	return lazy;
> }
>
> describes 'lazy' as:
>    [0x09, 0x1e): DW_OP_reg3 RBX
>    [0x1e, 0x21): DW_OP_reg0 RAX
>
> low_pc is 0. There is no entry value, so g_lazy() is still dropped.
> With 'int lazy' the list starts at low_pc with RSI.
> Looks like clang loses the entry range for every bool arg.

In some other cases, clang may generate even more complicated dwarf
for bool parameters.

One possible workaround is change 'lazy' type from 'bool' to say 'int'.
As Alexei mentioned in the above, clang didn't handle 'bool' well
in debug info.