From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Yonghong Song <yhs@fb.com>
Cc: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
dwarves@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Bill Wendling <morbo@google.com>,
bpf@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH dwarves 0/3] add option to merge more dwarf cu's into
Date: Thu, 25 Mar 2021 10:10:33 -0300 [thread overview]
Message-ID: <YFyLyfYCD131ZM5k@kernel.org> (raw)
In-Reply-To: <20210325065316.3121287-1-yhs@fb.com>
Em Wed, Mar 24, 2021 at 11:53:16PM -0700, Yonghong Song escreveu:
> For vmlinux built with clang thin-lto or lto for latest bpf-next,
> there exist cross cu debuginfo type references. For example,
> compile unit 1:
> tag 10: type A
> compile unit 2:
> ...
> refer to type A (tag 10 in compile unit 1)
> I only checked a few but have seen type A may be a simple type
> like "unsigned char" or a complex type like an array of base types.
> I am using latest llvm trunk and bpf-next. I suspect llvm12 or
> linus tree >= 5.12 rc2 should be able to exhibit the issue as well.
> Both thin-lto and lto have the same issues.
>
> Current pahole cannot handle this. It will report types cannot
> be found error. Bill Wendling has attempted to fix the issue
> with [1] by permitting all tags/types are hashed to the same
> hash table and then process cu's one by one. This does not
> really work. The reason is that each cu resolves types locally
> so for the above example we may have
> compile unit 1:
> type A : type_id = 10
> compile unit 2:
> refer to type A : type A will be resolved as type id = 10
> But id 10 refers to compile unit 1, we will get either out
> of bound type id or incorrect one.
>
> This patch set is a continuation of Bill's work. We still
> increase the hashtable size and traverse all cu's before
> recoding and finalization. But instead of creating one-to-one
> mapping between debuginfo cu and pahole cu, we just create
> one pahole cu, which should solve the above incorrect type
> id issue.
>
> Patches #1 and #2 are refactoring the existing code
> and Patch #3 added an option "merge_cus" to permit
> merging all debuginfo cu's into one pahole cu.
> For vmlinux built, it can be detected that if LTO or Thin-LTO
> is enabled, "merge_cus" can be added into pahole
> command line.
>
> [1] https://www.spinics.net/lists/dwarves/msg00999.html
Thanks for working on this, I'll look at it today.
- Arnaldo
next prev parent reply other threads:[~2021-03-25 13:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-25 6:53 [PATCH dwarves 0/3] add option to merge more dwarf cu's into Yonghong Song
2021-03-25 6:53 ` [PATCH dwarves 1/3] dwarf_loader: permits flexible HASHTAGS__BITS Yonghong Song
2021-03-26 23:13 ` Andrii Nakryiko
2021-03-26 23:26 ` Yonghong Song
2021-03-29 14:02 ` Arnaldo Carvalho de Melo
2021-03-31 4:30 ` Andrii Nakryiko
2021-03-25 6:53 ` [PATCH dwarves 2/3] dwarf_loader: factor out common code to initialize a cu Yonghong Song
2021-03-25 6:53 ` [PATCH dwarves 3/3] dwarf_loader: add option to merge more dwarf cu's into one pahole cu Yonghong Song
2021-03-26 14:41 ` Arnaldo Carvalho de Melo
2021-03-26 15:18 ` Yonghong Song
2021-03-26 17:35 ` Arnaldo Carvalho de Melo
2021-03-26 18:19 ` Arnaldo Carvalho de Melo
2021-03-26 23:05 ` Yonghong Song
2021-03-26 23:12 ` Alexei Starovoitov
2021-03-26 23:17 ` Yonghong Song
2021-03-29 14:04 ` Arnaldo Carvalho de Melo
2021-03-26 15:18 ` Arnaldo Carvalho de Melo
2021-03-26 23:21 ` Andrii Nakryiko
2021-03-27 0:19 ` Yonghong Song
2021-03-25 13:10 ` Arnaldo Carvalho de Melo [this message]
2021-03-26 1:41 ` [PATCH dwarves 0/3] add option to merge more dwarf cu's into 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=YFyLyfYCD131ZM5k@kernel.org \
--to=acme@kernel.org \
--cc=andrii@kernel.org \
--cc=arnaldo.melo@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dwarves@vger.kernel.org \
--cc=kernel-team@fb.com \
--cc=morbo@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox