Re: [PATCH dwarves] dwarf_loader: handle subprogram ret type with abstract_origin properly

[Yonghong Song <yhs@fb.com>]

On 4/2/21 10:23 AM, Yonghong Song wrote:
> 
> 
> On 4/2/21 7:57 AM, Arnaldo Carvalho de Melo wrote:
>> Em Fri, Apr 02, 2021 at 11:04:18AM -0300, Arnaldo Carvalho de Melo 
>> escreveu:
>>> Em Thu, Apr 01, 2021 at 05:00:46PM -0700, David Blaikie escreveu:
>>>> On Thu, Apr 1, 2021 at 4:41 PM Yonghong Song <yhs@fb.com> wrote:
>>>>> On 4/1/21 3:27 PM, David Blaikie wrote:
>>>>>> Though people may come up with novel uses of DWARF features. What 
>>>>>> would
>>>>>> happen if this constraint were violated/what's your motivation for
>>>>>> asking (I don't quite understand the connection between test_progs
>>>>>> failure description, and this question)
>>
>>>>> I have some codes to check the tag associated with abstract_origin
>>>>> for a subprogram must be a subprogram. Through experiment, I didn't
>>>>> see a violation, so I wonder that I can get confirmation from you
>>>>> and then I may delete that code.
>>
>>>>> The test_progs failure exposed the bug, that is all.
>>
>>>>> pahole cannot handle all weird usages of dwarf, so I think pahole
>>>>> is fine only to support well-formed dwarf.
>>
>>>> Sounds good. Thanks for the context!
>>
>>> David, since you took the time to go thru the changes and to agree that
>>> Yonghong's fix is good, can I add a:
>>
>>> Acked-by: David Blaikie <dblaikie@gmail.com>
>>
>>> to this patch?
>>
>>> Maybe even a:
>>
>>> Reviewed-by: David Blaikie <dblaikie@gmail.com>
>>
>> What I have is at tmp.master, please take a look and check that
>> everything is ok, the only think I wished to fix but I think can be left
>> for later is in the tmp.master branch at:
>>
>>   git://git.kernel.org/pub/scm/devel/pahole/pahole.git tmp.master
> 
> Thanks. I checked out the branch and did some testing with latest clang 
> trunk (just pulled in).
> 
> With kernel LTO note support, I tested gcc non-lto, and llvm-lto mode, 
> it works fine.
> 
> Without kernel LTO note support, I tested
>    gcc non-lto  <=== ok
>    llvm non-lto  <=== not ok
>    llvm lto     <=== ok
> 
> Surprisingly llvm non-lto vmlinux had the same "tcp_slow_start" issue.
> Some previous version of clang does not have this issue.
> I double checked the dwarfdump and it is indeed has the same reason
> for lto vmlinux. I checked abbrev section and there is no cross-cu
> references.
> 
> That means we need to adapt this patch
>    dwarf_loader: Handle subprogram ret type with abstract_origin properly
> for non merging case as well.
> The previous patch fixed lto subprogram abstract_origin issue,
> I will submit a followup patch for this.

Actually, the change is pretty simple,

diff --git a/dwarf_loader.c b/dwarf_loader.c
index 5dea837..82d7131 100644
--- a/dwarf_loader.c
+++ b/dwarf_loader.c
@@ -2323,7 +2323,11 @@ static int die__process_and_recode(Dwarf_Die 
*die, struct cu *cu)
         int ret = die__process(die, cu);
         if (ret != 0)
                 return ret;
-       return cu__recode_dwarf_types(cu);
+       ret = cu__recode_dwarf_types(cu);
+       if (ret != 0)
+               return ret;
+
+       return cu__resolve_func_ret_types(cu);
  }

Arnaldo, do you just want to fold into previous patches, or
you want me to submit a new one?

> 
>>
>> I did some testing for this ret type fix:
>>
>> https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?h=tmp.master 
>>
>>
>> And for the LTO ELF notes:
>>
>> https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?h=tmp.master&id=7a79d2d7a573a863aa36fd06f540fe9fa824db4e 
>>
>>
>> The only remaining thing, which I think can be left for 1.22 is:
>>
>> [acme@five pahole]$ btfdiff vmlinux.clang.thin.LTO
>> vmlinux.clang.thin.LTO           vmlinux.clang.thin.LTO+ELF_note
>> [acme@five pahole]$ btfdiff vmlinux.clang.thin.LTO+ELF_note
>> --- /tmp/btfdiff.dwarf.CtLJpQ    2021-04-02 11:55:09.658433186 -0300
>> +++ /tmp/btfdiff.btf.d3L3vy    2021-04-02 11:55:09.925439277 -0300
>> @@ -67255,7 +67255,7 @@ struct cpu_rmap {
>>       struct {
>>           u16                index;                /*    16     2 */
>>           u16                dist;                 /*    18     2 */
>> -    } near[0]; /*    16     0 */
>> +    } near[]; /*    16     0 */
>>
>>       /* size: 16, cachelines: 1, members: 5 */
>>       /* last cacheline: 16 bytes */
>> @@ -101181,7 +101181,7 @@ struct linux_efi_memreserve {
>>       struct {
>>           phys_addr_t        base;                 /*    16     8 */
>>           phys_addr_t        size;                 /*    24     8 */
>> -    } entry[0]; /*    16     0 */
>> +    } entry[]; /*    16     0 */
>>
>>       /* size: 16, cachelines: 1, members: 4 */
>>       /* last cacheline: 16 bytes */
>> @@ -113516,7 +113516,7 @@ struct netlink_policy_dump_state {
>>       struct {
>>           const struct nla_policy  * policy;       /*    16     8 */
>>           unsigned int       maxtype;              /*    24     4 */
>> -    } policies[0]; /*    16     0 */
>> +    } policies[]; /*    16     0 */
>>
>>       /* size: 16, cachelines: 1, members: 4 */
>>       /* sum members: 12, holes: 1, sum holes: 4 */
>> [acme@five pahole]$
>>
>> - Arnaldo
>>