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/28/26 11:11 PM, Alexei Starovoitov wrote:
> On Sat, Sep 26, 2026 at 10:49 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>> 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.
> I don't think it has to be complicated.
> In your gcc 14 dump the first entry of 'b' starts at low_pc and it's RSI.
> In scx_bpf_task_set_lazy_resched() low_pc is ...d70 and the first entry
> of 'lazy' starts at ...d8b. RBP there says nothing about the register
> 'lazy' was passed in.
> parameter__decode_location() already has 'start' of every entry.
> Can it take the register of the first entry only when that entry
> starts at low_pc and use the entry value otherwise?

Yes, this is what I thought as well.

>
> There is no guarantee, right, but when the guess is wrong the function
> is dropped. It's not encoded with a wrong signature.

Okay, no guarantee, but it should be an improvement.

>
>> 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.
> That works for this kfunc and for pahole that is already released,
> but every other function with a bool arg is still dropped.
> Can clang be fixed to keep the entry range?

Let me investigate this. Probably will be slow a little bit
due lpc and some other events.