* [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
@ 2021-04-01 2:58 Yonghong Song
2021-04-01 2:58 ` [PATCH dwarves 1/2] dwarf_loader: check .debug_abbrev for cross-cu references Yonghong Song
` (4 more replies)
0 siblings, 5 replies; 33+ messages in thread
From: Yonghong Song @ 2021-04-01 2:58 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, dwarves
Cc: Alexei Starovoitov, Andrii Nakryiko, Bill Wendling, bpf,
David Blaikie, Fāng-ruì Sòng, kernel-team,
Nick Desaulniers
Function cus__merging_cu() is introduced in Commit 39227909db3c
("dwarf_loader: Permit merging all DWARF CU's for clang LTO built
binary") to test whether cross-cu references may happen.
The original implementation anticipates compilation flags
in dwarf, but later some concerns about binary size surfaced
and the decision is to scan .debug_abbrev as a faster way
to check cross-cu references. Also putting a note in vmlinux
to indicate whether lto is enabled for built or not can
provide a much faster way.
This patch set implemented this two approaches, first
checking the note (in Patch #2), if not found, then
check .debug_abbrev (in Patch #1).
Yonghong Song (2):
dwarf_loader: check .debug_abbrev for cross-cu references
dwarf_loader: check .notes section for lto build info
dwarf_loader.c | 76 ++++++++++++++++++++++++++++++++++++--------------
1 file changed, 55 insertions(+), 21 deletions(-)
--
2.30.2
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH dwarves 1/2] dwarf_loader: check .debug_abbrev for cross-cu references
2021-04-01 2:58 [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu() Yonghong Song
@ 2021-04-01 2:58 ` Yonghong Song
2021-04-01 18:52 ` Nick Desaulniers
2021-04-01 2:58 ` [PATCH dwarves 2/2] dwarf_loader: check .notes section for lto build info Yonghong Song
` (3 subsequent siblings)
4 siblings, 1 reply; 33+ messages in thread
From: Yonghong Song @ 2021-04-01 2:58 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, dwarves
Cc: Alexei Starovoitov, Andrii Nakryiko, Bill Wendling, bpf,
David Blaikie, Fāng-ruì Sòng, kernel-team,
Nick Desaulniers
Commit 39227909db3c checked compilation flags to see
whether the binary is built with lto or not (-flto).
Currently, for clang lto build, default setting
won't put compilation flags in dwarf due to size
concern.
David Blaikie suggested in [1] to scan through .debug_abbrev
for DW_FORM_ref_addr which should be most faster than
scanning through cu's. This patch implemented this
suggestion and replaced the previous compilation flag
matching approach. Indeed, it seems that the overhead
for this approach is indeed managable.
I did some change to measure the overhead of cus_merging_cu():
@@ -2650,7 +2652,15 @@ static int cus__load_module(struct cus *cus, struct conf_load *conf,
}
}
- if (cus__merging_cu(dw)) {
+ bool do_merging;
+ struct timeval start, end;
+ gettimeofday(&start, NULL);
+ do_merging = cus__merging_cu(dw);
+ gettimeofday(&end, NULL);
+ fprintf(stderr, "%ld %ld -> %ld %ld\n", start.tv_sec, start.tv_usec,
+ end.tv_sec, end.tv_usec);
+
+ if (do_merging) {
res = cus__merge_and_process_cu(cus, conf, mod, dw, elf, filename,
build_id, build_id_len,
type_cu ? &type_dcu : NULL);
For lto vmlinux, the cus__merging_cu() checking takes
130us over total "pahole -J vmlinux" time 65sec as the function bail out
earlier due to detecting a merging cu condition.
For non-lto vmlinux, the cus__merging_cu() checking takes
~171368us over total pahole time 36sec, roughly 0.5% overhead.
[1] https://lore.kernel.org/bpf/20210328064121.2062927-1-yhs@fb.com/
Signed-off-by: Yonghong Song <yhs@fb.com>
---
dwarf_loader.c | 43 ++++++++++++++++++++++++-------------------
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/dwarf_loader.c b/dwarf_loader.c
index c1ca1a3..bd23751 100644
--- a/dwarf_loader.c
+++ b/dwarf_loader.c
@@ -2503,35 +2503,40 @@ static int cus__load_debug_types(struct cus *cus, struct conf_load *conf,
static bool cus__merging_cu(Dwarf *dw)
{
- uint8_t pointer_size, offset_size;
Dwarf_Off off = 0, noff;
size_t cuhl;
- int cnt = 0;
- /*
- * Just checking the first cu is not enough.
- * In linux, some C files may have LTO is disabled, e.g.,
- * e242db40be27 x86, vdso: disable LTO only for vDSO
- * d2dcd3e37475 x86, cpu: disable LTO for cpu.c
- * Fortunately, disabling LTO for a particular file in a LTO build
- * is rather an exception. Iterating 5 cu's to check whether
- * LTO is used or not should be enough.
- */
- while (dwarf_nextcu(dw, off, &noff, &cuhl, NULL, &pointer_size,
- &offset_size) == 0) {
+ while (dwarf_nextcu (dw, off, &noff, &cuhl, NULL, NULL, NULL) == 0) {
Dwarf_Die die_mem;
Dwarf_Die *cu_die = dwarf_offdie(dw, off + cuhl, &die_mem);
if (cu_die == NULL)
break;
- if (++cnt > 5)
- break;
+ Dwarf_Off offset = 0;
+ while (true) {
+ size_t length;
+ Dwarf_Abbrev *abbrev = dwarf_getabbrev (cu_die, offset, &length);
+ if (abbrev == NULL || abbrev == DWARF_END_ABBREV)
+ break;
- const char *producer = attr_string(cu_die, DW_AT_producer);
- if (strstr(producer, "clang version") != NULL &&
- strstr(producer, "-flto") != NULL)
- return true;
+ size_t attrcnt;
+ if (dwarf_getattrcnt (abbrev, &attrcnt) != 0)
+ return false;
+
+ unsigned int attr_num, attr_form;
+ Dwarf_Off aboffset;
+ size_t j;
+ for (j = 0; j < attrcnt; ++j) {
+ if (dwarf_getabbrevattr (abbrev, j, &attr_num, &attr_form,
+ &aboffset))
+ return false;
+ if (attr_form == DW_FORM_ref_addr)
+ return true;
+ }
+
+ offset += length;
+ }
off = noff;
}
--
2.30.2
^ permalink raw reply related [flat|nested] 33+ messages in thread
* [PATCH dwarves 2/2] dwarf_loader: check .notes section for lto build info
2021-04-01 2:58 [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu() Yonghong Song
2021-04-01 2:58 ` [PATCH dwarves 1/2] dwarf_loader: check .debug_abbrev for cross-cu references Yonghong Song
@ 2021-04-01 2:58 ` Yonghong Song
2021-04-01 12:59 ` [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu() Arnaldo Carvalho de Melo
` (2 subsequent siblings)
4 siblings, 0 replies; 33+ messages in thread
From: Yonghong Song @ 2021-04-01 2:58 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, dwarves
Cc: Alexei Starovoitov, Andrii Nakryiko, Bill Wendling, bpf,
David Blaikie, Fāng-ruì Sòng, kernel-team,
Nick Desaulniers
In [1], linux introduced a note with type BUILD_COMPILER_LTO_INFO.
If this note type exist, there is no need to scan .debug_abbrev
section for cross-cu reference. With a kernel built with [1],
the cus__merging_cu() overhead is about 3us for either
lto or non-lto vmlinux.
[1] https://lore.kernel.org/bpf/20210401012406.1800957-1-yhs@fb.com/
Signed-off-by: Yonghong Song <yhs@fb.com>
---
dwarf_loader.c | 33 +++++++++++++++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/dwarf_loader.c b/dwarf_loader.c
index bd23751..026d137 100644
--- a/dwarf_loader.c
+++ b/dwarf_loader.c
@@ -2501,8 +2501,37 @@ static int cus__load_debug_types(struct cus *cus, struct conf_load *conf,
return 0;
}
-static bool cus__merging_cu(Dwarf *dw)
+/* Match the define in linux:include/linux/elfnote.h */
+#define LINUX_ELFNOTE_BUILD_LTO 0x101
+
+static bool cus__merging_cu(Dwarf *dw, Elf *elf)
{
+ Elf_Scn *section = NULL;
+ while ((section = elf_nextscn(elf, section)) != 0) {
+ GElf_Shdr header;
+ if (!gelf_getshdr(section, &header))
+ continue;
+
+ if (header.sh_type != SHT_NOTE)
+ continue;
+
+ Elf_Data *data = NULL;
+ while ((data = elf_getdata(section, data)) != 0) {
+ size_t name_off, desc_off, offset = 0;
+ GElf_Nhdr hdr;
+ while ((offset = gelf_getnote(data, offset, &hdr, &name_off, &desc_off)) != 0) {
+ if (hdr.n_type != LINUX_ELFNOTE_BUILD_LTO)
+ continue;
+
+ /* owner is Linux */
+ if (strcmp((char *)data->d_buf + name_off, "Linux") != 0)
+ continue;
+
+ return *(int *)(data->d_buf + desc_off) != 0;
+ }
+ }
+ }
+
Dwarf_Off off = 0, noff;
size_t cuhl;
@@ -2649,7 +2678,7 @@ static int cus__load_module(struct cus *cus, struct conf_load *conf,
}
}
- if (cus__merging_cu(dw)) {
+ if (cus__merging_cu(dw, elf)) {
res = cus__merge_and_process_cu(cus, conf, mod, dw, elf, filename,
build_id, build_id_len,
type_cu ? &type_dcu : NULL);
--
2.30.2
^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-01 2:58 [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu() Yonghong Song
2021-04-01 2:58 ` [PATCH dwarves 1/2] dwarf_loader: check .debug_abbrev for cross-cu references Yonghong Song
2021-04-01 2:58 ` [PATCH dwarves 2/2] dwarf_loader: check .notes section for lto build info Yonghong Song
@ 2021-04-01 12:59 ` Arnaldo Carvalho de Melo
2021-04-01 18:50 ` Nick Desaulniers
2021-04-01 19:35 ` Bill Wendling
4 siblings, 0 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-01 12:59 UTC (permalink / raw)
To: Yonghong Song
Cc: Arnaldo Carvalho de Melo, dwarves, Alexei Starovoitov,
Andrii Nakryiko, Bill Wendling, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Wed, Mar 31, 2021 at 07:58:15PM -0700, Yonghong Song escreveu:
> Function cus__merging_cu() is introduced in Commit 39227909db3c
> ("dwarf_loader: Permit merging all DWARF CU's for clang LTO built
> binary") to test whether cross-cu references may happen.
> The original implementation anticipates compilation flags
> in dwarf, but later some concerns about binary size surfaced
> and the decision is to scan .debug_abbrev as a faster way
> to check cross-cu references. Also putting a note in vmlinux
> to indicate whether lto is enabled for built or not can
> provide a much faster way.
Great work! Reviewing/testing right now.
- Arnaldo
> This patch set implemented this two approaches, first
> checking the note (in Patch #2), if not found, then
> check .debug_abbrev (in Patch #1).
>
> Yonghong Song (2):
> dwarf_loader: check .debug_abbrev for cross-cu references
> dwarf_loader: check .notes section for lto build info
>
> dwarf_loader.c | 76 ++++++++++++++++++++++++++++++++++++--------------
> 1 file changed, 55 insertions(+), 21 deletions(-)
>
> --
> 2.30.2
>
--
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-01 2:58 [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu() Yonghong Song
` (2 preceding siblings ...)
2021-04-01 12:59 ` [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu() Arnaldo Carvalho de Melo
@ 2021-04-01 18:50 ` Nick Desaulniers
2021-04-01 19:35 ` Bill Wendling
4 siblings, 0 replies; 33+ messages in thread
From: Nick Desaulniers @ 2021-04-01 18:50 UTC (permalink / raw)
To: Yonghong Song
Cc: Arnaldo Carvalho de Melo, dwarves, Alexei Starovoitov,
Andrii Nakryiko, Bill Wendling, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, clang-built-linux
On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
>
> Function cus__merging_cu() is introduced in Commit 39227909db3c
> ("dwarf_loader: Permit merging all DWARF CU's for clang LTO built
> binary") to test whether cross-cu references may happen.
> The original implementation anticipates compilation flags
> in dwarf, but later some concerns about binary size surfaced
> and the decision is to scan .debug_abbrev as a faster way
> to check cross-cu references. Also putting a note in vmlinux
> to indicate whether lto is enabled for built or not can
> provide a much faster way.
>
> This patch set implemented this two approaches, first
> checking the note (in Patch #2), if not found, then
> check .debug_abbrev (in Patch #1).
For the series:
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
(Noting for others on our mailing list:
https://lore.kernel.org/linux-kbuild/20210401012406.1800957-1-yhs@fb.com/
is a series of kernel patches required to test this. I had feedback on
the kernel patches, but this approach in pahole LGTM since I think
using simple notes in ELF is a good approach).
>
> Yonghong Song (2):
> dwarf_loader: check .debug_abbrev for cross-cu references
> dwarf_loader: check .notes section for lto build info
>
> dwarf_loader.c | 76 ++++++++++++++++++++++++++++++++++++--------------
> 1 file changed, 55 insertions(+), 21 deletions(-)
>
> --
> 2.30.2
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 1/2] dwarf_loader: check .debug_abbrev for cross-cu references
2021-04-01 2:58 ` [PATCH dwarves 1/2] dwarf_loader: check .debug_abbrev for cross-cu references Yonghong Song
@ 2021-04-01 18:52 ` Nick Desaulniers
2021-04-01 19:36 ` Arnaldo
0 siblings, 1 reply; 33+ messages in thread
From: Nick Desaulniers @ 2021-04-01 18:52 UTC (permalink / raw)
To: Yonghong Song
Cc: Arnaldo Carvalho de Melo, dwarves, Alexei Starovoitov,
Andrii Nakryiko, Bill Wendling, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, David Blaikie
On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
>
> Commit 39227909db3c checked compilation flags to see
> whether the binary is built with lto or not (-flto).
> Currently, for clang lto build, default setting
> won't put compilation flags in dwarf due to size
> concern.
>
> David Blaikie suggested in [1] to scan through .debug_abbrev
> for DW_FORM_ref_addr which should be most faster than
> scanning through cu's. This patch implemented this
> suggestion and replaced the previous compilation flag
> matching approach. Indeed, it seems that the overhead
> for this approach is indeed managable.
>
> I did some change to measure the overhead of cus_merging_cu():
> @@ -2650,7 +2652,15 @@ static int cus__load_module(struct cus *cus, struct conf_load *conf,
> }
> }
>
> - if (cus__merging_cu(dw)) {
> + bool do_merging;
> + struct timeval start, end;
> + gettimeofday(&start, NULL);
> + do_merging = cus__merging_cu(dw);
> + gettimeofday(&end, NULL);
> + fprintf(stderr, "%ld %ld -> %ld %ld\n", start.tv_sec, start.tv_usec,
> + end.tv_sec, end.tv_usec);
> +
> + if (do_merging) {
> res = cus__merge_and_process_cu(cus, conf, mod, dw, elf, filename,
> build_id, build_id_len,
> type_cu ? &type_dcu : NULL);
>
> For lto vmlinux, the cus__merging_cu() checking takes
> 130us over total "pahole -J vmlinux" time 65sec as the function bail out
> earlier due to detecting a merging cu condition.
> For non-lto vmlinux, the cus__merging_cu() checking takes
> ~171368us over total pahole time 36sec, roughly 0.5% overhead.
>
> [1] https://lore.kernel.org/bpf/20210328064121.2062927-1-yhs@fb.com/
>
It might be a nice little touch to add:
Suggested-by: David Blaikie <blaikie@google.com>
> Signed-off-by: Yonghong Song <yhs@fb.com>
> ---
> dwarf_loader.c | 43 ++++++++++++++++++++++++-------------------
> 1 file changed, 24 insertions(+), 19 deletions(-)
>
> diff --git a/dwarf_loader.c b/dwarf_loader.c
> index c1ca1a3..bd23751 100644
> --- a/dwarf_loader.c
> +++ b/dwarf_loader.c
> @@ -2503,35 +2503,40 @@ static int cus__load_debug_types(struct cus *cus, struct conf_load *conf,
>
> static bool cus__merging_cu(Dwarf *dw)
> {
> - uint8_t pointer_size, offset_size;
> Dwarf_Off off = 0, noff;
> size_t cuhl;
> - int cnt = 0;
>
> - /*
> - * Just checking the first cu is not enough.
> - * In linux, some C files may have LTO is disabled, e.g.,
> - * e242db40be27 x86, vdso: disable LTO only for vDSO
> - * d2dcd3e37475 x86, cpu: disable LTO for cpu.c
> - * Fortunately, disabling LTO for a particular file in a LTO build
> - * is rather an exception. Iterating 5 cu's to check whether
> - * LTO is used or not should be enough.
> - */
> - while (dwarf_nextcu(dw, off, &noff, &cuhl, NULL, &pointer_size,
> - &offset_size) == 0) {
> + while (dwarf_nextcu (dw, off, &noff, &cuhl, NULL, NULL, NULL) == 0) {
> Dwarf_Die die_mem;
> Dwarf_Die *cu_die = dwarf_offdie(dw, off + cuhl, &die_mem);
>
> if (cu_die == NULL)
> break;
>
> - if (++cnt > 5)
> - break;
> + Dwarf_Off offset = 0;
> + while (true) {
> + size_t length;
> + Dwarf_Abbrev *abbrev = dwarf_getabbrev (cu_die, offset, &length);
> + if (abbrev == NULL || abbrev == DWARF_END_ABBREV)
> + break;
>
> - const char *producer = attr_string(cu_die, DW_AT_producer);
> - if (strstr(producer, "clang version") != NULL &&
> - strstr(producer, "-flto") != NULL)
> - return true;
> + size_t attrcnt;
> + if (dwarf_getattrcnt (abbrev, &attrcnt) != 0)
> + return false;
> +
> + unsigned int attr_num, attr_form;
> + Dwarf_Off aboffset;
> + size_t j;
> + for (j = 0; j < attrcnt; ++j) {
> + if (dwarf_getabbrevattr (abbrev, j, &attr_num, &attr_form,
> + &aboffset))
> + return false;
> + if (attr_form == DW_FORM_ref_addr)
> + return true;
> + }
> +
> + offset += length;
> + }
>
> off = noff;
> }
> --
> 2.30.2
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-01 2:58 [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu() Yonghong Song
` (3 preceding siblings ...)
2021-04-01 18:50 ` Nick Desaulniers
@ 2021-04-01 19:35 ` Bill Wendling
2021-04-01 20:56 ` Bill Wendling
2021-04-02 13:27 ` Arnaldo Carvalho de Melo
4 siblings, 2 replies; 33+ messages in thread
From: Bill Wendling @ 2021-04-01 19:35 UTC (permalink / raw)
To: Yonghong Song
Cc: Arnaldo Carvalho de Melo, dwarves, Alexei Starovoitov,
Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
>
> Function cus__merging_cu() is introduced in Commit 39227909db3c
> ("dwarf_loader: Permit merging all DWARF CU's for clang LTO built
> binary") to test whether cross-cu references may happen.
> The original implementation anticipates compilation flags
> in dwarf, but later some concerns about binary size surfaced
> and the decision is to scan .debug_abbrev as a faster way
> to check cross-cu references. Also putting a note in vmlinux
> to indicate whether lto is enabled for built or not can
> provide a much faster way.
>
> This patch set implemented this two approaches, first
> checking the note (in Patch #2), if not found, then
> check .debug_abbrev (in Patch #1).
>
> Yonghong Song (2):
> dwarf_loader: check .debug_abbrev for cross-cu references
> dwarf_loader: check .notes section for lto build info
>
> dwarf_loader.c | 76 ++++++++++++++++++++++++++++++++++++--------------
> 1 file changed, 55 insertions(+), 21 deletions(-)
>
With this series of patches, the compilation passes for me with
ThinLTO. You may add this if you like:
Tested-by: Bill Wendling <morbo@google.com>
Thanks!
-bw
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 1/2] dwarf_loader: check .debug_abbrev for cross-cu references
2021-04-01 18:52 ` Nick Desaulniers
@ 2021-04-01 19:36 ` Arnaldo
2021-04-01 20:54 ` Yonghong Song
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo @ 2021-04-01 19:36 UTC (permalink / raw)
To: Nick Desaulniers, Yonghong Song
Cc: dwarves, Alexei Starovoitov, Andrii Nakryiko, Bill Wendling, bpf,
David Blaikie, Fāng-ruì Sòng, kernel-team,
David Blaikie
On April 1, 2021 3:52:05 PM GMT-03:00, Nick Desaulniers <ndesaulniers@google.com> wrote:
>On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
>>
>> Commit 39227909db3c checked compilation flags to see
>> whether the binary is built with lto or not (-flto).
>> Currently, for clang lto build, default setting
>> won't put compilation flags in dwarf due to size
>> concern.
>>
>> David Blaikie suggested in [1] to scan through .debug_abbrev
>> for DW_FORM_ref_addr which should be most faster than
>> scanning through cu's. This patch implemented this
>> suggestion and replaced the previous compilation flag
>> matching approach. Indeed, it seems that the overhead
>> for this approach is indeed managable.
>>
>> I did some change to measure the overhead of cus_merging_cu():
>> @@ -2650,7 +2652,15 @@ static int cus__load_module(struct cus *cus,
>struct conf_load *conf,
>> }
>> }
>>
>> - if (cus__merging_cu(dw)) {
>> + bool do_merging;
>> + struct timeval start, end;
>> + gettimeofday(&start, NULL);
>> + do_merging = cus__merging_cu(dw);
>> + gettimeofday(&end, NULL);
>> + fprintf(stderr, "%ld %ld -> %ld %ld\n", start.tv_sec,
>start.tv_usec,
>> + end.tv_sec, end.tv_usec);
>> +
>> + if (do_merging) {
>> res = cus__merge_and_process_cu(cus, conf, mod, dw,
>elf, filename,
>> build_id,
>build_id_len,
>> type_cu ? &type_dcu
>: NULL);
>>
>> For lto vmlinux, the cus__merging_cu() checking takes
>> 130us over total "pahole -J vmlinux" time 65sec as the function bail
>out
>> earlier due to detecting a merging cu condition.
>> For non-lto vmlinux, the cus__merging_cu() checking takes
>> ~171368us over total pahole time 36sec, roughly 0.5% overhead.
>>
>> [1] https://lore.kernel.org/bpf/20210328064121.2062927-1-yhs@fb.com/
>>
>
>It might be a nice little touch to add:
>
>Suggested-by: David Blaikie <blaikie@google.com>
Sure, this is something that is becoming the norm, be it from patch submitters, or, that being somehow lost, by the maintainer.
I think this is not just fair, but documents what actually happened and encourage people to share ideas more freely and quickly.
I'll do it in this specific case.
if I failed to do so I'm the past, I'm sorry.
- Arnaldo
>
>> Signed-off-by: Yonghong Song <yhs@fb.com>
>> ---
>> dwarf_loader.c | 43 ++++++++++++++++++++++++-------------------
>> 1 file changed, 24 insertions(+), 19 deletions(-)
>>
>> diff --git a/dwarf_loader.c b/dwarf_loader.c
>> index c1ca1a3..bd23751 100644
>> --- a/dwarf_loader.c
>> +++ b/dwarf_loader.c
>> @@ -2503,35 +2503,40 @@ static int cus__load_debug_types(struct cus
>*cus, struct conf_load *conf,
>>
>> static bool cus__merging_cu(Dwarf *dw)
>> {
>> - uint8_t pointer_size, offset_size;
>> Dwarf_Off off = 0, noff;
>> size_t cuhl;
>> - int cnt = 0;
>>
>> - /*
>> - * Just checking the first cu is not enough.
>> - * In linux, some C files may have LTO is disabled, e.g.,
>> - * e242db40be27 x86, vdso: disable LTO only for vDSO
>> - * d2dcd3e37475 x86, cpu: disable LTO for cpu.c
>> - * Fortunately, disabling LTO for a particular file in a LTO
>build
>> - * is rather an exception. Iterating 5 cu's to check whether
>> - * LTO is used or not should be enough.
>> - */
>> - while (dwarf_nextcu(dw, off, &noff, &cuhl, NULL,
>&pointer_size,
>> - &offset_size) == 0) {
>> + while (dwarf_nextcu (dw, off, &noff, &cuhl, NULL, NULL, NULL)
>== 0) {
>> Dwarf_Die die_mem;
>> Dwarf_Die *cu_die = dwarf_offdie(dw, off + cuhl,
>&die_mem);
>>
>> if (cu_die == NULL)
>> break;
>>
>> - if (++cnt > 5)
>> - break;
>> + Dwarf_Off offset = 0;
>> + while (true) {
>> + size_t length;
>> + Dwarf_Abbrev *abbrev = dwarf_getabbrev
>(cu_die, offset, &length);
>> + if (abbrev == NULL || abbrev ==
>DWARF_END_ABBREV)
>> + break;
>>
>> - const char *producer = attr_string(cu_die,
>DW_AT_producer);
>> - if (strstr(producer, "clang version") != NULL &&
>> - strstr(producer, "-flto") != NULL)
>> - return true;
>> + size_t attrcnt;
>> + if (dwarf_getattrcnt (abbrev, &attrcnt) != 0)
>> + return false;
>> +
>> + unsigned int attr_num, attr_form;
>> + Dwarf_Off aboffset;
>> + size_t j;
>> + for (j = 0; j < attrcnt; ++j) {
>> + if (dwarf_getabbrevattr (abbrev, j,
>&attr_num, &attr_form,
>> + &aboffset))
>> + return false;
>> + if (attr_form == DW_FORM_ref_addr)
>> + return true;
>> + }
>> +
>> + offset += length;
>> + }
>>
>> off = noff;
>> }
>> --
>> 2.30.2
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 1/2] dwarf_loader: check .debug_abbrev for cross-cu references
2021-04-01 19:36 ` Arnaldo
@ 2021-04-01 20:54 ` Yonghong Song
0 siblings, 0 replies; 33+ messages in thread
From: Yonghong Song @ 2021-04-01 20:54 UTC (permalink / raw)
To: Arnaldo, Nick Desaulniers
Cc: dwarves, Alexei Starovoitov, Andrii Nakryiko, Bill Wendling, bpf,
David Blaikie, Fāng-ruì Sòng, kernel-team,
David Blaikie
On 4/1/21 12:36 PM, Arnaldo wrote:
>
>
> On April 1, 2021 3:52:05 PM GMT-03:00, Nick Desaulniers <ndesaulniers@google.com> wrote:
>> On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
>>>
>>> Commit 39227909db3c checked compilation flags to see
>>> whether the binary is built with lto or not (-flto).
>>> Currently, for clang lto build, default setting
>>> won't put compilation flags in dwarf due to size
>>> concern.
>>>
>>> David Blaikie suggested in [1] to scan through .debug_abbrev
>>> for DW_FORM_ref_addr which should be most faster than
>>> scanning through cu's. This patch implemented this
>>> suggestion and replaced the previous compilation flag
>>> matching approach. Indeed, it seems that the overhead
>>> for this approach is indeed managable.
>>>
>>> I did some change to measure the overhead of cus_merging_cu():
>>> @@ -2650,7 +2652,15 @@ static int cus__load_module(struct cus *cus,
>> struct conf_load *conf,
>>> }
>>> }
>>>
>>> - if (cus__merging_cu(dw)) {
>>> + bool do_merging;
>>> + struct timeval start, end;
>>> + gettimeofday(&start, NULL);
>>> + do_merging = cus__merging_cu(dw);
>>> + gettimeofday(&end, NULL);
>>> + fprintf(stderr, "%ld %ld -> %ld %ld\n", start.tv_sec,
>> start.tv_usec,
>>> + end.tv_sec, end.tv_usec);
>>> +
>>> + if (do_merging) {
>>> res = cus__merge_and_process_cu(cus, conf, mod, dw,
>> elf, filename,
>>> build_id,
>> build_id_len,
>>> type_cu ? &type_dcu
>> : NULL);
>>>
>>> For lto vmlinux, the cus__merging_cu() checking takes
>>> 130us over total "pahole -J vmlinux" time 65sec as the function bail
>> out
>>> earlier due to detecting a merging cu condition.
>>> For non-lto vmlinux, the cus__merging_cu() checking takes
>>> ~171368us over total pahole time 36sec, roughly 0.5% overhead.
>>>
>>> [1] https://lore.kernel.org/bpf/20210328064121.2062927-1-yhs@fb.com/
>>>
>>
>> It might be a nice little touch to add:
>>
>> Suggested-by: David Blaikie <blaikie@google.com>
>
> Sure, this is something that is becoming the norm, be it from patch submitters, or, that being somehow lost, by the maintainer.
>
> I think this is not just fair, but documents what actually happened and encourage people to share ideas more freely and quickly.
>
> I'll do it in this specific case.
Thanks, Arnaldo. Sometimes I indeed missed to add necessary tags like
Suggested-by, Reported-by, etc, esp. if I want to push the patch
out ASAP. Thanks for correcting this!
>
> if I failed to do so I'm the past, I'm sorry.
>
> - Arnaldo
>>
>>> Signed-off-by: Yonghong Song <yhs@fb.com>
>>> ---
>>> dwarf_loader.c | 43 ++++++++++++++++++++++++-------------------
>>> 1 file changed, 24 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/dwarf_loader.c b/dwarf_loader.c
>>> index c1ca1a3..bd23751 100644
>>> --- a/dwarf_loader.c
>>> +++ b/dwarf_loader.c
>>> @@ -2503,35 +2503,40 @@ static int cus__load_debug_types(struct cus
>> *cus, struct conf_load *conf,
>>>
>>> static bool cus__merging_cu(Dwarf *dw)
>>> {
>>> - uint8_t pointer_size, offset_size;
>>> Dwarf_Off off = 0, noff;
>>> size_t cuhl;
>>> - int cnt = 0;
>>>
>>> - /*
>>> - * Just checking the first cu is not enough.
>>> - * In linux, some C files may have LTO is disabled, e.g.,
>>> - * e242db40be27 x86, vdso: disable LTO only for vDSO
>>> - * d2dcd3e37475 x86, cpu: disable LTO for cpu.c
>>> - * Fortunately, disabling LTO for a particular file in a LTO
>> build
>>> - * is rather an exception. Iterating 5 cu's to check whether
>>> - * LTO is used or not should be enough.
>>> - */
>>> - while (dwarf_nextcu(dw, off, &noff, &cuhl, NULL,
>> &pointer_size,
>>> - &offset_size) == 0) {
>>> + while (dwarf_nextcu (dw, off, &noff, &cuhl, NULL, NULL, NULL)
>> == 0) {
>>> Dwarf_Die die_mem;
>>> Dwarf_Die *cu_die = dwarf_offdie(dw, off + cuhl,
>> &die_mem);
>>>
>>> if (cu_die == NULL)
>>> break;
>>>
>>> - if (++cnt > 5)
>>> - break;
>>> + Dwarf_Off offset = 0;
>>> + while (true) {
>>> + size_t length;
>>> + Dwarf_Abbrev *abbrev = dwarf_getabbrev
>> (cu_die, offset, &length);
>>> + if (abbrev == NULL || abbrev ==
>> DWARF_END_ABBREV)
>>> + break;
>>>
>>> - const char *producer = attr_string(cu_die,
>> DW_AT_producer);
>>> - if (strstr(producer, "clang version") != NULL &&
>>> - strstr(producer, "-flto") != NULL)
>>> - return true;
>>> + size_t attrcnt;
>>> + if (dwarf_getattrcnt (abbrev, &attrcnt) != 0)
>>> + return false;
>>> +
>>> + unsigned int attr_num, attr_form;
>>> + Dwarf_Off aboffset;
>>> + size_t j;
>>> + for (j = 0; j < attrcnt; ++j) {
>>> + if (dwarf_getabbrevattr (abbrev, j,
>> &attr_num, &attr_form,
>>> + &aboffset))
>>> + return false;
>>> + if (attr_form == DW_FORM_ref_addr)
>>> + return true;
>>> + }
>>> +
>>> + offset += length;
>>> + }
>>>
>>> off = noff;
>>> }
>>> --
>>> 2.30.2
>>>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-01 19:35 ` Bill Wendling
@ 2021-04-01 20:56 ` Bill Wendling
2021-04-01 21:59 ` Yonghong Song
2021-04-06 17:09 ` Jiri Olsa
2021-04-02 13:27 ` Arnaldo Carvalho de Melo
1 sibling, 2 replies; 33+ messages in thread
From: Bill Wendling @ 2021-04-01 20:56 UTC (permalink / raw)
To: Yonghong Song
Cc: Arnaldo Carvalho de Melo, dwarves, Alexei Starovoitov,
Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
On Thu, Apr 1, 2021 at 12:35 PM Bill Wendling <morbo@google.com> wrote:
>
> On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
> >
> > Function cus__merging_cu() is introduced in Commit 39227909db3c
> > ("dwarf_loader: Permit merging all DWARF CU's for clang LTO built
> > binary") to test whether cross-cu references may happen.
> > The original implementation anticipates compilation flags
> > in dwarf, but later some concerns about binary size surfaced
> > and the decision is to scan .debug_abbrev as a faster way
> > to check cross-cu references. Also putting a note in vmlinux
> > to indicate whether lto is enabled for built or not can
> > provide a much faster way.
> >
> > This patch set implemented this two approaches, first
> > checking the note (in Patch #2), if not found, then
> > check .debug_abbrev (in Patch #1).
> >
> > Yonghong Song (2):
> > dwarf_loader: check .debug_abbrev for cross-cu references
> > dwarf_loader: check .notes section for lto build info
> >
> > dwarf_loader.c | 76 ++++++++++++++++++++++++++++++++++++--------------
> > 1 file changed, 55 insertions(+), 21 deletions(-)
> >
> With this series of patches, the compilation passes for me with
> ThinLTO. You may add this if you like:
>
> Tested-by: Bill Wendling <morbo@google.com>
I did notice these warnings following the "pahole -J .tmp_vmlinux.btf"
command. I don't know the severity of them, but it might be good to
investigate.
$ ./tools/bpf/resolve_btfids/resolve_btfids vmlinux
BTFIDS vmlinux
WARN: multiple IDs found for 'inode': 355, 8746 - using 355
WARN: multiple IDs found for 'file': 588, 8779 - using 588
WARN: multiple IDs found for 'path': 411, 8780 - using 411
WARN: multiple IDs found for 'seq_file': 1414, 8836 - using 1414
WARN: multiple IDs found for 'vm_area_struct': 538, 8873 - using 538
WARN: multiple IDs found for 'task_struct': 28, 8880 - using 28
WARN: multiple IDs found for 'inode': 355, 9484 - using 355
WARN: multiple IDs found for 'file': 588, 9517 - using 588
WARN: multiple IDs found for 'path': 411, 9518 - using 411
WARN: multiple IDs found for 'seq_file': 1414, 9578 - using 1414
WARN: multiple IDs found for 'vm_area_struct': 538, 9615 - using 538
WARN: multiple IDs found for 'task_struct': 28, 9622 - using 28
WARN: multiple IDs found for 'seq_file': 1414, 12223 - using 1414
WARN: multiple IDs found for 'file': 588, 12237 - using 588
WARN: multiple IDs found for 'path': 411, 12238 - using 411
...
-bw
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-01 20:56 ` Bill Wendling
@ 2021-04-01 21:59 ` Yonghong Song
2021-04-02 19:44 ` Bill Wendling
2021-04-06 17:09 ` Jiri Olsa
1 sibling, 1 reply; 33+ messages in thread
From: Yonghong Song @ 2021-04-01 21:59 UTC (permalink / raw)
To: Bill Wendling
Cc: Arnaldo Carvalho de Melo, dwarves, Alexei Starovoitov,
Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
On 4/1/21 1:56 PM, Bill Wendling wrote:
> On Thu, Apr 1, 2021 at 12:35 PM Bill Wendling <morbo@google.com> wrote:
>>
>> On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
>>>
>>> Function cus__merging_cu() is introduced in Commit 39227909db3c
>>> ("dwarf_loader: Permit merging all DWARF CU's for clang LTO built
>>> binary") to test whether cross-cu references may happen.
>>> The original implementation anticipates compilation flags
>>> in dwarf, but later some concerns about binary size surfaced
>>> and the decision is to scan .debug_abbrev as a faster way
>>> to check cross-cu references. Also putting a note in vmlinux
>>> to indicate whether lto is enabled for built or not can
>>> provide a much faster way.
>>>
>>> This patch set implemented this two approaches, first
>>> checking the note (in Patch #2), if not found, then
>>> check .debug_abbrev (in Patch #1).
>>>
>>> Yonghong Song (2):
>>> dwarf_loader: check .debug_abbrev for cross-cu references
>>> dwarf_loader: check .notes section for lto build info
>>>
>>> dwarf_loader.c | 76 ++++++++++++++++++++++++++++++++++++--------------
>>> 1 file changed, 55 insertions(+), 21 deletions(-)
>>>
>> With this series of patches, the compilation passes for me with
>> ThinLTO. You may add this if you like:
>>
>> Tested-by: Bill Wendling <morbo@google.com>
>
> I did notice these warnings following the "pahole -J .tmp_vmlinux.btf"
> command. I don't know the severity of them, but it might be good to
> investigate.
>
> $ ./tools/bpf/resolve_btfids/resolve_btfids vmlinux
> BTFIDS vmlinux
> WARN: multiple IDs found for 'inode': 355, 8746 - using 355
> WARN: multiple IDs found for 'file': 588, 8779 - using 588
> WARN: multiple IDs found for 'path': 411, 8780 - using 411
> WARN: multiple IDs found for 'seq_file': 1414, 8836 - using 1414
> WARN: multiple IDs found for 'vm_area_struct': 538, 8873 - using 538
> WARN: multiple IDs found for 'task_struct': 28, 8880 - using 28
> WARN: multiple IDs found for 'inode': 355, 9484 - using 355
> WARN: multiple IDs found for 'file': 588, 9517 - using 588
> WARN: multiple IDs found for 'path': 411, 9518 - using 411
> WARN: multiple IDs found for 'seq_file': 1414, 9578 - using 1414
> WARN: multiple IDs found for 'vm_area_struct': 538, 9615 - using 538
> WARN: multiple IDs found for 'task_struct': 28, 9622 - using 28
> WARN: multiple IDs found for 'seq_file': 1414, 12223 - using 1414
> WARN: multiple IDs found for 'file': 588, 12237 - using 588
> WARN: multiple IDs found for 'path': 411, 12238 - using 411
> ...
I didn't see it with my config. Maybe you can share your config file?
>
> -bw
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-01 19:35 ` Bill Wendling
2021-04-01 20:56 ` Bill Wendling
@ 2021-04-02 13:27 ` Arnaldo Carvalho de Melo
2021-04-02 14:34 ` Yonghong Song
1 sibling, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-02 13:27 UTC (permalink / raw)
To: Bill Wendling
Cc: Yonghong Song, Arnaldo Carvalho de Melo, dwarves,
Alexei Starovoitov, Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Thu, Apr 01, 2021 at 12:35:45PM -0700, Bill Wendling escreveu:
> On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
> > Function cus__merging_cu() is introduced in Commit 39227909db3c
> > ("dwarf_loader: Permit merging all DWARF CU's for clang LTO built
> > binary") to test whether cross-cu references may happen.
> > The original implementation anticipates compilation flags
> > in dwarf, but later some concerns about binary size surfaced
> > and the decision is to scan .debug_abbrev as a faster way
> > to check cross-cu references. Also putting a note in vmlinux
> > to indicate whether lto is enabled for built or not can
> > provide a much faster way.
> > This patch set implemented this two approaches, first
> > checking the note (in Patch #2), if not found, then
> > check .debug_abbrev (in Patch #1).
> > Yonghong Song (2):
> > dwarf_loader: check .debug_abbrev for cross-cu references
> > dwarf_loader: check .notes section for lto build info
> > dwarf_loader.c | 76 ++++++++++++++++++++++++++++++++++++--------------
> > 1 file changed, 55 insertions(+), 21 deletions(-)
> With this series of patches, the compilation passes for me with
> ThinLTO. You may add this if you like:
> Tested-by: Bill Wendling <morbo@google.com>
Thanks, added, and also this "Committer testing" section:
Committer testing:
Using a thin-LTO built vmlinux that doesn't have the
LINUX_ELFNOTE_BUILD_LTO note:
$ readelf --notes vmlinux.clang.thin.LTO
Displaying notes found in: .notes
Owner Data size Description
Xen 0x00000006 Unknown note type: (0x00000006)
description data: 6c 69 6e 75 78 00
Xen 0x00000004 Unknown note type: (0x00000007)
description data: 32 2e 36 00
Xen 0x00000008 Unknown note type: (0x00000005)
description data: 78 65 6e 2d 33 2e 30 00
Xen 0x00000008 Unknown note type: (0x00000003)
description data: 00 00 00 80 ff ff ff ff
Xen 0x00000008 Unknown note type: (0x0000000f)
description data: 00 00 00 00 80 00 00 00
Xen 0x00000008 NT_VERSION (version)
description data: c0 e1 33 83 ff ff ff ff
Xen 0x00000008 NT_ARCH (architecture)
description data: 00 20 00 81 ff ff ff ff
Xen 0x00000029 Unknown note type: (0x0000000a)
description data: 21 77 72 69 74 61 62 6c 65 5f 70 61 67 65 5f 74 61 62 6c 65 73 7c 70 61 65 5f 70 67 64 69 72 5f 61 62 6f 76 65 5f 34 67 62
Xen 0x00000004 Unknown note type: (0x00000011)
description data: 01 88 00 00
Xen 0x00000004 Unknown note type: (0x00000009)
description data: 79 65 73 00
Xen 0x00000008 Unknown note type: (0x00000008)
description data: 67 65 6e 65 72 69 63 00
Xen 0x00000010 Unknown note type: (0x0000000d)
description data: 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
Xen 0x00000004 Unknown note type: (0x0000000e)
description data: 01 00 00 00
Xen 0x00000004 Unknown note type: (0x00000010)
description data: 01 00 00 00
Xen 0x00000008 Unknown note type: (0x0000000c)
description data: 00 00 00 00 00 80 ff ff
Xen 0x00000008 Unknown note type: (0x00000004)
description data: 00 00 00 00 00 00 00 00
Xen 0x00000008 Unknown note type: (0x00000012)
description data: e0 02 00 01 00 00 00 00
Linux 0x00000017 OPEN
description data: 34 2e 31 39 2e 34 2d 33 30 30 2e 66 63 32 39 2e 78 38 36 5f 36 34 00
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 354f81317b1b3c35f3f81f8d9f04d0c8caccb09a
$
Then with one with the new ELF note stating that this binary was built
with LTO:
[acme@five pahole]$ readelf --notes vmlinux.clang.thin.LTO+ELF_note
Displaying notes found in: .notes
Owner Data size Description
Xen 0x00000006 Unknown note type: (0x00000006)
description data: 6c 69 6e 75 78 00
Xen 0x00000004 Unknown note type: (0x00000007)
description data: 32 2e 36 00
Xen 0x00000008 Unknown note type: (0x00000005)
description data: 78 65 6e 2d 33 2e 30 00
Xen 0x00000008 Unknown note type: (0x00000003)
description data: 00 00 00 80 ff ff ff ff
Xen 0x00000008 Unknown note type: (0x0000000f)
description data: 00 00 00 00 80 00 00 00
Xen 0x00000008 NT_VERSION (version)
description data: c0 e1 33 83 ff ff ff ff
Xen 0x00000008 NT_ARCH (architecture)
description data: 00 20 00 81 ff ff ff ff
Xen 0x00000029 Unknown note type: (0x0000000a)
description data: 21 77 72 69 74 61 62 6c 65 5f 70 61 67 65 5f 74 61 62 6c 65 73 7c 70 61 65 5f 70 67 64 69 72 5f 61 62 6f 76 65 5f 34 67 62
Xen 0x00000004 Unknown note type: (0x00000011)
description data: 01 88 00 00
Xen 0x00000004 Unknown note type: (0x00000009)
description data: 79 65 73 00
Xen 0x00000008 Unknown note type: (0x00000008)
description data: 67 65 6e 65 72 69 63 00
Xen 0x00000010 Unknown note type: (0x0000000d)
description data: 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
Xen 0x00000004 Unknown note type: (0x0000000e)
description data: 01 00 00 00
Xen 0x00000004 Unknown note type: (0x00000010)
description data: 01 00 00 00
Xen 0x00000008 Unknown note type: (0x0000000c)
description data: 00 00 00 00 00 80 ff ff
Xen 0x00000008 Unknown note type: (0x00000004)
description data: 00 00 00 00 00 00 00 00
Xen 0x00000008 Unknown note type: (0x00000012)
description data: e0 02 00 01 00 00 00 00
Linux 0x00000017 OPEN
description data: 34 2e 31 39 2e 34 2d 33 30 30 2e 66 63 32 39 2e 78 38 36 5f 36 34 00
Linux 0x00000004 func
description data: 01 00 00 00
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: aeba9ffc929acd3cd573b4d1afc8df9af4f3694d
$
Now to see the diff:
$ readelf --notes vmlinux.clang.thin.LTO+ELF_note > with-note
$ readelf --notes vmlinux.clang.thin.LTO > without-note
$ diff -u without-note with-note
--- without-note 2021-04-02 10:23:57.545349084 -0300
+++ with-note 2021-04-02 10:23:50.690196102 -0300
@@ -37,5 +37,7 @@
description data: e0 02 00 01 00 00 00 00
Linux 0x00000017 OPEN
description data: 34 2e 31 39 2e 34 2d 33 30 30 2e 66 63 32 39 2e 78 38 36 5f 36 34 00
+ Linux 0x00000004 func
+ description data: 01 00 00 00
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
- Build ID: 354f81317b1b3c35f3f81f8d9f04d0c8caccb09a
+ Build ID: aeba9ffc929acd3cd573b4d1afc8df9af4f3694d
$
Signed-off-by: Yonghong Song <yhs@fb.com>
Suggested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Tested-by: Bill Wendling <morbo@google.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: David Blaikie <dblaikie@gmail.com>
Cc: Fāng-ruì Sòng <maskray@google.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: bpf@vger.kernel.org
Cc: dwarves@vger.kernel.org
Cc: kernel-team@fb.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-02 13:27 ` Arnaldo Carvalho de Melo
@ 2021-04-02 14:34 ` Yonghong Song
0 siblings, 0 replies; 33+ messages in thread
From: Yonghong Song @ 2021-04-02 14:34 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Bill Wendling
Cc: Arnaldo Carvalho de Melo, dwarves, Alexei Starovoitov,
Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
On 4/2/21 6:27 AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Apr 01, 2021 at 12:35:45PM -0700, Bill Wendling escreveu:
>> On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
>
>>> Function cus__merging_cu() is introduced in Commit 39227909db3c
>>> ("dwarf_loader: Permit merging all DWARF CU's for clang LTO built
>>> binary") to test whether cross-cu references may happen.
>>> The original implementation anticipates compilation flags
>>> in dwarf, but later some concerns about binary size surfaced
>>> and the decision is to scan .debug_abbrev as a faster way
>>> to check cross-cu references. Also putting a note in vmlinux
>>> to indicate whether lto is enabled for built or not can
>>> provide a much faster way.
>
>>> This patch set implemented this two approaches, first
>>> checking the note (in Patch #2), if not found, then
>>> check .debug_abbrev (in Patch #1).
>
>>> Yonghong Song (2):
>>> dwarf_loader: check .debug_abbrev for cross-cu references
>>> dwarf_loader: check .notes section for lto build info
>
>>> dwarf_loader.c | 76 ++++++++++++++++++++++++++++++++++++--------------
>>> 1 file changed, 55 insertions(+), 21 deletions(-)
>
>> With this series of patches, the compilation passes for me with
>> ThinLTO. You may add this if you like:
>
>> Tested-by: Bill Wendling <morbo@google.com>
>
> Thanks, added, and also this "Committer testing" section:
>
> Committer testing:
>
> Using a thin-LTO built vmlinux that doesn't have the
> LINUX_ELFNOTE_BUILD_LTO note:
>
> $ readelf --notes vmlinux.clang.thin.LTO
>
> Displaying notes found in: .notes
> Owner Data size Description
> Xen 0x00000006 Unknown note type: (0x00000006)
> description data: 6c 69 6e 75 78 00
> Xen 0x00000004 Unknown note type: (0x00000007)
> description data: 32 2e 36 00
> Xen 0x00000008 Unknown note type: (0x00000005)
> description data: 78 65 6e 2d 33 2e 30 00
> Xen 0x00000008 Unknown note type: (0x00000003)
> description data: 00 00 00 80 ff ff ff ff
> Xen 0x00000008 Unknown note type: (0x0000000f)
> description data: 00 00 00 00 80 00 00 00
> Xen 0x00000008 NT_VERSION (version)
> description data: c0 e1 33 83 ff ff ff ff
> Xen 0x00000008 NT_ARCH (architecture)
> description data: 00 20 00 81 ff ff ff ff
> Xen 0x00000029 Unknown note type: (0x0000000a)
> description data: 21 77 72 69 74 61 62 6c 65 5f 70 61 67 65 5f 74 61 62 6c 65 73 7c 70 61 65 5f 70 67 64 69 72 5f 61 62 6f 76 65 5f 34 67 62
> Xen 0x00000004 Unknown note type: (0x00000011)
> description data: 01 88 00 00
> Xen 0x00000004 Unknown note type: (0x00000009)
> description data: 79 65 73 00
> Xen 0x00000008 Unknown note type: (0x00000008)
> description data: 67 65 6e 65 72 69 63 00
> Xen 0x00000010 Unknown note type: (0x0000000d)
> description data: 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
> Xen 0x00000004 Unknown note type: (0x0000000e)
> description data: 01 00 00 00
> Xen 0x00000004 Unknown note type: (0x00000010)
> description data: 01 00 00 00
> Xen 0x00000008 Unknown note type: (0x0000000c)
> description data: 00 00 00 00 00 80 ff ff
> Xen 0x00000008 Unknown note type: (0x00000004)
> description data: 00 00 00 00 00 00 00 00
> Xen 0x00000008 Unknown note type: (0x00000012)
> description data: e0 02 00 01 00 00 00 00
> Linux 0x00000017 OPEN
> description data: 34 2e 31 39 2e 34 2d 33 30 30 2e 66 63 32 39 2e 78 38 36 5f 36 34 00
> GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
> Build ID: 354f81317b1b3c35f3f81f8d9f04d0c8caccb09a
> $
>
> Then with one with the new ELF note stating that this binary was built
> with LTO:
>
> [acme@five pahole]$ readelf --notes vmlinux.clang.thin.LTO+ELF_note
>
> Displaying notes found in: .notes
> Owner Data size Description
> Xen 0x00000006 Unknown note type: (0x00000006)
> description data: 6c 69 6e 75 78 00
> Xen 0x00000004 Unknown note type: (0x00000007)
> description data: 32 2e 36 00
> Xen 0x00000008 Unknown note type: (0x00000005)
> description data: 78 65 6e 2d 33 2e 30 00
> Xen 0x00000008 Unknown note type: (0x00000003)
> description data: 00 00 00 80 ff ff ff ff
> Xen 0x00000008 Unknown note type: (0x0000000f)
> description data: 00 00 00 00 80 00 00 00
> Xen 0x00000008 NT_VERSION (version)
> description data: c0 e1 33 83 ff ff ff ff
> Xen 0x00000008 NT_ARCH (architecture)
> description data: 00 20 00 81 ff ff ff ff
> Xen 0x00000029 Unknown note type: (0x0000000a)
> description data: 21 77 72 69 74 61 62 6c 65 5f 70 61 67 65 5f 74 61 62 6c 65 73 7c 70 61 65 5f 70 67 64 69 72 5f 61 62 6f 76 65 5f 34 67 62
> Xen 0x00000004 Unknown note type: (0x00000011)
> description data: 01 88 00 00
> Xen 0x00000004 Unknown note type: (0x00000009)
> description data: 79 65 73 00
> Xen 0x00000008 Unknown note type: (0x00000008)
> description data: 67 65 6e 65 72 69 63 00
> Xen 0x00000010 Unknown note type: (0x0000000d)
> description data: 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
> Xen 0x00000004 Unknown note type: (0x0000000e)
> description data: 01 00 00 00
> Xen 0x00000004 Unknown note type: (0x00000010)
> description data: 01 00 00 00
> Xen 0x00000008 Unknown note type: (0x0000000c)
> description data: 00 00 00 00 00 80 ff ff
> Xen 0x00000008 Unknown note type: (0x00000004)
> description data: 00 00 00 00 00 00 00 00
> Xen 0x00000008 Unknown note type: (0x00000012)
> description data: e0 02 00 01 00 00 00 00
> Linux 0x00000017 OPEN
> description data: 34 2e 31 39 2e 34 2d 33 30 30 2e 66 63 32 39 2e 78 38 36 5f 36 34 00
> Linux 0x00000004 func
> description data: 01 00 00 00
> GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
> Build ID: aeba9ffc929acd3cd573b4d1afc8df9af4f3694d
> $
>
> Now to see the diff:
>
> $ readelf --notes vmlinux.clang.thin.LTO+ELF_note > with-note
> $ readelf --notes vmlinux.clang.thin.LTO > without-note
> $ diff -u without-note with-note
> --- without-note 2021-04-02 10:23:57.545349084 -0300
> +++ with-note 2021-04-02 10:23:50.690196102 -0300
> @@ -37,5 +37,7 @@
> description data: e0 02 00 01 00 00 00 00
> Linux 0x00000017 OPEN
> description data: 34 2e 31 39 2e 34 2d 33 30 30 2e 66 63 32 39 2e 78 38 36 5f 36 34 00
> + Linux 0x00000004 func
> + description data: 01 00 00 00
> GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
> - Build ID: 354f81317b1b3c35f3f81f8d9f04d0c8caccb09a
> + Build ID: aeba9ffc929acd3cd573b4d1afc8df9af4f3694d
> $
>
> Signed-off-by: Yonghong Song <yhs@fb.com>
> Suggested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> Tested-by: Bill Wendling <morbo@google.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Andrii Nakryiko <andrii@kernel.org>
> Cc: David Blaikie <dblaikie@gmail.com>
> Cc: Fāng-ruì Sòng <maskray@google.com>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Cc: bpf@vger.kernel.org
> Cc: dwarves@vger.kernel.org
> Cc: kernel-team@fb.com
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Looks great! Thanks a lot for detailed testing log and
Suggested-by/Tested-by/Cc list!
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-01 21:59 ` Yonghong Song
@ 2021-04-02 19:44 ` Bill Wendling
2021-04-06 13:22 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Bill Wendling @ 2021-04-02 19:44 UTC (permalink / raw)
To: Yonghong Song
Cc: Arnaldo Carvalho de Melo, dwarves, Alexei Starovoitov,
Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
I tried porting the .config we're using to the official branch and
couldn't replicate the problem. It's probably something local.
-bw
On Thu, Apr 1, 2021 at 3:00 PM Yonghong Song <yhs@fb.com> wrote:
>
>
>
> On 4/1/21 1:56 PM, Bill Wendling wrote:
> > On Thu, Apr 1, 2021 at 12:35 PM Bill Wendling <morbo@google.com> wrote:
> >>
> >> On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
> >>>
> >>> Function cus__merging_cu() is introduced in Commit 39227909db3c
> >>> ("dwarf_loader: Permit merging all DWARF CU's for clang LTO built
> >>> binary") to test whether cross-cu references may happen.
> >>> The original implementation anticipates compilation flags
> >>> in dwarf, but later some concerns about binary size surfaced
> >>> and the decision is to scan .debug_abbrev as a faster way
> >>> to check cross-cu references. Also putting a note in vmlinux
> >>> to indicate whether lto is enabled for built or not can
> >>> provide a much faster way.
> >>>
> >>> This patch set implemented this two approaches, first
> >>> checking the note (in Patch #2), if not found, then
> >>> check .debug_abbrev (in Patch #1).
> >>>
> >>> Yonghong Song (2):
> >>> dwarf_loader: check .debug_abbrev for cross-cu references
> >>> dwarf_loader: check .notes section for lto build info
> >>>
> >>> dwarf_loader.c | 76 ++++++++++++++++++++++++++++++++++++--------------
> >>> 1 file changed, 55 insertions(+), 21 deletions(-)
> >>>
> >> With this series of patches, the compilation passes for me with
> >> ThinLTO. You may add this if you like:
> >>
> >> Tested-by: Bill Wendling <morbo@google.com>
> >
> > I did notice these warnings following the "pahole -J .tmp_vmlinux.btf"
> > command. I don't know the severity of them, but it might be good to
> > investigate.
> >
> > $ ./tools/bpf/resolve_btfids/resolve_btfids vmlinux
> > BTFIDS vmlinux
> > WARN: multiple IDs found for 'inode': 355, 8746 - using 355
> > WARN: multiple IDs found for 'file': 588, 8779 - using 588
> > WARN: multiple IDs found for 'path': 411, 8780 - using 411
> > WARN: multiple IDs found for 'seq_file': 1414, 8836 - using 1414
> > WARN: multiple IDs found for 'vm_area_struct': 538, 8873 - using 538
> > WARN: multiple IDs found for 'task_struct': 28, 8880 - using 28
> > WARN: multiple IDs found for 'inode': 355, 9484 - using 355
> > WARN: multiple IDs found for 'file': 588, 9517 - using 588
> > WARN: multiple IDs found for 'path': 411, 9518 - using 411
> > WARN: multiple IDs found for 'seq_file': 1414, 9578 - using 1414
> > WARN: multiple IDs found for 'vm_area_struct': 538, 9615 - using 538
> > WARN: multiple IDs found for 'task_struct': 28, 9622 - using 28
> > WARN: multiple IDs found for 'seq_file': 1414, 12223 - using 1414
> > WARN: multiple IDs found for 'file': 588, 12237 - using 588
> > WARN: multiple IDs found for 'path': 411, 12238 - using 411
> > ...
>
> I didn't see it with my config. Maybe you can share your config file?
>
> >
> > -bw
> >
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-02 19:44 ` Bill Wendling
@ 2021-04-06 13:22 ` Arnaldo Carvalho de Melo
2021-04-06 13:23 ` Arnaldo Carvalho de Melo
2021-04-06 16:40 ` Arnaldo Carvalho de Melo
0 siblings, 2 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-06 13:22 UTC (permalink / raw)
To: Bill Wendling
Cc: Yonghong Song, Arnaldo Carvalho de Melo, dwarves,
Alexei Starovoitov, Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Fri, Apr 02, 2021 at 12:44:50PM -0700, Bill Wendling escreveu:
> I tried porting the .config we're using to the official branch and
> couldn't replicate the problem. It's probably something local.
>
> On Thu, Apr 1, 2021 at 3:00 PM Yonghong Song <yhs@fb.com> wrote:
> > On 4/1/21 1:56 PM, Bill Wendling wrote:
> > > On Thu, Apr 1, 2021 at 12:35 PM Bill Wendling <morbo@google.com> wrote:
> > >>
> > >> On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
> > >>>
> > >>> Function cus__merging_cu() is introduced in Commit 39227909db3c
> > >>> ("dwarf_loader: Permit merging all DWARF CU's for clang LTO built
> > >>> binary") to test whether cross-cu references may happen.
> > >>> The original implementation anticipates compilation flags
> > >>> in dwarf, but later some concerns about binary size surfaced
> > >>> and the decision is to scan .debug_abbrev as a faster way
> > >>> to check cross-cu references. Also putting a note in vmlinux
> > >>> to indicate whether lto is enabled for built or not can
> > >>> provide a much faster way.
> > >>>
> > >>> This patch set implemented this two approaches, first
> > >>> checking the note (in Patch #2), if not found, then
> > >>> check .debug_abbrev (in Patch #1).
> > >>>
> > >>> Yonghong Song (2):
> > >>> dwarf_loader: check .debug_abbrev for cross-cu references
> > >>> dwarf_loader: check .notes section for lto build info
> > >>>
> > >>> dwarf_loader.c | 76 ++++++++++++++++++++++++++++++++++++--------------
> > >>> 1 file changed, 55 insertions(+), 21 deletions(-)
> > >>>
> > >> With this series of patches, the compilation passes for me with
> > >> ThinLTO. You may add this if you like:
> > >>
> > >> Tested-by: Bill Wendling <morbo@google.com>
> > >
> > > I did notice these warnings following the "pahole -J .tmp_vmlinux.btf"
> > > command. I don't know the severity of them, but it might be good to
> > > investigate.
> > >
> > > $ ./tools/bpf/resolve_btfids/resolve_btfids vmlinux
> > > BTFIDS vmlinux
> > > WARN: multiple IDs found for 'inode': 355, 8746 - using 355
> > > WARN: multiple IDs found for 'file': 588, 8779 - using 588
> > > WARN: multiple IDs found for 'path': 411, 8780 - using 411
> > > WARN: multiple IDs found for 'seq_file': 1414, 8836 - using 1414
> > > WARN: multiple IDs found for 'vm_area_struct': 538, 8873 - using 538
> > > WARN: multiple IDs found for 'task_struct': 28, 8880 - using 28
> > > WARN: multiple IDs found for 'inode': 355, 9484 - using 355
> > > WARN: multiple IDs found for 'file': 588, 9517 - using 588
> > > WARN: multiple IDs found for 'path': 411, 9518 - using 411
> > > WARN: multiple IDs found for 'seq_file': 1414, 9578 - using 1414
> > > WARN: multiple IDs found for 'vm_area_struct': 538, 9615 - using 538
> > > WARN: multiple IDs found for 'task_struct': 28, 9622 - using 28
> > > WARN: multiple IDs found for 'seq_file': 1414, 12223 - using 1414
> > > WARN: multiple IDs found for 'file': 588, 12237 - using 588
> > > WARN: multiple IDs found for 'path': 411, 12238 - using 411
> > > ...
> >
> > I didn't see it with my config. Maybe you can share your config file?
I'm seeing these here:
[acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
[acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_thin_lto/ vmlinux
make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
GEN Makefile
DESCEND objtool
DESCEND bpf/resolve_btfids
CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
CALL /home/acme/git/bpf/scripts/checksyscalls.sh
CHK include/generated/compile.h
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
AR init/built-in.a
GEN .tmp_initcalls.lds
LTO vmlinux.o
OBJTOOL vmlinux.o
vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen2()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen2()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen2()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen2()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen4()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen4()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen4()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen4()+0x12: unsupported stack pointer realignment
MODPOST vmlinux.symvers
MODINFO modules.builtin.modinfo
GEN modules.builtin
LD .tmp_vmlinux.btf
BTF .btf.vmlinux.bin.o
LD .tmp_vmlinux.kallsyms1
KSYMS .tmp_vmlinux.kallsyms1.S
AS .tmp_vmlinux.kallsyms1.S
LD .tmp_vmlinux.kallsyms2
KSYMS .tmp_vmlinux.kallsyms2.S
AS .tmp_vmlinux.kallsyms2.S
LD vmlinux
BTFIDS vmlinux
WARN: multiple IDs found for 'inode': 232, 28822 - using 232
WARN: multiple IDs found for 'file': 374, 28855 - using 374
WARN: multiple IDs found for 'path': 379, 28856 - using 379
WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
WARN: multiple IDs found for 'inode': 232, 29345 - using 232
WARN: multiple IDs found for 'file': 374, 29429 - using 374
WARN: multiple IDs found for 'path': 379, 29430 - using 379
WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
SORTTAB vmlinux
SYSMAP System.map
make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
[acme@five pahole]$ clang -v
clang version 11.0.0 (Fedora 11.0.0-2.fc33)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
[acme@five pahole]$
[acme@five bpf]$ git log --oneline -10
49b9da70941c3c8a (HEAD -> bpf_perf_enable) kbuild: add an elfnote with type BUILD_COMPILER_LTO_INFO
5c4f082a143c786e kbuild: move LINUX_ELFNOTE_BUILD_SALT to elfnote.h
42c8b565decb3662 bpf: Introduce helpers to enable/disable perf event fds in a map
f73ea1eb4cce6637 (bpf-next/master, bpf-next/for-next) bpf: selftests: Specify CONFIG_DYNAMIC_FTRACE in the testing config
f07669df4c8df0b7 libbpf: Remove redundant semi-colon
6ac4c6f887f5a8ef bpf: Remove repeated struct btf_type declaration
2daae89666ad2532 bpf, cgroup: Delete repeated struct bpf_prog declaration
2ec9898e9c70b93a bpf: Remove unused parameter from ___bpf_prog_run
007bdc12d4b46656 bpf, selftests: test_maps generating unrecognized data section
82506665179209e4 tcp: reorder tcp_congestion_ops for better cache locality
[acme@five bpf]$
I'll try after a 'make mrproper'
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 13:22 ` Arnaldo Carvalho de Melo
@ 2021-04-06 13:23 ` Arnaldo Carvalho de Melo
2021-04-06 16:40 ` Arnaldo Carvalho de Melo
1 sibling, 0 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-06 13:23 UTC (permalink / raw)
To: Yonghong Song, Bill Wendling
Cc: dwarves, Alexei Starovoitov, Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Tue, Apr 06, 2021 at 10:22:37AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Apr 02, 2021 at 12:44:50PM -0700, Bill Wendling escreveu:
> > I tried porting the .config we're using to the official branch and
> > couldn't replicate the problem. It's probably something local.
> >
> > On Thu, Apr 1, 2021 at 3:00 PM Yonghong Song <yhs@fb.com> wrote:
> > > On 4/1/21 1:56 PM, Bill Wendling wrote:
> > > > On Thu, Apr 1, 2021 at 12:35 PM Bill Wendling <morbo@google.com> wrote:
> > > >>
> > > >> On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
> > > >>>
> > > >>> Function cus__merging_cu() is introduced in Commit 39227909db3c
> > > >>> ("dwarf_loader: Permit merging all DWARF CU's for clang LTO built
> > > >>> binary") to test whether cross-cu references may happen.
> > > >>> The original implementation anticipates compilation flags
> > > >>> in dwarf, but later some concerns about binary size surfaced
> > > >>> and the decision is to scan .debug_abbrev as a faster way
> > > >>> to check cross-cu references. Also putting a note in vmlinux
> > > >>> to indicate whether lto is enabled for built or not can
> > > >>> provide a much faster way.
> > > >>>
> > > >>> This patch set implemented this two approaches, first
> > > >>> checking the note (in Patch #2), if not found, then
> > > >>> check .debug_abbrev (in Patch #1).
> > > >>>
> > > >>> Yonghong Song (2):
> > > >>> dwarf_loader: check .debug_abbrev for cross-cu references
> > > >>> dwarf_loader: check .notes section for lto build info
> > > >>>
> > > >>> dwarf_loader.c | 76 ++++++++++++++++++++++++++++++++++++--------------
> > > >>> 1 file changed, 55 insertions(+), 21 deletions(-)
> > > >>>
> > > >> With this series of patches, the compilation passes for me with
> > > >> ThinLTO. You may add this if you like:
> > > >>
> > > >> Tested-by: Bill Wendling <morbo@google.com>
> > > >
> > > > I did notice these warnings following the "pahole -J .tmp_vmlinux.btf"
> > > > command. I don't know the severity of them, but it might be good to
> > > > investigate.
> > > >
> > > > $ ./tools/bpf/resolve_btfids/resolve_btfids vmlinux
> > > > BTFIDS vmlinux
> > > > WARN: multiple IDs found for 'inode': 355, 8746 - using 355
> > > > WARN: multiple IDs found for 'file': 588, 8779 - using 588
> > > > WARN: multiple IDs found for 'path': 411, 8780 - using 411
> > > > WARN: multiple IDs found for 'seq_file': 1414, 8836 - using 1414
> > > > WARN: multiple IDs found for 'vm_area_struct': 538, 8873 - using 538
> > > > WARN: multiple IDs found for 'task_struct': 28, 8880 - using 28
> > > > WARN: multiple IDs found for 'inode': 355, 9484 - using 355
> > > > WARN: multiple IDs found for 'file': 588, 9517 - using 588
> > > > WARN: multiple IDs found for 'path': 411, 9518 - using 411
> > > > WARN: multiple IDs found for 'seq_file': 1414, 9578 - using 1414
> > > > WARN: multiple IDs found for 'vm_area_struct': 538, 9615 - using 538
> > > > WARN: multiple IDs found for 'task_struct': 28, 9622 - using 28
> > > > WARN: multiple IDs found for 'seq_file': 1414, 12223 - using 1414
> > > > WARN: multiple IDs found for 'file': 588, 12237 - using 588
> > > > WARN: multiple IDs found for 'path': 411, 12238 - using 411
> > > > ...
> > >
> > > I didn't see it with my config. Maybe you can share your config file?
>
> I'm seeing these here:
>
> [acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
> [acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_thin_lto/ vmlinux
> make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
> GEN Makefile
> DESCEND objtool
> DESCEND bpf/resolve_btfids
> CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
> CALL /home/acme/git/bpf/scripts/checksyscalls.sh
> CHK include/generated/compile.h
> GEN .version
> CHK include/generated/compile.h
> UPD include/generated/compile.h
> CC init/version.o
> AR init/built-in.a
> GEN .tmp_initcalls.lds
> LTO vmlinux.o
> OBJTOOL vmlinux.o
> vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen2()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen2()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen2()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen2()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen4()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen4()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen4()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen4()+0x12: unsupported stack pointer realignment
> MODPOST vmlinux.symvers
> MODINFO modules.builtin.modinfo
> GEN modules.builtin
> LD .tmp_vmlinux.btf
> BTF .btf.vmlinux.bin.o
> LD .tmp_vmlinux.kallsyms1
> KSYMS .tmp_vmlinux.kallsyms1.S
> AS .tmp_vmlinux.kallsyms1.S
> LD .tmp_vmlinux.kallsyms2
> KSYMS .tmp_vmlinux.kallsyms2.S
> AS .tmp_vmlinux.kallsyms2.S
> LD vmlinux
> BTFIDS vmlinux
> WARN: multiple IDs found for 'inode': 232, 28822 - using 232
> WARN: multiple IDs found for 'file': 374, 28855 - using 374
> WARN: multiple IDs found for 'path': 379, 28856 - using 379
> WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
> WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
> WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
> WARN: multiple IDs found for 'inode': 232, 29345 - using 232
> WARN: multiple IDs found for 'file': 374, 29429 - using 374
> WARN: multiple IDs found for 'path': 379, 29430 - using 379
> WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
> WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
> WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
> SORTTAB vmlinux
> SYSMAP System.map
> make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
>
> [acme@five pahole]$ clang -v
> clang version 11.0.0 (Fedora 11.0.0-2.fc33)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/10
> Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
> Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
> Candidate multilib: .;@m64
> Candidate multilib: 32;@m32
> Selected multilib: .;@m64
> [acme@five pahole]$
>
> [acme@five bpf]$ git log --oneline -10
> 49b9da70941c3c8a (HEAD -> bpf_perf_enable) kbuild: add an elfnote with type BUILD_COMPILER_LTO_INFO
> 5c4f082a143c786e kbuild: move LINUX_ELFNOTE_BUILD_SALT to elfnote.h
> 42c8b565decb3662 bpf: Introduce helpers to enable/disable perf event fds in a map
> f73ea1eb4cce6637 (bpf-next/master, bpf-next/for-next) bpf: selftests: Specify CONFIG_DYNAMIC_FTRACE in the testing config
> f07669df4c8df0b7 libbpf: Remove redundant semi-colon
> 6ac4c6f887f5a8ef bpf: Remove repeated struct btf_type declaration
> 2daae89666ad2532 bpf, cgroup: Delete repeated struct bpf_prog declaration
> 2ec9898e9c70b93a bpf: Remove unused parameter from ___bpf_prog_run
> 007bdc12d4b46656 bpf, selftests: test_maps generating unrecognized data section
> 82506665179209e4 tcp: reorder tcp_congestion_ops for better cache locality
> [acme@five bpf]$
>
> I'll try after a 'make mrproper'
Also:
[acme@five pahole]$ git log --oneline -10
ae0b7dde1fd50b12 (HEAD -> master) dwarf_loader: Handle DWARF5 DW_OP_addrx properly
9adb014930f31c66 dwarf_loader: Handle subprogram ret type with abstract_origin properly
5752d1951d081a80 dwarf_loader: Check .notes section for LTO build info
209e45424ff4a22d dwarf_loader: Check .debug_abbrev for cross-CU references
39227909db3cc2c2 dwarf_loader: Permit merging all DWARF CU's for clang LTO built binary
763475ca1101ccfe dwarf_loader: Factor out common code to initialize a cu
d0d3fbd4744953e8 dwarf_loader: Permit a flexible HASHTAGS__BITS
ffe0ef4d73906c18 btf: Add --btf_gen_all flag
de708b33114d42c2 btf: Add support for the floating-point types
4b7f8c04d009942b fprintf: Honour conf_fprintf.hex when printing enumerations
[acme@five pahole]$
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 13:22 ` Arnaldo Carvalho de Melo
2021-04-06 13:23 ` Arnaldo Carvalho de Melo
@ 2021-04-06 16:40 ` Arnaldo Carvalho de Melo
2021-04-06 16:55 ` Arnaldo Carvalho de Melo
1 sibling, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-06 16:40 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Bill Wendling, Yonghong Song, dwarves, Alexei Starovoitov,
Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Tue, Apr 06, 2021 at 10:22:37AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Apr 02, 2021 at 12:44:50PM -0700, Bill Wendling escreveu:
> > I tried porting the .config we're using to the official branch and
> > couldn't replicate the problem. It's probably something local.
> >
> > On Thu, Apr 1, 2021 at 3:00 PM Yonghong Song <yhs@fb.com> wrote:
> > > On 4/1/21 1:56 PM, Bill Wendling wrote:
> > > > On Thu, Apr 1, 2021 at 12:35 PM Bill Wendling <morbo@google.com> wrote:
> > > >>
> > > >> On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
> > > >>>
> > > >>> Function cus__merging_cu() is introduced in Commit 39227909db3c
> > > >>> ("dwarf_loader: Permit merging all DWARF CU's for clang LTO built
> > > >>> binary") to test whether cross-cu references may happen.
> > > >>> The original implementation anticipates compilation flags
> > > >>> in dwarf, but later some concerns about binary size surfaced
> > > >>> and the decision is to scan .debug_abbrev as a faster way
> > > >>> to check cross-cu references. Also putting a note in vmlinux
> > > >>> to indicate whether lto is enabled for built or not can
> > > >>> provide a much faster way.
> > > >>>
> > > >>> This patch set implemented this two approaches, first
> > > >>> checking the note (in Patch #2), if not found, then
> > > >>> check .debug_abbrev (in Patch #1).
> > > >>>
> > > >>> Yonghong Song (2):
> > > >>> dwarf_loader: check .debug_abbrev for cross-cu references
> > > >>> dwarf_loader: check .notes section for lto build info
> > > >>>
> > > >>> dwarf_loader.c | 76 ++++++++++++++++++++++++++++++++++++--------------
> > > >>> 1 file changed, 55 insertions(+), 21 deletions(-)
> > > >>>
> > > >> With this series of patches, the compilation passes for me with
> > > >> ThinLTO. You may add this if you like:
> > > >>
> > > >> Tested-by: Bill Wendling <morbo@google.com>
> > > >
> > > > I did notice these warnings following the "pahole -J .tmp_vmlinux.btf"
> > > > command. I don't know the severity of them, but it might be good to
> > > > investigate.
> > > >
> > > > $ ./tools/bpf/resolve_btfids/resolve_btfids vmlinux
> > > > BTFIDS vmlinux
> > > > WARN: multiple IDs found for 'inode': 355, 8746 - using 355
> > > > WARN: multiple IDs found for 'file': 588, 8779 - using 588
> > > > WARN: multiple IDs found for 'path': 411, 8780 - using 411
> > > > WARN: multiple IDs found for 'seq_file': 1414, 8836 - using 1414
> > > > WARN: multiple IDs found for 'vm_area_struct': 538, 8873 - using 538
> > > > WARN: multiple IDs found for 'task_struct': 28, 8880 - using 28
> > > > WARN: multiple IDs found for 'inode': 355, 9484 - using 355
> > > > WARN: multiple IDs found for 'file': 588, 9517 - using 588
> > > > WARN: multiple IDs found for 'path': 411, 9518 - using 411
> > > > WARN: multiple IDs found for 'seq_file': 1414, 9578 - using 1414
> > > > WARN: multiple IDs found for 'vm_area_struct': 538, 9615 - using 538
> > > > WARN: multiple IDs found for 'task_struct': 28, 9622 - using 28
> > > > WARN: multiple IDs found for 'seq_file': 1414, 12223 - using 1414
> > > > WARN: multiple IDs found for 'file': 588, 12237 - using 588
> > > > WARN: multiple IDs found for 'path': 411, 12238 - using 411
> > > > ...
> > >
> > > I didn't see it with my config. Maybe you can share your config file?
>
> I'm seeing these here:
>
> [acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
> [acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_thin_lto/ vmlinux
> make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
> GEN Makefile
> DESCEND objtool
> DESCEND bpf/resolve_btfids
> CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
> CALL /home/acme/git/bpf/scripts/checksyscalls.sh
> CHK include/generated/compile.h
> GEN .version
> CHK include/generated/compile.h
> UPD include/generated/compile.h
> CC init/version.o
> AR init/built-in.a
> GEN .tmp_initcalls.lds
> LTO vmlinux.o
> OBJTOOL vmlinux.o
> vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen2()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen2()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen2()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen2()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen4()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen4()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen4()+0x12: unsupported stack pointer realignment
> vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen4()+0x12: unsupported stack pointer realignment
> MODPOST vmlinux.symvers
> MODINFO modules.builtin.modinfo
> GEN modules.builtin
> LD .tmp_vmlinux.btf
> BTF .btf.vmlinux.bin.o
> LD .tmp_vmlinux.kallsyms1
> KSYMS .tmp_vmlinux.kallsyms1.S
> AS .tmp_vmlinux.kallsyms1.S
> LD .tmp_vmlinux.kallsyms2
> KSYMS .tmp_vmlinux.kallsyms2.S
> AS .tmp_vmlinux.kallsyms2.S
> LD vmlinux
> BTFIDS vmlinux
> WARN: multiple IDs found for 'inode': 232, 28822 - using 232
> WARN: multiple IDs found for 'file': 374, 28855 - using 374
> WARN: multiple IDs found for 'path': 379, 28856 - using 379
> WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
> WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
> WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
> WARN: multiple IDs found for 'inode': 232, 29345 - using 232
> WARN: multiple IDs found for 'file': 374, 29429 - using 374
> WARN: multiple IDs found for 'path': 379, 29430 - using 379
> WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
> WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
> WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
> SORTTAB vmlinux
> SYSMAP System.map
> make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
>
> [acme@five pahole]$ clang -v
> clang version 11.0.0 (Fedora 11.0.0-2.fc33)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/10
> Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
> Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
> Candidate multilib: .;@m64
> Candidate multilib: 32;@m32
> Selected multilib: .;@m64
> [acme@five pahole]$
>
> [acme@five bpf]$ git log --oneline -10
> 49b9da70941c3c8a (HEAD -> bpf_perf_enable) kbuild: add an elfnote with type BUILD_COMPILER_LTO_INFO
> 5c4f082a143c786e kbuild: move LINUX_ELFNOTE_BUILD_SALT to elfnote.h
> 42c8b565decb3662 bpf: Introduce helpers to enable/disable perf event fds in a map
> f73ea1eb4cce6637 (bpf-next/master, bpf-next/for-next) bpf: selftests: Specify CONFIG_DYNAMIC_FTRACE in the testing config
> f07669df4c8df0b7 libbpf: Remove redundant semi-colon
> 6ac4c6f887f5a8ef bpf: Remove repeated struct btf_type declaration
> 2daae89666ad2532 bpf, cgroup: Delete repeated struct bpf_prog declaration
> 2ec9898e9c70b93a bpf: Remove unused parameter from ___bpf_prog_run
> 007bdc12d4b46656 bpf, selftests: test_maps generating unrecognized data section
> 82506665179209e4 tcp: reorder tcp_congestion_ops for better cache locality
> [acme@five bpf]$
>
> I'll try after a 'make mrproper'
Same thing, trying now with gcc.
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 16:40 ` Arnaldo Carvalho de Melo
@ 2021-04-06 16:55 ` Arnaldo Carvalho de Melo
2021-04-06 16:59 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-06 16:55 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Bill Wendling, Yonghong Song, dwarves, Alexei Starovoitov,
Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Tue, Apr 06, 2021 at 01:40:20PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Apr 06, 2021 at 10:22:37AM -0300, Arnaldo Carvalho de Melo escreveu:
> > I'm seeing these here:
> > [acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
> > [acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_thin_lto/ vmlinux
> > make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
> > GEN Makefile
> > DESCEND objtool
> > DESCEND bpf/resolve_btfids
> > CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
> > CALL /home/acme/git/bpf/scripts/checksyscalls.sh
> > CHK include/generated/compile.h
> > GEN .version
> > CHK include/generated/compile.h
> > UPD include/generated/compile.h
> > CC init/version.o
> > AR init/built-in.a
> > GEN .tmp_initcalls.lds
> > LTO vmlinux.o
> > OBJTOOL vmlinux.o
> > vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen2()+0x12: unsupported stack pointer realignment
> > vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen2()+0x12: unsupported stack pointer realignment
> > vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen2()+0x12: unsupported stack pointer realignment
> > vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen2()+0x12: unsupported stack pointer realignment
> > vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen4()+0x12: unsupported stack pointer realignment
> > vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen4()+0x12: unsupported stack pointer realignment
> > vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen4()+0x12: unsupported stack pointer realignment
> > vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen4()+0x12: unsupported stack pointer realignment
> > MODPOST vmlinux.symvers
> > MODINFO modules.builtin.modinfo
> > GEN modules.builtin
> > LD .tmp_vmlinux.btf
> > BTF .btf.vmlinux.bin.o
> > LD .tmp_vmlinux.kallsyms1
> > KSYMS .tmp_vmlinux.kallsyms1.S
> > AS .tmp_vmlinux.kallsyms1.S
> > LD .tmp_vmlinux.kallsyms2
> > KSYMS .tmp_vmlinux.kallsyms2.S
> > AS .tmp_vmlinux.kallsyms2.S
> > LD vmlinux
> > BTFIDS vmlinux
> > WARN: multiple IDs found for 'inode': 232, 28822 - using 232
> > WARN: multiple IDs found for 'file': 374, 28855 - using 374
> > WARN: multiple IDs found for 'path': 379, 28856 - using 379
> > WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
> > WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
> > WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
> > WARN: multiple IDs found for 'inode': 232, 29345 - using 232
> > WARN: multiple IDs found for 'file': 374, 29429 - using 374
> > WARN: multiple IDs found for 'path': 379, 29430 - using 379
> > WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
> > WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
> > WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
> > SORTTAB vmlinux
> > SYSMAP System.map
> > make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
> >
> > [acme@five pahole]$ clang -v
> > clang version 11.0.0 (Fedora 11.0.0-2.fc33)
> > Target: x86_64-unknown-linux-gnu
> > Thread model: posix
> > InstalledDir: /usr/bin
> > Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/10
> > Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
> > Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
> > Candidate multilib: .;@m64
> > Candidate multilib: 32;@m32
> > Selected multilib: .;@m64
> > [acme@five pahole]$
> >
> > [acme@five bpf]$ git log --oneline -10
> > 49b9da70941c3c8a (HEAD -> bpf_perf_enable) kbuild: add an elfnote with type BUILD_COMPILER_LTO_INFO
> > 5c4f082a143c786e kbuild: move LINUX_ELFNOTE_BUILD_SALT to elfnote.h
> > 42c8b565decb3662 bpf: Introduce helpers to enable/disable perf event fds in a map
> > f73ea1eb4cce6637 (bpf-next/master, bpf-next/for-next) bpf: selftests: Specify CONFIG_DYNAMIC_FTRACE in the testing config
> > f07669df4c8df0b7 libbpf: Remove redundant semi-colon
> > 6ac4c6f887f5a8ef bpf: Remove repeated struct btf_type declaration
> > 2daae89666ad2532 bpf, cgroup: Delete repeated struct bpf_prog declaration
> > 2ec9898e9c70b93a bpf: Remove unused parameter from ___bpf_prog_run
> > 007bdc12d4b46656 bpf, selftests: test_maps generating unrecognized data section
> > 82506665179209e4 tcp: reorder tcp_congestion_ops for better cache locality
> > [acme@five bpf]$
> >
> > I'll try after a 'make mrproper'
>
> Same thing, trying now with gcc.
With gcc no such messages:
CC [M] drivers/gpu/drm/nouveau/nv84_fence.o
CC [M] drivers/gpu/drm/nouveau/nvc0_fence.o
LD [M] drivers/gpu/drm/nouveau/nouveau.o
AR drivers/gpu/built-in.a
AR drivers/built-in.a
GEN .version
CHK include/generated/compile.h
LD vmlinux.o
MODPOST vmlinux.symvers
MODINFO modules.builtin.modinfo
GEN modules.builtin
LD .tmp_vmlinux.btf
BTF .btf.vmlinux.bin.o
LD .tmp_vmlinux.kallsyms1
KSYMS .tmp_vmlinux.kallsyms1.S
AS .tmp_vmlinux.kallsyms1.S
LD .tmp_vmlinux.kallsyms2
KSYMS .tmp_vmlinux.kallsyms2.S
AS .tmp_vmlinux.kallsyms2.S
LD vmlinux
BTFIDS vmlinux
SORTTAB vmlinux
SYSMAP System.map
HOSTCC arch/x86/tools/insn_decoder_test
HOSTCC arch/x86/tools/insn_sanity
MODPOST Module.symvers
TEST posttest
CC [M] arch/x86/crypto/aegis128-aesni.mod.o
CC [M] arch/x86/crypto/blake2s-x86_64.mod.o
Now will try with clang non-LTO.
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 16:55 ` Arnaldo Carvalho de Melo
@ 2021-04-06 16:59 ` Arnaldo Carvalho de Melo
2021-04-06 17:03 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-06 16:59 UTC (permalink / raw)
To: Bill Wendling, Yonghong Song, Jiri Olsa
Cc: dwarves, Alexei Starovoitov, Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Tue, Apr 06, 2021 at 01:55:54PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Apr 06, 2021 at 01:40:20PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Tue, Apr 06, 2021 at 10:22:37AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > I'm seeing these here:
>
> > > [acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
> > > [acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_thin_lto/ vmlinux
> > > make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > GEN Makefile
> > > DESCEND objtool
> > > DESCEND bpf/resolve_btfids
> > > CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
> > > CALL /home/acme/git/bpf/scripts/checksyscalls.sh
> > > CHK include/generated/compile.h
> > > GEN .version
> > > CHK include/generated/compile.h
> > > UPD include/generated/compile.h
> > > CC init/version.o
> > > AR init/built-in.a
> > > GEN .tmp_initcalls.lds
> > > LTO vmlinux.o
> > > OBJTOOL vmlinux.o
> > > vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen2()+0x12: unsupported stack pointer realignment
> > > vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen2()+0x12: unsupported stack pointer realignment
> > > vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen2()+0x12: unsupported stack pointer realignment
> > > vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen2()+0x12: unsupported stack pointer realignment
> > > vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen4()+0x12: unsupported stack pointer realignment
> > > vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen4()+0x12: unsupported stack pointer realignment
> > > vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen4()+0x12: unsupported stack pointer realignment
> > > vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen4()+0x12: unsupported stack pointer realignment
> > > MODPOST vmlinux.symvers
> > > MODINFO modules.builtin.modinfo
> > > GEN modules.builtin
> > > LD .tmp_vmlinux.btf
> > > BTF .btf.vmlinux.bin.o
> > > LD .tmp_vmlinux.kallsyms1
> > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > AS .tmp_vmlinux.kallsyms1.S
> > > LD .tmp_vmlinux.kallsyms2
> > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > AS .tmp_vmlinux.kallsyms2.S
> > > LD vmlinux
> > > BTFIDS vmlinux
> > > WARN: multiple IDs found for 'inode': 232, 28822 - using 232
> > > WARN: multiple IDs found for 'file': 374, 28855 - using 374
> > > WARN: multiple IDs found for 'path': 379, 28856 - using 379
> > > WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
> > > WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
> > > WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
> > > WARN: multiple IDs found for 'inode': 232, 29345 - using 232
> > > WARN: multiple IDs found for 'file': 374, 29429 - using 374
> > > WARN: multiple IDs found for 'path': 379, 29430 - using 379
> > > WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
> > > WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
> > > WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
> > > SORTTAB vmlinux
> > > SYSMAP System.map
> > > make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
> > >
> > > [acme@five pahole]$ clang -v
> > > clang version 11.0.0 (Fedora 11.0.0-2.fc33)
> > > Target: x86_64-unknown-linux-gnu
> > > Thread model: posix
> > > InstalledDir: /usr/bin
> > > Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/10
> > > Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
> > > Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
> > > Candidate multilib: .;@m64
> > > Candidate multilib: 32;@m32
> > > Selected multilib: .;@m64
> > > [acme@five pahole]$
> > >
> > > [acme@five bpf]$ git log --oneline -10
> > > 49b9da70941c3c8a (HEAD -> bpf_perf_enable) kbuild: add an elfnote with type BUILD_COMPILER_LTO_INFO
> > > 5c4f082a143c786e kbuild: move LINUX_ELFNOTE_BUILD_SALT to elfnote.h
> > > 42c8b565decb3662 bpf: Introduce helpers to enable/disable perf event fds in a map
> > > f73ea1eb4cce6637 (bpf-next/master, bpf-next/for-next) bpf: selftests: Specify CONFIG_DYNAMIC_FTRACE in the testing config
> > > f07669df4c8df0b7 libbpf: Remove redundant semi-colon
> > > 6ac4c6f887f5a8ef bpf: Remove repeated struct btf_type declaration
> > > 2daae89666ad2532 bpf, cgroup: Delete repeated struct bpf_prog declaration
> > > 2ec9898e9c70b93a bpf: Remove unused parameter from ___bpf_prog_run
> > > 007bdc12d4b46656 bpf, selftests: test_maps generating unrecognized data section
> > > 82506665179209e4 tcp: reorder tcp_congestion_ops for better cache locality
> > > [acme@five bpf]$
> > >
> > > I'll try after a 'make mrproper'
> >
> > Same thing, trying now with gcc.
>
> With gcc no such messages:
>
> CC [M] drivers/gpu/drm/nouveau/nv84_fence.o
> CC [M] drivers/gpu/drm/nouveau/nvc0_fence.o
> LD [M] drivers/gpu/drm/nouveau/nouveau.o
> AR drivers/gpu/built-in.a
> AR drivers/built-in.a
> GEN .version
> CHK include/generated/compile.h
> LD vmlinux.o
> MODPOST vmlinux.symvers
> MODINFO modules.builtin.modinfo
> GEN modules.builtin
> LD .tmp_vmlinux.btf
> BTF .btf.vmlinux.bin.o
> LD .tmp_vmlinux.kallsyms1
> KSYMS .tmp_vmlinux.kallsyms1.S
> AS .tmp_vmlinux.kallsyms1.S
> LD .tmp_vmlinux.kallsyms2
> KSYMS .tmp_vmlinux.kallsyms2.S
> AS .tmp_vmlinux.kallsyms2.S
> LD vmlinux
> BTFIDS vmlinux
> SORTTAB vmlinux
> SYSMAP System.map
> HOSTCC arch/x86/tools/insn_decoder_test
> HOSTCC arch/x86/tools/insn_sanity
> MODPOST Module.symvers
> TEST posttest
> CC [M] arch/x86/crypto/aegis128-aesni.mod.o
> CC [M] arch/x86/crypto/blake2s-x86_64.mod.o
>
> Now will try with clang non-LTO.
Works:
AR drivers/usb/built-in.a
AR lib/built-in.a
AR drivers/md/built-in.a
AR drivers/built-in.a
GEN .version
CHK include/generated/compile.h
LD vmlinux.o
MODPOST vmlinux.symvers
MODINFO modules.builtin.modinfo
GEN modules.builtin
LD .tmp_vmlinux.btf
BTF .btf.vmlinux.bin.o
LD .tmp_vmlinux.kallsyms1
KSYMS .tmp_vmlinux.kallsyms1.S
AS .tmp_vmlinux.kallsyms1.S
LD .tmp_vmlinux.kallsyms2
KSYMS .tmp_vmlinux.kallsyms2.S
AS .tmp_vmlinux.kallsyms2.S
LD vmlinux
BTFIDS vmlinux
SORTTAB vmlinux
SYSMAP System.map
make[1]: Leaving directory '/home/acme/git/build/bpf_clang_no_lto'
[acme@five bpf]$ grep LTO ../build/bpf_clang_no_lto/.config
CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
CONFIG_LTO_NONE=y
CONFIG_HID_WALTOP=m
[acme@five bpf]$
This works, gcc as well, but this produces those BTFID warnings:
[acme@five bpf]$ grep LTO ../build/bpf_clang_thin_lto/.config
CONFIG_LTO=y
CONFIG_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
CONFIG_HAS_LTO_CLANG=y
# CONFIG_LTO_NONE is not set
# CONFIG_LTO_CLANG_FULL is not set
CONFIG_LTO_CLANG_THIN=y
CONFIG_HID_WALTOP=m
[acme@five bpf]$
Trying with clang full LTO.
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 16:59 ` Arnaldo Carvalho de Melo
@ 2021-04-06 17:03 ` Arnaldo Carvalho de Melo
2021-04-06 17:07 ` Arnaldo Carvalho de Melo
2021-04-06 17:23 ` Yonghong Song
0 siblings, 2 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-06 17:03 UTC (permalink / raw)
To: Bill Wendling, Yonghong Song, Jiri Olsa
Cc: dwarves, Alexei Starovoitov, Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Tue, Apr 06, 2021 at 01:59:30PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Apr 06, 2021 at 01:55:54PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Tue, Apr 06, 2021 at 01:40:20PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Tue, Apr 06, 2021 at 10:22:37AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > I'm seeing these here:
> >
> > > > [acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
> > > > [acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_thin_lto/ vmlinux
> > > > make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > > GEN Makefile
> > > > DESCEND objtool
> > > > DESCEND bpf/resolve_btfids
> > > > CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
> > > > CALL /home/acme/git/bpf/scripts/checksyscalls.sh
> > > > CHK include/generated/compile.h
> > > > GEN .version
> > > > CHK include/generated/compile.h
> > > > UPD include/generated/compile.h
> > > > CC init/version.o
> > > > AR init/built-in.a
> > > > GEN .tmp_initcalls.lds
> > > > LTO vmlinux.o
> > > > OBJTOOL vmlinux.o
> > > > vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen2()+0x12: unsupported stack pointer realignment
> > > > vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen2()+0x12: unsupported stack pointer realignment
> > > > vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen2()+0x12: unsupported stack pointer realignment
> > > > vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen2()+0x12: unsupported stack pointer realignment
> > > > vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen4()+0x12: unsupported stack pointer realignment
> > > > vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen4()+0x12: unsupported stack pointer realignment
> > > > vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen4()+0x12: unsupported stack pointer realignment
> > > > vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen4()+0x12: unsupported stack pointer realignment
> > > > MODPOST vmlinux.symvers
> > > > MODINFO modules.builtin.modinfo
> > > > GEN modules.builtin
> > > > LD .tmp_vmlinux.btf
> > > > BTF .btf.vmlinux.bin.o
> > > > LD .tmp_vmlinux.kallsyms1
> > > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > > AS .tmp_vmlinux.kallsyms1.S
> > > > LD .tmp_vmlinux.kallsyms2
> > > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > > AS .tmp_vmlinux.kallsyms2.S
> > > > LD vmlinux
> > > > BTFIDS vmlinux
> > > > WARN: multiple IDs found for 'inode': 232, 28822 - using 232
> > > > WARN: multiple IDs found for 'file': 374, 28855 - using 374
> > > > WARN: multiple IDs found for 'path': 379, 28856 - using 379
> > > > WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
> > > > WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
> > > > WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
> > > > WARN: multiple IDs found for 'inode': 232, 29345 - using 232
> > > > WARN: multiple IDs found for 'file': 374, 29429 - using 374
> > > > WARN: multiple IDs found for 'path': 379, 29430 - using 379
> > > > WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
> > > > WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
> > > > WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
> > > > SORTTAB vmlinux
> > > > SYSMAP System.map
> > > > make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > >
> > > > [acme@five pahole]$ clang -v
> > > > clang version 11.0.0 (Fedora 11.0.0-2.fc33)
> > > > Target: x86_64-unknown-linux-gnu
> > > > Thread model: posix
> > > > InstalledDir: /usr/bin
> > > > Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/10
> > > > Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
> > > > Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
> > > > Candidate multilib: .;@m64
> > > > Candidate multilib: 32;@m32
> > > > Selected multilib: .;@m64
> > > > [acme@five pahole]$
> > > >
> > > > [acme@five bpf]$ git log --oneline -10
> > > > 49b9da70941c3c8a (HEAD -> bpf_perf_enable) kbuild: add an elfnote with type BUILD_COMPILER_LTO_INFO
> > > > 5c4f082a143c786e kbuild: move LINUX_ELFNOTE_BUILD_SALT to elfnote.h
> > > > 42c8b565decb3662 bpf: Introduce helpers to enable/disable perf event fds in a map
> > > > f73ea1eb4cce6637 (bpf-next/master, bpf-next/for-next) bpf: selftests: Specify CONFIG_DYNAMIC_FTRACE in the testing config
> > > > f07669df4c8df0b7 libbpf: Remove redundant semi-colon
> > > > 6ac4c6f887f5a8ef bpf: Remove repeated struct btf_type declaration
> > > > 2daae89666ad2532 bpf, cgroup: Delete repeated struct bpf_prog declaration
> > > > 2ec9898e9c70b93a bpf: Remove unused parameter from ___bpf_prog_run
> > > > 007bdc12d4b46656 bpf, selftests: test_maps generating unrecognized data section
> > > > 82506665179209e4 tcp: reorder tcp_congestion_ops for better cache locality
> > > > [acme@five bpf]$
> > > >
> > > > I'll try after a 'make mrproper'
> > >
> > > Same thing, trying now with gcc.
> >
> > With gcc no such messages:
> >
> > CC [M] drivers/gpu/drm/nouveau/nv84_fence.o
> > CC [M] drivers/gpu/drm/nouveau/nvc0_fence.o
> > LD [M] drivers/gpu/drm/nouveau/nouveau.o
> > AR drivers/gpu/built-in.a
> > AR drivers/built-in.a
> > GEN .version
> > CHK include/generated/compile.h
> > LD vmlinux.o
> > MODPOST vmlinux.symvers
> > MODINFO modules.builtin.modinfo
> > GEN modules.builtin
> > LD .tmp_vmlinux.btf
> > BTF .btf.vmlinux.bin.o
> > LD .tmp_vmlinux.kallsyms1
> > KSYMS .tmp_vmlinux.kallsyms1.S
> > AS .tmp_vmlinux.kallsyms1.S
> > LD .tmp_vmlinux.kallsyms2
> > KSYMS .tmp_vmlinux.kallsyms2.S
> > AS .tmp_vmlinux.kallsyms2.S
> > LD vmlinux
> > BTFIDS vmlinux
> > SORTTAB vmlinux
> > SYSMAP System.map
> > HOSTCC arch/x86/tools/insn_decoder_test
> > HOSTCC arch/x86/tools/insn_sanity
> > MODPOST Module.symvers
> > TEST posttest
> > CC [M] arch/x86/crypto/aegis128-aesni.mod.o
> > CC [M] arch/x86/crypto/blake2s-x86_64.mod.o
> >
> > Now will try with clang non-LTO.
>
> Works:
>
> AR drivers/usb/built-in.a
> AR lib/built-in.a
> AR drivers/md/built-in.a
> AR drivers/built-in.a
> GEN .version
> CHK include/generated/compile.h
> LD vmlinux.o
> MODPOST vmlinux.symvers
> MODINFO modules.builtin.modinfo
> GEN modules.builtin
> LD .tmp_vmlinux.btf
> BTF .btf.vmlinux.bin.o
> LD .tmp_vmlinux.kallsyms1
> KSYMS .tmp_vmlinux.kallsyms1.S
> AS .tmp_vmlinux.kallsyms1.S
> LD .tmp_vmlinux.kallsyms2
> KSYMS .tmp_vmlinux.kallsyms2.S
> AS .tmp_vmlinux.kallsyms2.S
> LD vmlinux
> BTFIDS vmlinux
> SORTTAB vmlinux
> SYSMAP System.map
> make[1]: Leaving directory '/home/acme/git/build/bpf_clang_no_lto'
>
> [acme@five bpf]$ grep LTO ../build/bpf_clang_no_lto/.config
> CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
> CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
> CONFIG_LTO_NONE=y
> CONFIG_HID_WALTOP=m
> [acme@five bpf]$
Sorry, I forgot to use clang on this no-lto build... doing it now with:
[acme@five bpf]$ grep LTO ../build/bpf_clang_no_lto/.config
CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
CONFIG_HAS_LTO_CLANG=y
CONFIG_LTO_NONE=y
# CONFIG_LTO_CLANG_FULL is not set
# CONFIG_LTO_CLANG_THIN is not set
CONFIG_HID_WALTOP=m
[acme@five bpf]$
[acme@five bpf]$ make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_no_lto/ vmlinux
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 17:03 ` Arnaldo Carvalho de Melo
@ 2021-04-06 17:07 ` Arnaldo Carvalho de Melo
2021-04-06 17:25 ` Arnaldo Carvalho de Melo
2021-04-06 17:23 ` Yonghong Song
1 sibling, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-06 17:07 UTC (permalink / raw)
To: Bill Wendling, Yonghong Song, Jiri Olsa
Cc: dwarves, Alexei Starovoitov, Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Tue, Apr 06, 2021 at 02:03:41PM -0300, Arnaldo Carvalho de Melo escreveu:
> Sorry, I forgot to use clang on this no-lto build... doing it now with:
>
> [acme@five bpf]$ grep LTO ../build/bpf_clang_no_lto/.config
> CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
> CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
> CONFIG_HAS_LTO_CLANG=y
> CONFIG_LTO_NONE=y
> # CONFIG_LTO_CLANG_FULL is not set
> # CONFIG_LTO_CLANG_THIN is not set
> CONFIG_HID_WALTOP=m
> [acme@five bpf]$
> [acme@five bpf]$ make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_no_lto/ vmlinux
Works:
[acme@five bpf]$ make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_no_lto/ vmlinux
CC drivers/acpi/acpica/utxfmutex.o
AR fs/built-in.a
AR drivers/acpi/acpica/built-in.a
AR drivers/acpi/built-in.a
AR drivers/md/built-in.a
AR drivers/built-in.a
GEN .version
CHK include/generated/compile.h
LD vmlinux.o
MODPOST vmlinux.symvers
MODINFO modules.builtin.modinfo
GEN modules.builtin
LD .tmp_vmlinux.btf
BTF .btf.vmlinux.bin.o
LD .tmp_vmlinux.kallsyms1
KSYMS .tmp_vmlinux.kallsyms1.S
AS .tmp_vmlinux.kallsyms1.S
LD .tmp_vmlinux.kallsyms2
KSYMS .tmp_vmlinux.kallsyms2.S
AS .tmp_vmlinux.kallsyms2.S
LD vmlinux
BTFIDS vmlinux
SORTTAB vmlinux
SYSMAP System.map
make[1]: Leaving directory '/home/acme/git/build/bpf_clang_no_lto'
[acme@five bpf]$ grep LTO ../build/bpf_clang_thin_lto/.config
CONFIG_LTO=y
CONFIG_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
CONFIG_HAS_LTO_CLANG=y
# CONFIG_LTO_NONE is not set
# CONFIG_LTO_CLANG_FULL is not set
CONFIG_LTO_CLANG_THIN=y
CONFIG_HID_WALTOP=m
[acme@five bpf]$
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-01 20:56 ` Bill Wendling
2021-04-01 21:59 ` Yonghong Song
@ 2021-04-06 17:09 ` Jiri Olsa
1 sibling, 0 replies; 33+ messages in thread
From: Jiri Olsa @ 2021-04-06 17:09 UTC (permalink / raw)
To: Bill Wendling
Cc: Yonghong Song, Arnaldo Carvalho de Melo, dwarves,
Alexei Starovoitov, Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
On Thu, Apr 01, 2021 at 01:56:57PM -0700, Bill Wendling wrote:
> On Thu, Apr 1, 2021 at 12:35 PM Bill Wendling <morbo@google.com> wrote:
> >
> > On Wed, Mar 31, 2021 at 7:58 PM Yonghong Song <yhs@fb.com> wrote:
> > >
> > > Function cus__merging_cu() is introduced in Commit 39227909db3c
> > > ("dwarf_loader: Permit merging all DWARF CU's for clang LTO built
> > > binary") to test whether cross-cu references may happen.
> > > The original implementation anticipates compilation flags
> > > in dwarf, but later some concerns about binary size surfaced
> > > and the decision is to scan .debug_abbrev as a faster way
> > > to check cross-cu references. Also putting a note in vmlinux
> > > to indicate whether lto is enabled for built or not can
> > > provide a much faster way.
> > >
> > > This patch set implemented this two approaches, first
> > > checking the note (in Patch #2), if not found, then
> > > check .debug_abbrev (in Patch #1).
> > >
> > > Yonghong Song (2):
> > > dwarf_loader: check .debug_abbrev for cross-cu references
> > > dwarf_loader: check .notes section for lto build info
> > >
> > > dwarf_loader.c | 76 ++++++++++++++++++++++++++++++++++++--------------
> > > 1 file changed, 55 insertions(+), 21 deletions(-)
> > >
> > With this series of patches, the compilation passes for me with
> > ThinLTO. You may add this if you like:
> >
> > Tested-by: Bill Wendling <morbo@google.com>
>
> I did notice these warnings following the "pahole -J .tmp_vmlinux.btf"
> command. I don't know the severity of them, but it might be good to
> investigate.
>
> $ ./tools/bpf/resolve_btfids/resolve_btfids vmlinux
> BTFIDS vmlinux
> WARN: multiple IDs found for 'inode': 355, 8746 - using 355
the message means that there are multiple instances of 'inode'
structs in the BTF data with ids 355 and 8746
that can happen when some object/struct name is duplicated in
multiple objects and it's causing two distinct type hierarchies
in BTF data.. like the one we fixes in here:
f7f2b43eaf6b crypto: bcm - Rename struct device_private to bcm_device_private
if you provide the .config, I can check if I reproduce
jirka
> WARN: multiple IDs found for 'file': 588, 8779 - using 588
> WARN: multiple IDs found for 'path': 411, 8780 - using 411
> WARN: multiple IDs found for 'seq_file': 1414, 8836 - using 1414
> WARN: multiple IDs found for 'vm_area_struct': 538, 8873 - using 538
> WARN: multiple IDs found for 'task_struct': 28, 8880 - using 28
> WARN: multiple IDs found for 'inode': 355, 9484 - using 355
> WARN: multiple IDs found for 'file': 588, 9517 - using 588
> WARN: multiple IDs found for 'path': 411, 9518 - using 411
> WARN: multiple IDs found for 'seq_file': 1414, 9578 - using 1414
> WARN: multiple IDs found for 'vm_area_struct': 538, 9615 - using 538
> WARN: multiple IDs found for 'task_struct': 28, 9622 - using 28
> WARN: multiple IDs found for 'seq_file': 1414, 12223 - using 1414
> WARN: multiple IDs found for 'file': 588, 12237 - using 588
> WARN: multiple IDs found for 'path': 411, 12238 - using 411
> ...
>
> -bw
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 17:03 ` Arnaldo Carvalho de Melo
2021-04-06 17:07 ` Arnaldo Carvalho de Melo
@ 2021-04-06 17:23 ` Yonghong Song
2021-04-06 17:34 ` Arnaldo Carvalho de Melo
2021-04-06 17:48 ` Yonghong Song
1 sibling, 2 replies; 33+ messages in thread
From: Yonghong Song @ 2021-04-06 17:23 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Bill Wendling, Jiri Olsa
Cc: dwarves, Alexei Starovoitov, Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
On 4/6/21 10:03 AM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Apr 06, 2021 at 01:59:30PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Tue, Apr 06, 2021 at 01:55:54PM -0300, Arnaldo Carvalho de Melo escreveu:
>>> Em Tue, Apr 06, 2021 at 01:40:20PM -0300, Arnaldo Carvalho de Melo escreveu:
>>>> Em Tue, Apr 06, 2021 at 10:22:37AM -0300, Arnaldo Carvalho de Melo escreveu:
>>>>> I'm seeing these here:
>>>
>>>>> [acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
>>>>> [acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_thin_lto/ vmlinux
>>>>> make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
>>>>> GEN Makefile
>>>>> DESCEND objtool
>>>>> DESCEND bpf/resolve_btfids
>>>>> CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
>>>>> CALL /home/acme/git/bpf/scripts/checksyscalls.sh
>>>>> CHK include/generated/compile.h
>>>>> GEN .version
>>>>> CHK include/generated/compile.h
>>>>> UPD include/generated/compile.h
>>>>> CC init/version.o
>>>>> AR init/built-in.a
>>>>> GEN .tmp_initcalls.lds
>>>>> LTO vmlinux.o
>>>>> OBJTOOL vmlinux.o
>>>>> vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen2()+0x12: unsupported stack pointer realignment
>>>>> vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen2()+0x12: unsupported stack pointer realignment
>>>>> vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen2()+0x12: unsupported stack pointer realignment
>>>>> vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen2()+0x12: unsupported stack pointer realignment
>>>>> vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen4()+0x12: unsupported stack pointer realignment
>>>>> vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen4()+0x12: unsupported stack pointer realignment
>>>>> vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen4()+0x12: unsupported stack pointer realignment
>>>>> vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen4()+0x12: unsupported stack pointer realignment
>>>>> MODPOST vmlinux.symvers
>>>>> MODINFO modules.builtin.modinfo
>>>>> GEN modules.builtin
>>>>> LD .tmp_vmlinux.btf
>>>>> BTF .btf.vmlinux.bin.o
>>>>> LD .tmp_vmlinux.kallsyms1
>>>>> KSYMS .tmp_vmlinux.kallsyms1.S
>>>>> AS .tmp_vmlinux.kallsyms1.S
>>>>> LD .tmp_vmlinux.kallsyms2
>>>>> KSYMS .tmp_vmlinux.kallsyms2.S
>>>>> AS .tmp_vmlinux.kallsyms2.S
>>>>> LD vmlinux
>>>>> BTFIDS vmlinux
>>>>> WARN: multiple IDs found for 'inode': 232, 28822 - using 232
>>>>> WARN: multiple IDs found for 'file': 374, 28855 - using 374
>>>>> WARN: multiple IDs found for 'path': 379, 28856 - using 379
>>>>> WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
>>>>> WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
>>>>> WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
>>>>> WARN: multiple IDs found for 'inode': 232, 29345 - using 232
>>>>> WARN: multiple IDs found for 'file': 374, 29429 - using 374
>>>>> WARN: multiple IDs found for 'path': 379, 29430 - using 379
>>>>> WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
>>>>> WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
>>>>> WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
>>>>> SORTTAB vmlinux
>>>>> SYSMAP System.map
>>>>> make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
>>>>>
>>>>> [acme@five pahole]$ clang -v
>>>>> clang version 11.0.0 (Fedora 11.0.0-2.fc33)
This could be due to the compiler. The clang 11 is used here. Sedat is
using clang 12 and didn't see warnings and I am using clang dev branch
(clang 13) and didn't see warnings either. clang 11 could generate
some debuginfo where pahole didn't handle it properly.
I tried to build locally with clang 11 but it crashed as I enabled
assert during compiler build. Will try a little bit more.
>>>>> Target: x86_64-unknown-linux-gnu
>>>>> Thread model: posix
>>>>> InstalledDir: /usr/bin
>>>>> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/10
>>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
>>>>> Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
>>>>> Candidate multilib: .;@m64
>>>>> Candidate multilib: 32;@m32
>>>>> Selected multilib: .;@m64
>>>>> [acme@five pahole]$
>>>>>
>>>>> [acme@five bpf]$ git log --oneline -10
>>>>> 49b9da70941c3c8a (HEAD -> bpf_perf_enable) kbuild: add an elfnote with type BUILD_COMPILER_LTO_INFO
>>>>> 5c4f082a143c786e kbuild: move LINUX_ELFNOTE_BUILD_SALT to elfnote.h
>>>>> 42c8b565decb3662 bpf: Introduce helpers to enable/disable perf event fds in a map
>>>>> f73ea1eb4cce6637 (bpf-next/master, bpf-next/for-next) bpf: selftests: Specify CONFIG_DYNAMIC_FTRACE in the testing config
>>>>> f07669df4c8df0b7 libbpf: Remove redundant semi-colon
>>>>> 6ac4c6f887f5a8ef bpf: Remove repeated struct btf_type declaration
>>>>> 2daae89666ad2532 bpf, cgroup: Delete repeated struct bpf_prog declaration
>>>>> 2ec9898e9c70b93a bpf: Remove unused parameter from ___bpf_prog_run
>>>>> 007bdc12d4b46656 bpf, selftests: test_maps generating unrecognized data section
>>>>> 82506665179209e4 tcp: reorder tcp_congestion_ops for better cache locality
>>>>> [acme@five bpf]$
>>>>>
>>>>> I'll try after a 'make mrproper'
>>>>
>>>> Same thing, trying now with gcc.
>>>
>>> With gcc no such messages:
>>>
>>> CC [M] drivers/gpu/drm/nouveau/nv84_fence.o
>>> CC [M] drivers/gpu/drm/nouveau/nvc0_fence.o
>>> LD [M] drivers/gpu/drm/nouveau/nouveau.o
>>> AR drivers/gpu/built-in.a
>>> AR drivers/built-in.a
>>> GEN .version
>>> CHK include/generated/compile.h
>>> LD vmlinux.o
>>> MODPOST vmlinux.symvers
>>> MODINFO modules.builtin.modinfo
>>> GEN modules.builtin
>>> LD .tmp_vmlinux.btf
>>> BTF .btf.vmlinux.bin.o
>>> LD .tmp_vmlinux.kallsyms1
>>> KSYMS .tmp_vmlinux.kallsyms1.S
>>> AS .tmp_vmlinux.kallsyms1.S
>>> LD .tmp_vmlinux.kallsyms2
>>> KSYMS .tmp_vmlinux.kallsyms2.S
>>> AS .tmp_vmlinux.kallsyms2.S
>>> LD vmlinux
>>> BTFIDS vmlinux
>>> SORTTAB vmlinux
>>> SYSMAP System.map
>>> HOSTCC arch/x86/tools/insn_decoder_test
>>> HOSTCC arch/x86/tools/insn_sanity
>>> MODPOST Module.symvers
>>> TEST posttest
>>> CC [M] arch/x86/crypto/aegis128-aesni.mod.o
>>> CC [M] arch/x86/crypto/blake2s-x86_64.mod.o
>>>
>>> Now will try with clang non-LTO.
>>
>> Works:
>>
>> AR drivers/usb/built-in.a
>> AR lib/built-in.a
>> AR drivers/md/built-in.a
>> AR drivers/built-in.a
>> GEN .version
>> CHK include/generated/compile.h
>> LD vmlinux.o
>> MODPOST vmlinux.symvers
>> MODINFO modules.builtin.modinfo
>> GEN modules.builtin
>> LD .tmp_vmlinux.btf
>> BTF .btf.vmlinux.bin.o
>> LD .tmp_vmlinux.kallsyms1
>> KSYMS .tmp_vmlinux.kallsyms1.S
>> AS .tmp_vmlinux.kallsyms1.S
>> LD .tmp_vmlinux.kallsyms2
>> KSYMS .tmp_vmlinux.kallsyms2.S
>> AS .tmp_vmlinux.kallsyms2.S
>> LD vmlinux
>> BTFIDS vmlinux
>> SORTTAB vmlinux
>> SYSMAP System.map
>> make[1]: Leaving directory '/home/acme/git/build/bpf_clang_no_lto'
>>
>> [acme@five bpf]$ grep LTO ../build/bpf_clang_no_lto/.config
>> CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
>> CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
>> CONFIG_LTO_NONE=y
>> CONFIG_HID_WALTOP=m
>> [acme@five bpf]$
>
> Sorry, I forgot to use clang on this no-lto build... doing it now with:
>
> [acme@five bpf]$ grep LTO ../build/bpf_clang_no_lto/.config
> CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
> CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
> CONFIG_HAS_LTO_CLANG=y
> CONFIG_LTO_NONE=y
> # CONFIG_LTO_CLANG_FULL is not set
> # CONFIG_LTO_CLANG_THIN is not set
> CONFIG_HID_WALTOP=m
> [acme@five bpf]$
> [acme@five bpf]$ make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_no_lto/ vmlinux
>
> - Arnaldo
>
>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 17:07 ` Arnaldo Carvalho de Melo
@ 2021-04-06 17:25 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-06 17:25 UTC (permalink / raw)
To: Bill Wendling, Yonghong Song, Jiri Olsa
Cc: dwarves, Alexei Starovoitov, Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Tue, Apr 06, 2021 at 02:07:26PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Apr 06, 2021 at 02:03:41PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Sorry, I forgot to use clang on this no-lto build... doing it now with:
> >
> > [acme@five bpf]$ grep LTO ../build/bpf_clang_no_lto/.config
> > CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
> > CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
> > CONFIG_HAS_LTO_CLANG=y
> > CONFIG_LTO_NONE=y
> > # CONFIG_LTO_CLANG_FULL is not set
> > # CONFIG_LTO_CLANG_THIN is not set
> > CONFIG_HID_WALTOP=m
> > [acme@five bpf]$
> > [acme@five bpf]$ make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_no_lto/ vmlinux
>
>
> Works:
>
> [acme@five bpf]$ make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_no_lto/ vmlinux
Now with FULL LTO:
CC fs/mbcache.o
CC fs/posix_acl.o
CC fs/coredump.o
CC fs/drop_caches.o
CC fs/fhandle.o
AR drivers/soundwire/built-in.a
AR drivers/hid/built-in.a
AR drivers/acpi/built-in.a
AR drivers/built-in.a
AR fs/built-in.a
GEN .version
CHK include/generated/compile.h
GEN .tmp_initcalls.lds
LTO vmlinux.o
OBJTOOL vmlinux.o
vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen2()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen2()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen2()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen2()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen4()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen4()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen4()+0x12: unsupported stack pointer realignment
vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen4()+0x12: unsupported stack pointer realignment
MODPOST vmlinux.symvers
MODINFO modules.builtin.modinfo
GEN modules.builtin
LD .tmp_vmlinux.btf
BTF .btf.vmlinux.bin.o
LD .tmp_vmlinux.kallsyms1
KSYMS .tmp_vmlinux.kallsyms1.S
AS .tmp_vmlinux.kallsyms1.S
LD .tmp_vmlinux.kallsyms2
KSYMS .tmp_vmlinux.kallsyms2.S
AS .tmp_vmlinux.kallsyms2.S
LD vmlinux
BTFIDS vmlinux
SORTTAB vmlinux
SYSMAP System.map
make[1]: Leaving directory '/home/acme/git/build/bpf_clang_full_lto'
real 8m36.854s
user 50m44.832s
sys 4m0.946s
[acme@five bpf]$
[acme@five bpf]$ cat /etc/fedora-release
Fedora release 33 (Thirty Three)
[acme@five bpf]$ grep LTO ../build/bpf_clang_full_lto/.config
CONFIG_LTO=y
CONFIG_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
CONFIG_HAS_LTO_CLANG=y
# CONFIG_LTO_NONE is not set
CONFIG_LTO_CLANG_FULL=y
# CONFIG_LTO_CLANG_THIN is not set
CONFIG_HID_WALTOP=m
[acme@five bpf]$
Probably this will go away if I update clang/llvm? :)
Will try.
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 17:23 ` Yonghong Song
@ 2021-04-06 17:34 ` Arnaldo Carvalho de Melo
2021-04-06 17:36 ` Arnaldo Carvalho de Melo
2021-04-06 17:48 ` Yonghong Song
1 sibling, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-06 17:34 UTC (permalink / raw)
To: Yonghong Song
Cc: Bill Wendling, Jiri Olsa, dwarves, Alexei Starovoitov,
Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Tue, Apr 06, 2021 at 10:23:37AM -0700, Yonghong Song escreveu:
>
>
> On 4/6/21 10:03 AM, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Apr 06, 2021 at 01:59:30PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Tue, Apr 06, 2021 at 01:55:54PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > Em Tue, Apr 06, 2021 at 01:40:20PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > > Em Tue, Apr 06, 2021 at 10:22:37AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > > > I'm seeing these here:
> > > >
> > > > > > [acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
> > > > > > [acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_thin_lto/ vmlinux
> > > > > > make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > > > > GEN Makefile
> > > > > > DESCEND objtool
> > > > > > DESCEND bpf/resolve_btfids
> > > > > > CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
> > > > > > CALL /home/acme/git/bpf/scripts/checksyscalls.sh
> > > > > > CHK include/generated/compile.h
> > > > > > GEN .version
> > > > > > CHK include/generated/compile.h
> > > > > > UPD include/generated/compile.h
> > > > > > CC init/version.o
> > > > > > AR init/built-in.a
> > > > > > GEN .tmp_initcalls.lds
> > > > > > LTO vmlinux.o
> > > > > > OBJTOOL vmlinux.o
> > > > > > vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen2()+0x12: unsupported stack pointer realignment
> > > > > > vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen2()+0x12: unsupported stack pointer realignment
> > > > > > vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen2()+0x12: unsupported stack pointer realignment
> > > > > > vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen2()+0x12: unsupported stack pointer realignment
> > > > > > vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen4()+0x12: unsupported stack pointer realignment
> > > > > > vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen4()+0x12: unsupported stack pointer realignment
> > > > > > vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen4()+0x12: unsupported stack pointer realignment
> > > > > > vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen4()+0x12: unsupported stack pointer realignment
> > > > > > MODPOST vmlinux.symvers
> > > > > > MODINFO modules.builtin.modinfo
> > > > > > GEN modules.builtin
> > > > > > LD .tmp_vmlinux.btf
> > > > > > BTF .btf.vmlinux.bin.o
> > > > > > LD .tmp_vmlinux.kallsyms1
> > > > > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > > > > AS .tmp_vmlinux.kallsyms1.S
> > > > > > LD .tmp_vmlinux.kallsyms2
> > > > > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > > > > AS .tmp_vmlinux.kallsyms2.S
> > > > > > LD vmlinux
> > > > > > BTFIDS vmlinux
> > > > > > WARN: multiple IDs found for 'inode': 232, 28822 - using 232
> > > > > > WARN: multiple IDs found for 'file': 374, 28855 - using 374
> > > > > > WARN: multiple IDs found for 'path': 379, 28856 - using 379
> > > > > > WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
> > > > > > WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
> > > > > > WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
> > > > > > WARN: multiple IDs found for 'inode': 232, 29345 - using 232
> > > > > > WARN: multiple IDs found for 'file': 374, 29429 - using 374
> > > > > > WARN: multiple IDs found for 'path': 379, 29430 - using 379
> > > > > > WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
> > > > > > WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
> > > > > > WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
> > > > > > SORTTAB vmlinux
> > > > > > SYSMAP System.map
> > > > > > make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > > > >
> > > > > > [acme@five pahole]$ clang -v
> > > > > > clang version 11.0.0 (Fedora 11.0.0-2.fc33)
>
> This could be due to the compiler. The clang 11 is used here. Sedat is
> using clang 12 and didn't see warnings and I am using clang dev branch
> (clang 13) and didn't see warnings either. clang 11 could generate
> some debuginfo where pahole didn't handle it properly.
>
> I tried to build locally with clang 11 but it crashed as I enabled
> assert during compiler build. Will try a little bit more.
Right, I'm now at:
$ git clone https://github.com/llvm/llvm-project.git
$ cmake -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" ../llvm
:-)
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 17:34 ` Arnaldo Carvalho de Melo
@ 2021-04-06 17:36 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-06 17:36 UTC (permalink / raw)
To: Yonghong Song
Cc: Bill Wendling, Jiri Olsa, dwarves, Alexei Starovoitov,
Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Tue, Apr 06, 2021 at 02:34:01PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Apr 06, 2021 at 10:23:37AM -0700, Yonghong Song escreveu:
> > On 4/6/21 10:03 AM, Arnaldo Carvalho de Melo wrote:
> > > Em Tue, Apr 06, 2021 at 01:59:30PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > Em Tue, Apr 06, 2021 at 01:55:54PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > > Em Tue, Apr 06, 2021 at 01:40:20PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > > > Em Tue, Apr 06, 2021 at 10:22:37AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > > > > I'm seeing these here:
> > > > >
> > > > > > > [acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
> > > > > > > [acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1 O=../build/bpf_clang_thin_lto/ vmlinux
> > > > > > > make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > > > > > GEN Makefile
> > > > > > > DESCEND objtool
> > > > > > > DESCEND bpf/resolve_btfids
> > > > > > > CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
> > > > > > > CALL /home/acme/git/bpf/scripts/checksyscalls.sh
> > > > > > > CHK include/generated/compile.h
> > > > > > > GEN .version
> > > > > > > CHK include/generated/compile.h
> > > > > > > UPD include/generated/compile.h
> > > > > > > CC init/version.o
> > > > > > > AR init/built-in.a
> > > > > > > GEN .tmp_initcalls.lds
> > > > > > > LTO vmlinux.o
> > > > > > > OBJTOOL vmlinux.o
> > > > > > > vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen2()+0x12: unsupported stack pointer realignment
> > > > > > > vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen2()+0x12: unsupported stack pointer realignment
> > > > > > > vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen2()+0x12: unsupported stack pointer realignment
> > > > > > > vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen2()+0x12: unsupported stack pointer realignment
> > > > > > > vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen4()+0x12: unsupported stack pointer realignment
> > > > > > > vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen4()+0x12: unsupported stack pointer realignment
> > > > > > > vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen4()+0x12: unsupported stack pointer realignment
> > > > > > > vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen4()+0x12: unsupported stack pointer realignment
> > > > > > > MODPOST vmlinux.symvers
> > > > > > > MODINFO modules.builtin.modinfo
> > > > > > > GEN modules.builtin
> > > > > > > LD .tmp_vmlinux.btf
> > > > > > > BTF .btf.vmlinux.bin.o
> > > > > > > LD .tmp_vmlinux.kallsyms1
> > > > > > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > > > > > AS .tmp_vmlinux.kallsyms1.S
> > > > > > > LD .tmp_vmlinux.kallsyms2
> > > > > > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > > > > > AS .tmp_vmlinux.kallsyms2.S
> > > > > > > LD vmlinux
> > > > > > > BTFIDS vmlinux
> > > > > > > WARN: multiple IDs found for 'inode': 232, 28822 - using 232
> > > > > > > WARN: multiple IDs found for 'file': 374, 28855 - using 374
> > > > > > > WARN: multiple IDs found for 'path': 379, 28856 - using 379
> > > > > > > WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
> > > > > > > WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
> > > > > > > WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
> > > > > > > WARN: multiple IDs found for 'inode': 232, 29345 - using 232
> > > > > > > WARN: multiple IDs found for 'file': 374, 29429 - using 374
> > > > > > > WARN: multiple IDs found for 'path': 379, 29430 - using 379
> > > > > > > WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
> > > > > > > WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
> > > > > > > WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
> > > > > > > SORTTAB vmlinux
> > > > > > > SYSMAP System.map
> > > > > > > make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > > > > >
> > > > > > > [acme@five pahole]$ clang -v
> > > > > > > clang version 11.0.0 (Fedora 11.0.0-2.fc33)
> >
> > This could be due to the compiler. The clang 11 is used here. Sedat is
> > using clang 12 and didn't see warnings and I am using clang dev branch
Cool, clang 12 is the one in Fedora 34 beta.
- Arnaldo
> > (clang 13) and didn't see warnings either. clang 11 could generate
> > some debuginfo where pahole didn't handle it properly.
> >
> > I tried to build locally with clang 11 but it crashed as I enabled
> > assert during compiler build. Will try a little bit more.
>
> Right, I'm now at:
>
> $ git clone https://github.com/llvm/llvm-project.git
> $ cmake -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" ../llvm
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 17:23 ` Yonghong Song
2021-04-06 17:34 ` Arnaldo Carvalho de Melo
@ 2021-04-06 17:48 ` Yonghong Song
2021-04-06 18:03 ` Arnaldo Carvalho de Melo
1 sibling, 1 reply; 33+ messages in thread
From: Yonghong Song @ 2021-04-06 17:48 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Bill Wendling, Jiri Olsa
Cc: dwarves, Alexei Starovoitov, Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
On 4/6/21 10:23 AM, Yonghong Song wrote:
>
>
> On 4/6/21 10:03 AM, Arnaldo Carvalho de Melo wrote:
>> Em Tue, Apr 06, 2021 at 01:59:30PM -0300, Arnaldo Carvalho de Melo
>> escreveu:
>>> Em Tue, Apr 06, 2021 at 01:55:54PM -0300, Arnaldo Carvalho de Melo
>>> escreveu:
>>>> Em Tue, Apr 06, 2021 at 01:40:20PM -0300, Arnaldo Carvalho de Melo
>>>> escreveu:
>>>>> Em Tue, Apr 06, 2021 at 10:22:37AM -0300, Arnaldo Carvalho de Melo
>>>>> escreveu:
>>>>>> I'm seeing these here:
>>>>
>>>>>> [acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
>>>>>> [acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1
>>>>>> O=../build/bpf_clang_thin_lto/ vmlinux
>>>>>> make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
>>>>>> GEN Makefile
>>>>>> DESCEND objtool
>>>>>> DESCEND bpf/resolve_btfids
>>>>>> CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
>>>>>> CALL /home/acme/git/bpf/scripts/checksyscalls.sh
>>>>>> CHK include/generated/compile.h
>>>>>> GEN .version
>>>>>> CHK include/generated/compile.h
>>>>>> UPD include/generated/compile.h
>>>>>> CC init/version.o
>>>>>> AR init/built-in.a
>>>>>> GEN .tmp_initcalls.lds
>>>>>> LTO vmlinux.o
>>>>>> OBJTOOL vmlinux.o
>>>>>> vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen2()+0x12:
>>>>>> unsupported stack pointer realignment
>>>>>> vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen2()+0x12:
>>>>>> unsupported stack pointer realignment
>>>>>> vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen2()+0x12:
>>>>>> unsupported stack pointer realignment
>>>>>> vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen2()+0x12:
>>>>>> unsupported stack pointer realignment
>>>>>> vmlinux.o: warning: objtool: aesni_gcm_init_avx_gen4()+0x12:
>>>>>> unsupported stack pointer realignment
>>>>>> vmlinux.o: warning: objtool: aesni_gcm_enc_update_avx_gen4()+0x12:
>>>>>> unsupported stack pointer realignment
>>>>>> vmlinux.o: warning: objtool: aesni_gcm_dec_update_avx_gen4()+0x12:
>>>>>> unsupported stack pointer realignment
>>>>>> vmlinux.o: warning: objtool: aesni_gcm_finalize_avx_gen4()+0x12:
>>>>>> unsupported stack pointer realignment
>>>>>> MODPOST vmlinux.symvers
>>>>>> MODINFO modules.builtin.modinfo
>>>>>> GEN modules.builtin
>>>>>> LD .tmp_vmlinux.btf
>>>>>> BTF .btf.vmlinux.bin.o
>>>>>> LD .tmp_vmlinux.kallsyms1
>>>>>> KSYMS .tmp_vmlinux.kallsyms1.S
>>>>>> AS .tmp_vmlinux.kallsyms1.S
>>>>>> LD .tmp_vmlinux.kallsyms2
>>>>>> KSYMS .tmp_vmlinux.kallsyms2.S
>>>>>> AS .tmp_vmlinux.kallsyms2.S
>>>>>> LD vmlinux
>>>>>> BTFIDS vmlinux
>>>>>> WARN: multiple IDs found for 'inode': 232, 28822 - using 232
>>>>>> WARN: multiple IDs found for 'file': 374, 28855 - using 374
>>>>>> WARN: multiple IDs found for 'path': 379, 28856 - using 379
>>>>>> WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
>>>>>> WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
>>>>>> WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
>>>>>> WARN: multiple IDs found for 'inode': 232, 29345 - using 232
>>>>>> WARN: multiple IDs found for 'file': 374, 29429 - using 374
>>>>>> WARN: multiple IDs found for 'path': 379, 29430 - using 379
>>>>>> WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
>>>>>> WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
>>>>>> WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
>>>>>> SORTTAB vmlinux
>>>>>> SYSMAP System.map
>>>>>> make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
>>>>>>
>>>>>> [acme@five pahole]$ clang -v
>>>>>> clang version 11.0.0 (Fedora 11.0.0-2.fc33)
>
> This could be due to the compiler. The clang 11 is used here. Sedat is
> using clang 12 and didn't see warnings and I am using clang dev branch
> (clang 13) and didn't see warnings either. clang 11 could generate
> some debuginfo where pahole didn't handle it properly.
>
> I tried to build locally with clang 11 but it crashed as I enabled
> assert during compiler build. Will try a little bit more.
Yes, I can see it with llvm11:
LD vmlinux
BTFIDS vmlinux
WARN: multiple IDs found for 'inode': 245, 36255 - using 245
WARN: multiple IDs found for 'file': 390, 36288 - using 390
WARN: multiple IDs found for 'path': 395, 36289 - using 395
WARN: multiple IDs found for 'vm_area_struct': 190, 36362 - using 190
WARN: multiple IDs found for 'task_struct': 93, 36399 - using 93
WARN: multiple IDs found for 'seq_file': 524, 36498 - using 524
WARN: multiple IDs found for 'inode': 245, 36784 - using 245
WARN: multiple IDs found for 'file': 390, 36868 - using 390
WARN: multiple IDs found for 'path': 395, 36869 - using 395
WARN: multiple IDs found for 'vm_area_struct': 190, 36910 - using 190
WARN: multiple IDs found for 'task_struct': 93, 36920 - using 93
WARN: multiple IDs found for 'seq_file': 524, 36951 - using 524
SORTTAB vmlinux
SYSMAP System.map
LTO [M] crypto/crypto_engine.lto.o
LTO [M] drivers/crypto/virtio/virtio_crypto.lto.o
$ clang --version
clang version 11.1.0 (https://github.com/llvm/llvm-project.git
1fdec59bffc11ae37eb51a1b9869f0696bfd5312)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/yhs/work/llvm-project/llvm/build/install/bin
clang12 is okay:
LTO vmlinux.o
OBJTOOL vmlinux.o
MODPOST vmlinux.symvers
MODINFO modules.builtin.modinfo
GEN modules.builtin
LD .tmp_vmlinux.btf
BTF .btf.vmlinux.bin.o
LD .tmp_vmlinux.kallsyms1
KSYMS .tmp_vmlinux.kallsyms1.S
AS .tmp_vmlinux.kallsyms1.S
LD .tmp_vmlinux.kallsyms2
KSYMS .tmp_vmlinux.kallsyms2.S
$ clang --version
clang version 12.0.0 (https://github.com/llvm/llvm-project.git
31001be371e8f2c74470e727e54503fb2aabec8b)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/yhs/work/llvm-project/llvm/build/install/bin
I think we do not need to fix pahole for llvm11.
When linus tree 5.12 is out. clang 12 should have been released
or very close, we can just recommend clang 12 and later.
>
>>>>>> Target: x86_64-unknown-linux-gnu
>>>>>> Thread model: posix
>>>>>> InstalledDir: /usr/bin
>>>>>> Found candidate GCC installation:
>>>>>> /usr/bin/../lib/gcc/x86_64-redhat-linux/10
>>>>>> Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
>>>>>> Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/10
>>>>>> Candidate multilib: .;@m64
>>>>>> Candidate multilib: 32;@m32
>>>>>> Selected multilib: .;@m64
>>>>>> [acme@five pahole]$
>>>>>>
>>>>>> [acme@five bpf]$ git log --oneline -10
>>>>>> 49b9da70941c3c8a (HEAD -> bpf_perf_enable) kbuild: add an elfnote
>>>>>> with type BUILD_COMPILER_LTO_INFO
>>>>>> 5c4f082a143c786e kbuild: move LINUX_ELFNOTE_BUILD_SALT to elfnote.h
>>>>>> 42c8b565decb3662 bpf: Introduce helpers to enable/disable perf
>>>>>> event fds in a map
>>>>>> f73ea1eb4cce6637 (bpf-next/master, bpf-next/for-next) bpf:
>>>>>> selftests: Specify CONFIG_DYNAMIC_FTRACE in the testing config
>>>>>> f07669df4c8df0b7 libbpf: Remove redundant semi-colon
>>>>>> 6ac4c6f887f5a8ef bpf: Remove repeated struct btf_type declaration
>>>>>> 2daae89666ad2532 bpf, cgroup: Delete repeated struct bpf_prog
>>>>>> declaration
>>>>>> 2ec9898e9c70b93a bpf: Remove unused parameter from ___bpf_prog_run
>>>>>> 007bdc12d4b46656 bpf, selftests: test_maps generating unrecognized
>>>>>> data section
>>>>>> 82506665179209e4 tcp: reorder tcp_congestion_ops for better cache
>>>>>> locality
>>>>>> [acme@five bpf]$
>>>>>>
>>>>>> I'll try after a 'make mrproper'
>>>>>
>>>>> Same thing, trying now with gcc.
>>>>
[...]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 17:48 ` Yonghong Song
@ 2021-04-06 18:03 ` Arnaldo Carvalho de Melo
2021-04-06 18:04 ` Arnaldo Carvalho de Melo
2021-04-06 18:17 ` David Blaikie
0 siblings, 2 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-06 18:03 UTC (permalink / raw)
To: Yonghong Song
Cc: Bill Wendling, Jiri Olsa, dwarves, Alexei Starovoitov,
Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Tue, Apr 06, 2021 at 10:48:22AM -0700, Yonghong Song escreveu:
>
>
> On 4/6/21 10:23 AM, Yonghong Song wrote:
> >
> >
> > On 4/6/21 10:03 AM, Arnaldo Carvalho de Melo wrote:
> > > Em Tue, Apr 06, 2021 at 01:59:30PM -0300, Arnaldo Carvalho de Melo
> > > escreveu:
> > > > Em Tue, Apr 06, 2021 at 01:55:54PM -0300, Arnaldo Carvalho de
> > > > Melo escreveu:
> > > > > Em Tue, Apr 06, 2021 at 01:40:20PM -0300, Arnaldo Carvalho
> > > > > de Melo escreveu:
> > > > > > Em Tue, Apr 06, 2021 at 10:22:37AM -0300, Arnaldo
> > > > > > Carvalho de Melo escreveu:
> > > > > > > I'm seeing these here:
> > > > >
> > > > > > > [acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
> > > > > > > [acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1
> > > > > > > O=../build/bpf_clang_thin_lto/ vmlinux
> > > > > > > make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > > > > > GEN Makefile
> > > > > > > DESCEND objtool
> > > > > > > DESCEND bpf/resolve_btfids
> > > > > > > CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
> > > > > > > CALL /home/acme/git/bpf/scripts/checksyscalls.sh
> > > > > > > CHK include/generated/compile.h
> > > > > > > GEN .version
> > > > > > > CHK include/generated/compile.h
> > > > > > > UPD include/generated/compile.h
> > > > > > > CC init/version.o
> > > > > > > AR init/built-in.a
> > > > > > > GEN .tmp_initcalls.lds
> > > > > > > LTO vmlinux.o
> > > > > > > OBJTOOL vmlinux.o
> > > > > > > vmlinux.o: warning: objtool:
> > > > > > > aesni_gcm_init_avx_gen2()+0x12: unsupported stack
> > > > > > > pointer realignment
> > > > > > > vmlinux.o: warning: objtool:
> > > > > > > aesni_gcm_enc_update_avx_gen2()+0x12: unsupported
> > > > > > > stack pointer realignment
> > > > > > > vmlinux.o: warning: objtool:
> > > > > > > aesni_gcm_dec_update_avx_gen2()+0x12: unsupported
> > > > > > > stack pointer realignment
> > > > > > > vmlinux.o: warning: objtool:
> > > > > > > aesni_gcm_finalize_avx_gen2()+0x12: unsupported
> > > > > > > stack pointer realignment
> > > > > > > vmlinux.o: warning: objtool:
> > > > > > > aesni_gcm_init_avx_gen4()+0x12: unsupported stack
> > > > > > > pointer realignment
> > > > > > > vmlinux.o: warning: objtool:
> > > > > > > aesni_gcm_enc_update_avx_gen4()+0x12: unsupported
> > > > > > > stack pointer realignment
> > > > > > > vmlinux.o: warning: objtool:
> > > > > > > aesni_gcm_dec_update_avx_gen4()+0x12: unsupported
> > > > > > > stack pointer realignment
> > > > > > > vmlinux.o: warning: objtool:
> > > > > > > aesni_gcm_finalize_avx_gen4()+0x12: unsupported
> > > > > > > stack pointer realignment
> > > > > > > MODPOST vmlinux.symvers
> > > > > > > MODINFO modules.builtin.modinfo
> > > > > > > GEN modules.builtin
> > > > > > > LD .tmp_vmlinux.btf
> > > > > > > BTF .btf.vmlinux.bin.o
> > > > > > > LD .tmp_vmlinux.kallsyms1
> > > > > > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > > > > > AS .tmp_vmlinux.kallsyms1.S
> > > > > > > LD .tmp_vmlinux.kallsyms2
> > > > > > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > > > > > AS .tmp_vmlinux.kallsyms2.S
> > > > > > > LD vmlinux
> > > > > > > BTFIDS vmlinux
> > > > > > > WARN: multiple IDs found for 'inode': 232, 28822 - using 232
> > > > > > > WARN: multiple IDs found for 'file': 374, 28855 - using 374
> > > > > > > WARN: multiple IDs found for 'path': 379, 28856 - using 379
> > > > > > > WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
> > > > > > > WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
> > > > > > > WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
> > > > > > > WARN: multiple IDs found for 'inode': 232, 29345 - using 232
> > > > > > > WARN: multiple IDs found for 'file': 374, 29429 - using 374
> > > > > > > WARN: multiple IDs found for 'path': 379, 29430 - using 379
> > > > > > > WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
> > > > > > > WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
> > > > > > > WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
> > > > > > > SORTTAB vmlinux
> > > > > > > SYSMAP System.map
> > > > > > > make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > > > > >
> > > > > > > [acme@five pahole]$ clang -v
> > > > > > > clang version 11.0.0 (Fedora 11.0.0-2.fc33)
> >
> > This could be due to the compiler. The clang 11 is used here. Sedat is
> > using clang 12 and didn't see warnings and I am using clang dev branch
> > (clang 13) and didn't see warnings either. clang 11 could generate
> > some debuginfo where pahole didn't handle it properly.
> >
> > I tried to build locally with clang 11 but it crashed as I enabled
> > assert during compiler build. Will try a little bit more.
>
> Yes, I can see it with llvm11:
>
> LD vmlinux
>
>
> BTFIDS vmlinux
>
>
> WARN: multiple IDs found for 'inode': 245, 36255 - using 245
>
>
> WARN: multiple IDs found for 'file': 390, 36288 - using 390
>
>
> WARN: multiple IDs found for 'path': 395, 36289 - using 395
>
>
> WARN: multiple IDs found for 'vm_area_struct': 190, 36362 - using 190
>
>
> WARN: multiple IDs found for 'task_struct': 93, 36399 - using 93
>
>
> WARN: multiple IDs found for 'seq_file': 524, 36498 - using 524
>
>
> WARN: multiple IDs found for 'inode': 245, 36784 - using 245
>
>
> WARN: multiple IDs found for 'file': 390, 36868 - using 390
>
>
> WARN: multiple IDs found for 'path': 395, 36869 - using 395
>
>
> WARN: multiple IDs found for 'vm_area_struct': 190, 36910 - using 190
>
>
> WARN: multiple IDs found for 'task_struct': 93, 36920 - using 93
>
>
> WARN: multiple IDs found for 'seq_file': 524, 36951 - using 524
>
>
> SORTTAB vmlinux
>
>
> SYSMAP System.map
>
>
> LTO [M] crypto/crypto_engine.lto.o
>
>
> LTO [M] drivers/crypto/virtio/virtio_crypto.lto.o
>
> $ clang --version
> clang version 11.1.0 (https://github.com/llvm/llvm-project.git
> 1fdec59bffc11ae37eb51a1b9869f0696bfd5312)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /home/yhs/work/llvm-project/llvm/build/install/bin
>
> clang12 is okay:
>
> LTO vmlinux.o
> OBJTOOL vmlinux.o
> MODPOST vmlinux.symvers
> MODINFO modules.builtin.modinfo
> GEN modules.builtin
> LD .tmp_vmlinux.btf
> BTF .btf.vmlinux.bin.o
> LD .tmp_vmlinux.kallsyms1
> KSYMS .tmp_vmlinux.kallsyms1.S
> AS .tmp_vmlinux.kallsyms1.S
> LD .tmp_vmlinux.kallsyms2
> KSYMS .tmp_vmlinux.kallsyms2.S
>
> $ clang --version
> clang version 12.0.0 (https://github.com/llvm/llvm-project.git
> 31001be371e8f2c74470e727e54503fb2aabec8b)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /home/yhs/work/llvm-project/llvm/build/install/bin
>
> I think we do not need to fix pahole for llvm11.
> When linus tree 5.12 is out. clang 12 should have been released
> or very close, we can just recommend clang 12 and later.
Agreed, and it is just for _thin_ LTO, those warnings don't pop up when
building for full LTO with clang 11, the one in Fedora 33.
And Fedora 34 beta has clang/llvm 12.0, so we're good.
/me goes back to building clang/llvm HEAD, reducing the number of linker
instances to 1 as I have just 32GB of ram in this Ryzen machine... ;-)
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 18:03 ` Arnaldo Carvalho de Melo
@ 2021-04-06 18:04 ` Arnaldo Carvalho de Melo
2021-04-06 18:31 ` Nick Desaulniers
2021-04-06 18:17 ` David Blaikie
1 sibling, 1 reply; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-06 18:04 UTC (permalink / raw)
To: Yonghong Song
Cc: Bill Wendling, Jiri Olsa, dwarves, Alexei Starovoitov,
Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Tue, Apr 06, 2021 at 03:03:29PM -0300, Arnaldo Carvalho de Melo escreveu:
> /me goes back to building clang/llvm HEAD, reducing the number of linker
> instances to 1 as I have just 32GB of ram in this Ryzen machine... ;-)
And guess what takes a long time?
[ 61%] Linking CXX executable ../../bin/llvm-lto
;-)
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 18:03 ` Arnaldo Carvalho de Melo
2021-04-06 18:04 ` Arnaldo Carvalho de Melo
@ 2021-04-06 18:17 ` David Blaikie
2021-04-06 18:20 ` Arnaldo Carvalho de Melo
2021-04-06 18:22 ` Fāng-ruì Sòng
1 sibling, 2 replies; 33+ messages in thread
From: David Blaikie @ 2021-04-06 18:17 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Yonghong Song, Bill Wendling, Jiri Olsa, dwarves,
Alexei Starovoitov, Andrii Nakryiko, bpf,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
On Tue, Apr 6, 2021 at 11:03 AM Arnaldo Carvalho de Melo
<arnaldo.melo@gmail.com> wrote:
>
> Em Tue, Apr 06, 2021 at 10:48:22AM -0700, Yonghong Song escreveu:
> >
> >
> > On 4/6/21 10:23 AM, Yonghong Song wrote:
> > >
> > >
> > > On 4/6/21 10:03 AM, Arnaldo Carvalho de Melo wrote:
> > > > Em Tue, Apr 06, 2021 at 01:59:30PM -0300, Arnaldo Carvalho de Melo
> > > > escreveu:
> > > > > Em Tue, Apr 06, 2021 at 01:55:54PM -0300, Arnaldo Carvalho de
> > > > > Melo escreveu:
> > > > > > Em Tue, Apr 06, 2021 at 01:40:20PM -0300, Arnaldo Carvalho
> > > > > > de Melo escreveu:
> > > > > > > Em Tue, Apr 06, 2021 at 10:22:37AM -0300, Arnaldo
> > > > > > > Carvalho de Melo escreveu:
> > > > > > > > I'm seeing these here:
> > > > > >
> > > > > > > > [acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
> > > > > > > > [acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1
> > > > > > > > O=../build/bpf_clang_thin_lto/ vmlinux
> > > > > > > > make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > > > > > > GEN Makefile
> > > > > > > > DESCEND objtool
> > > > > > > > DESCEND bpf/resolve_btfids
> > > > > > > > CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
> > > > > > > > CALL /home/acme/git/bpf/scripts/checksyscalls.sh
> > > > > > > > CHK include/generated/compile.h
> > > > > > > > GEN .version
> > > > > > > > CHK include/generated/compile.h
> > > > > > > > UPD include/generated/compile.h
> > > > > > > > CC init/version.o
> > > > > > > > AR init/built-in.a
> > > > > > > > GEN .tmp_initcalls.lds
> > > > > > > > LTO vmlinux.o
> > > > > > > > OBJTOOL vmlinux.o
> > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > aesni_gcm_init_avx_gen2()+0x12: unsupported stack
> > > > > > > > pointer realignment
> > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > aesni_gcm_enc_update_avx_gen2()+0x12: unsupported
> > > > > > > > stack pointer realignment
> > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > aesni_gcm_dec_update_avx_gen2()+0x12: unsupported
> > > > > > > > stack pointer realignment
> > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > aesni_gcm_finalize_avx_gen2()+0x12: unsupported
> > > > > > > > stack pointer realignment
> > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > aesni_gcm_init_avx_gen4()+0x12: unsupported stack
> > > > > > > > pointer realignment
> > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > aesni_gcm_enc_update_avx_gen4()+0x12: unsupported
> > > > > > > > stack pointer realignment
> > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > aesni_gcm_dec_update_avx_gen4()+0x12: unsupported
> > > > > > > > stack pointer realignment
> > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > aesni_gcm_finalize_avx_gen4()+0x12: unsupported
> > > > > > > > stack pointer realignment
> > > > > > > > MODPOST vmlinux.symvers
> > > > > > > > MODINFO modules.builtin.modinfo
> > > > > > > > GEN modules.builtin
> > > > > > > > LD .tmp_vmlinux.btf
> > > > > > > > BTF .btf.vmlinux.bin.o
> > > > > > > > LD .tmp_vmlinux.kallsyms1
> > > > > > > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > > > > > > AS .tmp_vmlinux.kallsyms1.S
> > > > > > > > LD .tmp_vmlinux.kallsyms2
> > > > > > > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > > > > > > AS .tmp_vmlinux.kallsyms2.S
> > > > > > > > LD vmlinux
> > > > > > > > BTFIDS vmlinux
> > > > > > > > WARN: multiple IDs found for 'inode': 232, 28822 - using 232
> > > > > > > > WARN: multiple IDs found for 'file': 374, 28855 - using 374
> > > > > > > > WARN: multiple IDs found for 'path': 379, 28856 - using 379
> > > > > > > > WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
> > > > > > > > WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
> > > > > > > > WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
> > > > > > > > WARN: multiple IDs found for 'inode': 232, 29345 - using 232
> > > > > > > > WARN: multiple IDs found for 'file': 374, 29429 - using 374
> > > > > > > > WARN: multiple IDs found for 'path': 379, 29430 - using 379
> > > > > > > > WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
> > > > > > > > WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
> > > > > > > > WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
> > > > > > > > SORTTAB vmlinux
> > > > > > > > SYSMAP System.map
> > > > > > > > make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > > > > > >
> > > > > > > > [acme@five pahole]$ clang -v
> > > > > > > > clang version 11.0.0 (Fedora 11.0.0-2.fc33)
> > >
> > > This could be due to the compiler. The clang 11 is used here. Sedat is
> > > using clang 12 and didn't see warnings and I am using clang dev branch
> > > (clang 13) and didn't see warnings either. clang 11 could generate
> > > some debuginfo where pahole didn't handle it properly.
> > >
> > > I tried to build locally with clang 11 but it crashed as I enabled
> > > assert during compiler build. Will try a little bit more.
> >
> > Yes, I can see it with llvm11:
> >
> > LD vmlinux
> >
> >
> > BTFIDS vmlinux
> >
> >
> > WARN: multiple IDs found for 'inode': 245, 36255 - using 245
> >
> >
> > WARN: multiple IDs found for 'file': 390, 36288 - using 390
> >
> >
> > WARN: multiple IDs found for 'path': 395, 36289 - using 395
> >
> >
> > WARN: multiple IDs found for 'vm_area_struct': 190, 36362 - using 190
> >
> >
> > WARN: multiple IDs found for 'task_struct': 93, 36399 - using 93
> >
> >
> > WARN: multiple IDs found for 'seq_file': 524, 36498 - using 524
> >
> >
> > WARN: multiple IDs found for 'inode': 245, 36784 - using 245
> >
> >
> > WARN: multiple IDs found for 'file': 390, 36868 - using 390
> >
> >
> > WARN: multiple IDs found for 'path': 395, 36869 - using 395
> >
> >
> > WARN: multiple IDs found for 'vm_area_struct': 190, 36910 - using 190
> >
> >
> > WARN: multiple IDs found for 'task_struct': 93, 36920 - using 93
> >
> >
> > WARN: multiple IDs found for 'seq_file': 524, 36951 - using 524
> >
> >
> > SORTTAB vmlinux
> >
> >
> > SYSMAP System.map
> >
> >
> > LTO [M] crypto/crypto_engine.lto.o
> >
> >
> > LTO [M] drivers/crypto/virtio/virtio_crypto.lto.o
> >
> > $ clang --version
> > clang version 11.1.0 (https://github.com/llvm/llvm-project.git
> > 1fdec59bffc11ae37eb51a1b9869f0696bfd5312)
> > Target: x86_64-unknown-linux-gnu
> > Thread model: posix
> > InstalledDir: /home/yhs/work/llvm-project/llvm/build/install/bin
> >
> > clang12 is okay:
> >
> > LTO vmlinux.o
> > OBJTOOL vmlinux.o
> > MODPOST vmlinux.symvers
> > MODINFO modules.builtin.modinfo
> > GEN modules.builtin
> > LD .tmp_vmlinux.btf
> > BTF .btf.vmlinux.bin.o
> > LD .tmp_vmlinux.kallsyms1
> > KSYMS .tmp_vmlinux.kallsyms1.S
> > AS .tmp_vmlinux.kallsyms1.S
> > LD .tmp_vmlinux.kallsyms2
> > KSYMS .tmp_vmlinux.kallsyms2.S
> >
> > $ clang --version
> > clang version 12.0.0 (https://github.com/llvm/llvm-project.git
> > 31001be371e8f2c74470e727e54503fb2aabec8b)
> > Target: x86_64-unknown-linux-gnu
> > Thread model: posix
> > InstalledDir: /home/yhs/work/llvm-project/llvm/build/install/bin
> >
> > I think we do not need to fix pahole for llvm11.
> > When linus tree 5.12 is out. clang 12 should have been released
> > or very close, we can just recommend clang 12 and later.
>
> Agreed, and it is just for _thin_ LTO, those warnings don't pop up when
> building for full LTO with clang 11, the one in Fedora 33.
>
> And Fedora 34 beta has clang/llvm 12.0, so we're good.
>
> /me goes back to building clang/llvm HEAD, reducing the number of linker
> instances to 1 as I have just 32GB of ram in this Ryzen machine... ;-)
32GB should be enough for a lot of parallel links - unless you're
using ld.bfd - highly advised to switch to gold or lld & then you
shuold be able to do a fair number of parallel links without loads of
thrashing.
https://llvm.org/docs/GettingStarted.html#common-problems discusses a
few things to try
- Dave
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 18:17 ` David Blaikie
@ 2021-04-06 18:20 ` Arnaldo Carvalho de Melo
2021-04-06 18:22 ` Fāng-ruì Sòng
1 sibling, 0 replies; 33+ messages in thread
From: Arnaldo Carvalho de Melo @ 2021-04-06 18:20 UTC (permalink / raw)
To: David Blaikie
Cc: Arnaldo Carvalho de Melo, Yonghong Song, Bill Wendling,
Jiri Olsa, dwarves, Alexei Starovoitov, Andrii Nakryiko, bpf,
Fāng-ruì Sòng, kernel-team, Nick Desaulniers
Em Tue, Apr 06, 2021 at 11:17:56AM -0700, David Blaikie escreveu:
> On Tue, Apr 6, 2021 at 11:03 AM Arnaldo Carvalho de Melo
> <arnaldo.melo@gmail.com> wrote:
> >
> > Em Tue, Apr 06, 2021 at 10:48:22AM -0700, Yonghong Song escreveu:
> > >
> > >
> > > On 4/6/21 10:23 AM, Yonghong Song wrote:
> > > >
> > > >
> > > > On 4/6/21 10:03 AM, Arnaldo Carvalho de Melo wrote:
> > > > > Em Tue, Apr 06, 2021 at 01:59:30PM -0300, Arnaldo Carvalho de Melo
> > > > > escreveu:
> > > > > > Em Tue, Apr 06, 2021 at 01:55:54PM -0300, Arnaldo Carvalho de
> > > > > > Melo escreveu:
> > > > > > > Em Tue, Apr 06, 2021 at 01:40:20PM -0300, Arnaldo Carvalho
> > > > > > > de Melo escreveu:
> > > > > > > > Em Tue, Apr 06, 2021 at 10:22:37AM -0300, Arnaldo
> > > > > > > > Carvalho de Melo escreveu:
> > > > > > > > > I'm seeing these here:
> > > > > > >
> > > > > > > > > [acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
> > > > > > > > > [acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1
> > > > > > > > > O=../build/bpf_clang_thin_lto/ vmlinux
> > > > > > > > > make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > > > > > > > GEN Makefile
> > > > > > > > > DESCEND objtool
> > > > > > > > > DESCEND bpf/resolve_btfids
> > > > > > > > > CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
> > > > > > > > > CALL /home/acme/git/bpf/scripts/checksyscalls.sh
> > > > > > > > > CHK include/generated/compile.h
> > > > > > > > > GEN .version
> > > > > > > > > CHK include/generated/compile.h
> > > > > > > > > UPD include/generated/compile.h
> > > > > > > > > CC init/version.o
> > > > > > > > > AR init/built-in.a
> > > > > > > > > GEN .tmp_initcalls.lds
> > > > > > > > > LTO vmlinux.o
> > > > > > > > > OBJTOOL vmlinux.o
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_init_avx_gen2()+0x12: unsupported stack
> > > > > > > > > pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_enc_update_avx_gen2()+0x12: unsupported
> > > > > > > > > stack pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_dec_update_avx_gen2()+0x12: unsupported
> > > > > > > > > stack pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_finalize_avx_gen2()+0x12: unsupported
> > > > > > > > > stack pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_init_avx_gen4()+0x12: unsupported stack
> > > > > > > > > pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_enc_update_avx_gen4()+0x12: unsupported
> > > > > > > > > stack pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_dec_update_avx_gen4()+0x12: unsupported
> > > > > > > > > stack pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_finalize_avx_gen4()+0x12: unsupported
> > > > > > > > > stack pointer realignment
> > > > > > > > > MODPOST vmlinux.symvers
> > > > > > > > > MODINFO modules.builtin.modinfo
> > > > > > > > > GEN modules.builtin
> > > > > > > > > LD .tmp_vmlinux.btf
> > > > > > > > > BTF .btf.vmlinux.bin.o
> > > > > > > > > LD .tmp_vmlinux.kallsyms1
> > > > > > > > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > > > > > > > AS .tmp_vmlinux.kallsyms1.S
> > > > > > > > > LD .tmp_vmlinux.kallsyms2
> > > > > > > > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > > > > > > > AS .tmp_vmlinux.kallsyms2.S
> > > > > > > > > LD vmlinux
> > > > > > > > > BTFIDS vmlinux
> > > > > > > > > WARN: multiple IDs found for 'inode': 232, 28822 - using 232
> > > > > > > > > WARN: multiple IDs found for 'file': 374, 28855 - using 374
> > > > > > > > > WARN: multiple IDs found for 'path': 379, 28856 - using 379
> > > > > > > > > WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
> > > > > > > > > WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
> > > > > > > > > WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
> > > > > > > > > WARN: multiple IDs found for 'inode': 232, 29345 - using 232
> > > > > > > > > WARN: multiple IDs found for 'file': 374, 29429 - using 374
> > > > > > > > > WARN: multiple IDs found for 'path': 379, 29430 - using 379
> > > > > > > > > WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
> > > > > > > > > WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
> > > > > > > > > WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
> > > > > > > > > SORTTAB vmlinux
> > > > > > > > > SYSMAP System.map
> > > > > > > > > make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > > > > > > >
> > > > > > > > > [acme@five pahole]$ clang -v
> > > > > > > > > clang version 11.0.0 (Fedora 11.0.0-2.fc33)
> > > >
> > > > This could be due to the compiler. The clang 11 is used here. Sedat is
> > > > using clang 12 and didn't see warnings and I am using clang dev branch
> > > > (clang 13) and didn't see warnings either. clang 11 could generate
> > > > some debuginfo where pahole didn't handle it properly.
> > > >
> > > > I tried to build locally with clang 11 but it crashed as I enabled
> > > > assert during compiler build. Will try a little bit more.
> > >
> > > Yes, I can see it with llvm11:
> > >
> > > LD vmlinux
> > >
> > >
> > > BTFIDS vmlinux
> > >
> > >
> > > WARN: multiple IDs found for 'inode': 245, 36255 - using 245
> > >
> > >
> > > WARN: multiple IDs found for 'file': 390, 36288 - using 390
> > >
> > >
> > > WARN: multiple IDs found for 'path': 395, 36289 - using 395
> > >
> > >
> > > WARN: multiple IDs found for 'vm_area_struct': 190, 36362 - using 190
> > >
> > >
> > > WARN: multiple IDs found for 'task_struct': 93, 36399 - using 93
> > >
> > >
> > > WARN: multiple IDs found for 'seq_file': 524, 36498 - using 524
> > >
> > >
> > > WARN: multiple IDs found for 'inode': 245, 36784 - using 245
> > >
> > >
> > > WARN: multiple IDs found for 'file': 390, 36868 - using 390
> > >
> > >
> > > WARN: multiple IDs found for 'path': 395, 36869 - using 395
> > >
> > >
> > > WARN: multiple IDs found for 'vm_area_struct': 190, 36910 - using 190
> > >
> > >
> > > WARN: multiple IDs found for 'task_struct': 93, 36920 - using 93
> > >
> > >
> > > WARN: multiple IDs found for 'seq_file': 524, 36951 - using 524
> > >
> > >
> > > SORTTAB vmlinux
> > >
> > >
> > > SYSMAP System.map
> > >
> > >
> > > LTO [M] crypto/crypto_engine.lto.o
> > >
> > >
> > > LTO [M] drivers/crypto/virtio/virtio_crypto.lto.o
> > >
> > > $ clang --version
> > > clang version 11.1.0 (https://github.com/llvm/llvm-project.git
> > > 1fdec59bffc11ae37eb51a1b9869f0696bfd5312)
> > > Target: x86_64-unknown-linux-gnu
> > > Thread model: posix
> > > InstalledDir: /home/yhs/work/llvm-project/llvm/build/install/bin
> > >
> > > clang12 is okay:
> > >
> > > LTO vmlinux.o
> > > OBJTOOL vmlinux.o
> > > MODPOST vmlinux.symvers
> > > MODINFO modules.builtin.modinfo
> > > GEN modules.builtin
> > > LD .tmp_vmlinux.btf
> > > BTF .btf.vmlinux.bin.o
> > > LD .tmp_vmlinux.kallsyms1
> > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > AS .tmp_vmlinux.kallsyms1.S
> > > LD .tmp_vmlinux.kallsyms2
> > > KSYMS .tmp_vmlinux.kallsyms2.S
> > >
> > > $ clang --version
> > > clang version 12.0.0 (https://github.com/llvm/llvm-project.git
> > > 31001be371e8f2c74470e727e54503fb2aabec8b)
> > > Target: x86_64-unknown-linux-gnu
> > > Thread model: posix
> > > InstalledDir: /home/yhs/work/llvm-project/llvm/build/install/bin
> > >
> > > I think we do not need to fix pahole for llvm11.
> > > When linus tree 5.12 is out. clang 12 should have been released
> > > or very close, we can just recommend clang 12 and later.
> >
> > Agreed, and it is just for _thin_ LTO, those warnings don't pop up when
> > building for full LTO with clang 11, the one in Fedora 33.
> >
> > And Fedora 34 beta has clang/llvm 12.0, so we're good.
> >
> > /me goes back to building clang/llvm HEAD, reducing the number of linker
> > instances to 1 as I have just 32GB of ram in this Ryzen machine... ;-)
>
> 32GB should be enough for a lot of parallel links - unless you're
> using ld.bfd - highly advised to switch to gold or lld & then you
> shuold be able to do a fair number of parallel links without loads of
> thrashing.
>
> https://llvm.org/docs/GettingStarted.html#common-problems discusses a
> few things to try
Thanks for the pointer!
- Arnaldo
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 18:17 ` David Blaikie
2021-04-06 18:20 ` Arnaldo Carvalho de Melo
@ 2021-04-06 18:22 ` Fāng-ruì Sòng
1 sibling, 0 replies; 33+ messages in thread
From: Fāng-ruì Sòng @ 2021-04-06 18:22 UTC (permalink / raw)
To: David Blaikie
Cc: Arnaldo Carvalho de Melo, Yonghong Song, Bill Wendling,
Jiri Olsa, dwarves, Alexei Starovoitov, Andrii Nakryiko, bpf,
kernel-team, Nick Desaulniers
On Tue, Apr 6, 2021 at 11:18 AM David Blaikie <dblaikie@gmail.com> wrote:
>
> On Tue, Apr 6, 2021 at 11:03 AM Arnaldo Carvalho de Melo
> <arnaldo.melo@gmail.com> wrote:
> >
> > Em Tue, Apr 06, 2021 at 10:48:22AM -0700, Yonghong Song escreveu:
> > >
> > >
> > > On 4/6/21 10:23 AM, Yonghong Song wrote:
> > > >
> > > >
> > > > On 4/6/21 10:03 AM, Arnaldo Carvalho de Melo wrote:
> > > > > Em Tue, Apr 06, 2021 at 01:59:30PM -0300, Arnaldo Carvalho de Melo
> > > > > escreveu:
> > > > > > Em Tue, Apr 06, 2021 at 01:55:54PM -0300, Arnaldo Carvalho de
> > > > > > Melo escreveu:
> > > > > > > Em Tue, Apr 06, 2021 at 01:40:20PM -0300, Arnaldo Carvalho
> > > > > > > de Melo escreveu:
> > > > > > > > Em Tue, Apr 06, 2021 at 10:22:37AM -0300, Arnaldo
> > > > > > > > Carvalho de Melo escreveu:
> > > > > > > > > I'm seeing these here:
> > > > > > >
> > > > > > > > > [acme@five bpf]$ rm -f ../build/bpf_clang_thin_lto/*vmlinu*
> > > > > > > > > [acme@five bpf]$ time make -j28 LLVM=1 LLVM_IAS=1
> > > > > > > > > O=../build/bpf_clang_thin_lto/ vmlinux
> > > > > > > > > make[1]: Entering directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > > > > > > > GEN Makefile
> > > > > > > > > DESCEND objtool
> > > > > > > > > DESCEND bpf/resolve_btfids
> > > > > > > > > CALL /home/acme/git/bpf/scripts/atomic/check-atomics.sh
> > > > > > > > > CALL /home/acme/git/bpf/scripts/checksyscalls.sh
> > > > > > > > > CHK include/generated/compile.h
> > > > > > > > > GEN .version
> > > > > > > > > CHK include/generated/compile.h
> > > > > > > > > UPD include/generated/compile.h
> > > > > > > > > CC init/version.o
> > > > > > > > > AR init/built-in.a
> > > > > > > > > GEN .tmp_initcalls.lds
> > > > > > > > > LTO vmlinux.o
> > > > > > > > > OBJTOOL vmlinux.o
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_init_avx_gen2()+0x12: unsupported stack
> > > > > > > > > pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_enc_update_avx_gen2()+0x12: unsupported
> > > > > > > > > stack pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_dec_update_avx_gen2()+0x12: unsupported
> > > > > > > > > stack pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_finalize_avx_gen2()+0x12: unsupported
> > > > > > > > > stack pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_init_avx_gen4()+0x12: unsupported stack
> > > > > > > > > pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_enc_update_avx_gen4()+0x12: unsupported
> > > > > > > > > stack pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_dec_update_avx_gen4()+0x12: unsupported
> > > > > > > > > stack pointer realignment
> > > > > > > > > vmlinux.o: warning: objtool:
> > > > > > > > > aesni_gcm_finalize_avx_gen4()+0x12: unsupported
> > > > > > > > > stack pointer realignment
> > > > > > > > > MODPOST vmlinux.symvers
> > > > > > > > > MODINFO modules.builtin.modinfo
> > > > > > > > > GEN modules.builtin
> > > > > > > > > LD .tmp_vmlinux.btf
> > > > > > > > > BTF .btf.vmlinux.bin.o
> > > > > > > > > LD .tmp_vmlinux.kallsyms1
> > > > > > > > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > > > > > > > AS .tmp_vmlinux.kallsyms1.S
> > > > > > > > > LD .tmp_vmlinux.kallsyms2
> > > > > > > > > KSYMS .tmp_vmlinux.kallsyms2.S
> > > > > > > > > AS .tmp_vmlinux.kallsyms2.S
> > > > > > > > > LD vmlinux
> > > > > > > > > BTFIDS vmlinux
> > > > > > > > > WARN: multiple IDs found for 'inode': 232, 28822 - using 232
> > > > > > > > > WARN: multiple IDs found for 'file': 374, 28855 - using 374
> > > > > > > > > WARN: multiple IDs found for 'path': 379, 28856 - using 379
> > > > > > > > > WARN: multiple IDs found for 'vm_area_struct': 177, 28929 - using 177
> > > > > > > > > WARN: multiple IDs found for 'task_struct': 97, 28966 - using 97
> > > > > > > > > WARN: multiple IDs found for 'seq_file': 510, 29059 - using 510
> > > > > > > > > WARN: multiple IDs found for 'inode': 232, 29345 - using 232
> > > > > > > > > WARN: multiple IDs found for 'file': 374, 29429 - using 374
> > > > > > > > > WARN: multiple IDs found for 'path': 379, 29430 - using 379
> > > > > > > > > WARN: multiple IDs found for 'vm_area_struct': 177, 29471 - using 177
> > > > > > > > > WARN: multiple IDs found for 'task_struct': 97, 29481 - using 97
> > > > > > > > > WARN: multiple IDs found for 'seq_file': 510, 29512 - using 510
> > > > > > > > > SORTTAB vmlinux
> > > > > > > > > SYSMAP System.map
> > > > > > > > > make[1]: Leaving directory '/home/acme/git/build/bpf_clang_thin_lto'
> > > > > > > > >
> > > > > > > > > [acme@five pahole]$ clang -v
> > > > > > > > > clang version 11.0.0 (Fedora 11.0.0-2.fc33)
> > > >
> > > > This could be due to the compiler. The clang 11 is used here. Sedat is
> > > > using clang 12 and didn't see warnings and I am using clang dev branch
> > > > (clang 13) and didn't see warnings either. clang 11 could generate
> > > > some debuginfo where pahole didn't handle it properly.
> > > >
> > > > I tried to build locally with clang 11 but it crashed as I enabled
> > > > assert during compiler build. Will try a little bit more.
> > >
> > > Yes, I can see it with llvm11:
> > >
> > > LD vmlinux
> > >
> > >
> > > BTFIDS vmlinux
> > >
> > >
> > > WARN: multiple IDs found for 'inode': 245, 36255 - using 245
> > >
> > >
> > > WARN: multiple IDs found for 'file': 390, 36288 - using 390
> > >
> > >
> > > WARN: multiple IDs found for 'path': 395, 36289 - using 395
> > >
> > >
> > > WARN: multiple IDs found for 'vm_area_struct': 190, 36362 - using 190
> > >
> > >
> > > WARN: multiple IDs found for 'task_struct': 93, 36399 - using 93
> > >
> > >
> > > WARN: multiple IDs found for 'seq_file': 524, 36498 - using 524
> > >
> > >
> > > WARN: multiple IDs found for 'inode': 245, 36784 - using 245
> > >
> > >
> > > WARN: multiple IDs found for 'file': 390, 36868 - using 390
> > >
> > >
> > > WARN: multiple IDs found for 'path': 395, 36869 - using 395
> > >
> > >
> > > WARN: multiple IDs found for 'vm_area_struct': 190, 36910 - using 190
> > >
> > >
> > > WARN: multiple IDs found for 'task_struct': 93, 36920 - using 93
> > >
> > >
> > > WARN: multiple IDs found for 'seq_file': 524, 36951 - using 524
> > >
> > >
> > > SORTTAB vmlinux
> > >
> > >
> > > SYSMAP System.map
> > >
> > >
> > > LTO [M] crypto/crypto_engine.lto.o
> > >
> > >
> > > LTO [M] drivers/crypto/virtio/virtio_crypto.lto.o
> > >
> > > $ clang --version
> > > clang version 11.1.0 (https://github.com/llvm/llvm-project.git
> > > 1fdec59bffc11ae37eb51a1b9869f0696bfd5312)
> > > Target: x86_64-unknown-linux-gnu
> > > Thread model: posix
> > > InstalledDir: /home/yhs/work/llvm-project/llvm/build/install/bin
> > >
> > > clang12 is okay:
> > >
> > > LTO vmlinux.o
> > > OBJTOOL vmlinux.o
> > > MODPOST vmlinux.symvers
> > > MODINFO modules.builtin.modinfo
> > > GEN modules.builtin
> > > LD .tmp_vmlinux.btf
> > > BTF .btf.vmlinux.bin.o
> > > LD .tmp_vmlinux.kallsyms1
> > > KSYMS .tmp_vmlinux.kallsyms1.S
> > > AS .tmp_vmlinux.kallsyms1.S
> > > LD .tmp_vmlinux.kallsyms2
> > > KSYMS .tmp_vmlinux.kallsyms2.S
> > >
> > > $ clang --version
> > > clang version 12.0.0 (https://github.com/llvm/llvm-project.git
> > > 31001be371e8f2c74470e727e54503fb2aabec8b)
> > > Target: x86_64-unknown-linux-gnu
> > > Thread model: posix
> > > InstalledDir: /home/yhs/work/llvm-project/llvm/build/install/bin
> > >
> > > I think we do not need to fix pahole for llvm11.
> > > When linus tree 5.12 is out. clang 12 should have been released
> > > or very close, we can just recommend clang 12 and later.
> >
> > Agreed, and it is just for _thin_ LTO, those warnings don't pop up when
> > building for full LTO with clang 11, the one in Fedora 33.
> >
> > And Fedora 34 beta has clang/llvm 12.0, so we're good.
> >
> > /me goes back to building clang/llvm HEAD, reducing the number of linker
> > instances to 1 as I have just 32GB of ram in this Ryzen machine... ;-)
>
> 32GB should be enough for a lot of parallel links - unless you're
> using ld.bfd - highly advised to switch to gold or lld & then you
> shuold be able to do a fair number of parallel links without loads of
> thrashing.
>
> https://llvm.org/docs/GettingStarted.html#common-problems discusses a
> few things to try
>
> - Dave
In the Linux kernel land I remember ld.lld can use more memory than GNU ld.
There are some lkp bot reports related to this.
It may be related to GNU ld not mmaping(?) input files. In any case no
deep analysis has been performed tracking down the potential issues.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu()
2021-04-06 18:04 ` Arnaldo Carvalho de Melo
@ 2021-04-06 18:31 ` Nick Desaulniers
0 siblings, 0 replies; 33+ messages in thread
From: Nick Desaulniers @ 2021-04-06 18:31 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Yonghong Song, Bill Wendling, Jiri Olsa, dwarves,
Alexei Starovoitov, Andrii Nakryiko, bpf, David Blaikie,
Fāng-ruì Sòng, kernel-team
On Tue, Apr 6, 2021 at 11:04 AM Arnaldo Carvalho de Melo
<acme@kernel.org> wrote:
>
> Em Tue, Apr 06, 2021 at 03:03:29PM -0300, Arnaldo Carvalho de Melo escreveu:
> > /me goes back to building clang/llvm HEAD, reducing the number of linker
> > instances to 1 as I have just 32GB of ram in this Ryzen machine... ;-)
>
> And guess what takes a long time?
>
> [ 61%] Linking CXX executable ../../bin/llvm-lto
During configuration of LLVM (cmake):
$ cmake ... -DLLVM_ENABLE_LLD=ON
to link the binaries with LLD, which should be able to link using all cores.
https://llvm.org/docs/CMake.html
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2021-04-06 18:31 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-01 2:58 [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu() Yonghong Song
2021-04-01 2:58 ` [PATCH dwarves 1/2] dwarf_loader: check .debug_abbrev for cross-cu references Yonghong Song
2021-04-01 18:52 ` Nick Desaulniers
2021-04-01 19:36 ` Arnaldo
2021-04-01 20:54 ` Yonghong Song
2021-04-01 2:58 ` [PATCH dwarves 2/2] dwarf_loader: check .notes section for lto build info Yonghong Song
2021-04-01 12:59 ` [PATCH dwarves 0/2] dwarf_loader: improve cus__merging_cu() Arnaldo Carvalho de Melo
2021-04-01 18:50 ` Nick Desaulniers
2021-04-01 19:35 ` Bill Wendling
2021-04-01 20:56 ` Bill Wendling
2021-04-01 21:59 ` Yonghong Song
2021-04-02 19:44 ` Bill Wendling
2021-04-06 13:22 ` Arnaldo Carvalho de Melo
2021-04-06 13:23 ` Arnaldo Carvalho de Melo
2021-04-06 16:40 ` Arnaldo Carvalho de Melo
2021-04-06 16:55 ` Arnaldo Carvalho de Melo
2021-04-06 16:59 ` Arnaldo Carvalho de Melo
2021-04-06 17:03 ` Arnaldo Carvalho de Melo
2021-04-06 17:07 ` Arnaldo Carvalho de Melo
2021-04-06 17:25 ` Arnaldo Carvalho de Melo
2021-04-06 17:23 ` Yonghong Song
2021-04-06 17:34 ` Arnaldo Carvalho de Melo
2021-04-06 17:36 ` Arnaldo Carvalho de Melo
2021-04-06 17:48 ` Yonghong Song
2021-04-06 18:03 ` Arnaldo Carvalho de Melo
2021-04-06 18:04 ` Arnaldo Carvalho de Melo
2021-04-06 18:31 ` Nick Desaulniers
2021-04-06 18:17 ` David Blaikie
2021-04-06 18:20 ` Arnaldo Carvalho de Melo
2021-04-06 18:22 ` Fāng-ruì Sòng
2021-04-06 17:09 ` Jiri Olsa
2021-04-02 13:27 ` Arnaldo Carvalho de Melo
2021-04-02 14:34 ` Yonghong Song
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).