From: Jiri Olsa <jolsa@redhat.com>
To: Arnaldo <arnaldo.melo@gmail.com>
Cc: Yonghong Song <yhs@fb.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
David Blaikie <dblaikie@gmail.com>,
dwarves@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Bill Wendling <morbo@google.com>, bpf <bpf@vger.kernel.org>,
kernel-team@fb.com, Nick Desaulniers <ndesaulniers@google.com>,
Jiri Olsa <jolsa@kernel.org>
Subject: Re: [PATCH dwarves] dwarf_loader: handle subprogram ret type with abstract_origin properly
Date: Fri, 2 Apr 2021 21:01:04 +0200 [thread overview]
Message-ID: <YGdp8NITtcwOoOs2@krava> (raw)
In-Reply-To: <E9072F07-B689-402C-89F6-545B589EF7E4@gmail.com>
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 <yhs@fb.com> 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
next prev parent reply other threads:[~2021-04-02 19:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 21:36 [PATCH dwarves] dwarf_loader: handle subprogram ret type with abstract_origin properly Yonghong Song
2021-04-01 21:41 ` Yonghong Song
2021-04-01 22:30 ` David Blaikie
[not found] ` <CAENS6EsZ5OX9o=Cn5L1jmx8ucR9siEWbGYiYHCUWuZjLyP3E7Q@mail.gmail.com>
2021-04-01 23:40 ` Yonghong Song
2021-04-02 0:00 ` David Blaikie
2021-04-02 14:04 ` Arnaldo Carvalho de Melo
2021-04-02 14:57 ` Arnaldo Carvalho de Melo
2021-04-02 17:23 ` Yonghong Song
2021-04-02 17:42 ` Yonghong Song
2021-04-02 18:08 ` Arnaldo
2021-04-02 19:01 ` Jiri Olsa [this message]
2021-04-02 19:41 ` Yonghong Song
2021-04-03 17:08 ` Arnaldo Carvalho de Melo
2021-04-04 17:22 ` Jiri Olsa
2021-04-07 14:54 ` Yonghong Song
2021-04-07 15:37 ` Arnaldo Carvalho de Melo
2021-04-07 15:40 ` [RFT] prepping up pahole 1.21, wanna test it? was " Arnaldo Carvalho de Melo
2021-04-07 22:53 ` Yonghong Song
2021-04-09 13:52 ` Arnaldo Carvalho de Melo
2021-04-08 21:23 ` Jiri Olsa
2021-04-09 13:51 ` Arnaldo Carvalho de Melo
2021-04-07 22:51 ` Yonghong Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YGdp8NITtcwOoOs2@krava \
--to=jolsa@redhat.com \
--cc=acme@kernel.org \
--cc=arnaldo.melo@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dblaikie@gmail.com \
--cc=dwarves@vger.kernel.org \
--cc=jolsa@kernel.org \
--cc=kernel-team@fb.com \
--cc=morbo@google.com \
--cc=ndesaulniers@google.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.