From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D34F3C43460 for ; Fri, 2 Apr 2021 19:01:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 88E46610FC for ; Fri, 2 Apr 2021 19:01:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236073AbhDBTBN (ORCPT ); Fri, 2 Apr 2021 15:01:13 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:28942 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235946AbhDBTBN (ORCPT ); Fri, 2 Apr 2021 15:01:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617390071; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lH8yhJxrynhxd0WvNK7HIa6U2kDcv+hX7f7c1Z+ZW/c=; b=RV2nDVjt9NSS1D8dRkPl23AUaqtpxWbhqpKNpjptx2BR3S98CmuKm45fKmnAfW4mQWzIZE /GfeRlEwjdDmngniSRiD0NEoyZEApxseaii7R5GA0KTBscXnHWS1BnEUvRSKqvdxR4A4BY AYLTgcqOpsVsM3y1N3hsr+wzUtq+Uog= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-296-ZeI0OyflNsO4b_Zb0QpKHA-1; Fri, 02 Apr 2021 15:01:09 -0400 X-MC-Unique: ZeI0OyflNsO4b_Zb0QpKHA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AA9EB18C43C1; Fri, 2 Apr 2021 19:01:07 +0000 (UTC) Received: from krava (unknown [10.40.193.98]) by smtp.corp.redhat.com (Postfix) with ESMTP id 547891037E81; Fri, 2 Apr 2021 19:01:05 +0000 (UTC) Date: Fri, 2 Apr 2021 21:01:04 +0200 From: Jiri Olsa To: Arnaldo Cc: Yonghong Song , Arnaldo Carvalho de Melo , David Blaikie , dwarves@vger.kernel.org, Alexei Starovoitov , Bill Wendling , bpf , kernel-team@fb.com, Nick Desaulniers , Jiri Olsa Subject: Re: [PATCH dwarves] dwarf_loader: handle subprogram ret type with abstract_origin properly Message-ID: References: <20210401213620.3056084-1-yhs@fb.com> <1ef31dd8-2385-1da1-2c95-54429c895d8a@fb.com> <2d55d22b-d136-82b9-6a0f-8b09eeef7047@fb.com> <82dfd420-96f9-aedc-6cdc-bf20042455db@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Precedence: bulk List-ID: X-Mailing-List: dwarves@vger.kernel.org On Fri, Apr 02, 2021 at 03:08:27PM -0300, Arnaldo wrote: > > > On April 2, 2021 2:42:21 PM GMT-03:00, Yonghong Song wrote: > >On 4/2/21 10:23 AM, Yonghong Song wrote: > :> 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 can take care of that. > > And I think it's time for to look at Jiri's test suite... :-) > > It's a holiday here, so I'll take some time to get to this, hopefully I'll tag 1.21 tomorrow tho. heya, I did not follow this change, but if you put the latest change into some branch I can run it on top of that jirka