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 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.