bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: sedat.dilek@gmail.com, Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: "Arnaldo Carvalho de Melo" <arnaldo.melo@gmail.com>,
	"Tom Stellard" <tstellar@redhat.com>,
	"Jiri Olsa" <jolsa@kernel.org>,
	dwarves@vger.kernel.org, bpf <bpf@vger.kernel.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Andrii Nakryiko" <andriin@fb.com>, "Yonghong Song" <yhs@fb.com>,
	"Hao Luo" <haoluo@google.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>
Subject: Re: [RFT] pahole 1.20 RC was Re: [PATCH] btf_encoder: Add extra checks for symbol names
Date: Wed, 03 Feb 2021 11:23:47 +0100	[thread overview]
Message-ID: <95233b493fd29b613f5bf3f92419528ce3298c14.camel@klomp.org> (raw)
In-Reply-To: <CA+icZUUTddV18rhZjaVif0a6BgpWtpj4mP1pyQ9cfh_e2xxvMQ@mail.gmail.com>

Hi,

On Wed, 2021-02-03 at 10:03 +0100, Sedat Dilek wrote:
> > It all looks to be working fine on my side. There is a compilation
> > error in our libbpf CI when building the latest pahole from sources
> > due to DW_FORM_implicit_const being undefined. I'm updating our VMs to
> > use Ubuntu Focal 20.04, up from Bionic 18.04, and that should
> > hopefully solve the issue due to newer versions of libdw. If you worry
> > about breaking others, though, we might want to add #ifndef guards and
> > re-define DW_FORM_implicit_const as 0x21 explicitly in pahole source
> > code.

I think that might be a good idea for older setups. But that also means
that the underlying elfutils libdw doesn't support DWARF5, so pahole
itself also wouldn't work (the define would only fix the compile time
issue, not the runtime issue of not being able to parse
DW_FORM_implicit_const). That might not be a problem because such
systems also wouldn't have GCC11 defaulting to DWARF5.

> > But otherwise, all good from what I can see in my environment.
> > Looking
> > forward to 1.20 release! I'll let you know if, after updating to
> > Ubuntu Focal, any new pahole issues crop up.
> > 
> 
> Last weekend I did some testing with
> <pahole.git#DW_AT_data_bit_offset> and DWARF-v5 support for the
> Linux-kernel.
> 
> The good: I was able to compile :-).
> The bad: My build-log grew up to 1.2GiB and I could not boot in QEMU.
> The ugly: I killed the archive which had all relevant material.

I think the build-log grew so much because of warnings about unknown
tags. At least when using GCC11 you'll get a couple of standardized
DWARF5 tags instead of the GNU extensions to DWARF4. That should be
solved by:

   commit d783117162c0212d4f75f6cea185f493d2f244e1
   Author: Mark Wielaard <mark@klomp.org>
   Date:   Sun Jan 31 01:27:31 2021 +0100

       dwarf_loader: Handle DWARF5 DW_TAG_call_site like DW_TAG_GNU_call_site

Cheers,

Mark

  reply	other threads:[~2021-02-03 10:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-12 18:40 [PATCH] btf_encoder: Add extra checks for symbol names Jiri Olsa
2021-01-12 19:20 ` Andrii Nakryiko
2021-01-12 19:47   ` Jiri Olsa
2021-01-12 20:17     ` Sedat Dilek
2021-01-13  0:27 ` Tom Stellard
2021-01-14  7:50   ` Sedat Dilek
2021-01-14 14:33     ` Tom Stellard
2021-01-14 14:39       ` Sedat Dilek
2021-01-21 13:38   ` Arnaldo Carvalho de Melo
2021-01-21 16:06     ` Sedat Dilek
2021-01-21 19:37       ` Arnaldo Carvalho de Melo
2021-01-21 20:53       ` Andrii Nakryiko
2021-01-22  2:07         ` Sedat Dilek
2021-01-22  4:11           ` Andrii Nakryiko
2021-01-28 20:00             ` [RFT] pahole 1.20 RC was " Arnaldo Carvalho de Melo
2021-01-28 20:57               ` Sedat Dilek
2021-01-28 21:11                 ` Arnaldo Carvalho de Melo
2021-01-28 22:28                   ` Sedat Dilek
2021-02-02  7:48               ` Andrii Nakryiko
2021-02-03  9:03                 ` Sedat Dilek
2021-02-03 10:23                   ` Mark Wielaard [this message]
2021-02-03 21:48                     ` Sedat Dilek
2021-02-03 23:21                       ` Andrii Nakryiko
2021-02-04  1:06                         ` Arnaldo Carvalho de Melo
2021-02-04  6:40                         ` Sedat Dilek
2021-01-21 17:37     ` Tom Stellard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=95233b493fd29b613f5bf3f92419528ce3298c14.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=arnaldo.melo@gmail.com \
    --cc=ast@kernel.org \
    --cc=berrange@redhat.com \
    --cc=bpf@vger.kernel.org \
    --cc=dwarves@vger.kernel.org \
    --cc=haoluo@google.com \
    --cc=jolsa@kernel.org \
    --cc=sedat.dilek@gmail.com \
    --cc=tstellar@redhat.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).