dwarves.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: dwarves@vger.kernel.org
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	bpf@vger.kernel.org, "Jiri Olsa" <jolsa@kernel.org>,
	"Jan Engelhardt" <jengelh@inai.de>,
	"Domenico Andreoli" <cavok@debian.org>,
	"Matthias Schwarzott" <zzam@gentoo.org>,
	"Andrii Nakryiko" <andriin@fb.com>, "Yonghong Song" <yhs@fb.com>,
	"Mark Wieelard" <mjw@redhat.com>,
	"Fāng-ruì Sòng" <maskray@google.com>,
	"Ilya Leoshkevich" <iii@linux.ibm.com>,
	"Bill Wendling" <morbo@google.com>,
	"David Blaikie" <dblaikie@gmail.com>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	"Sedat Dilek" <sedat.dilek@gmail.com>
Subject: ANNOUNCE: pahole v1.21 (clang's LTO edition, BTF floats)
Date: Mon, 12 Apr 2021 12:08:12 -0300	[thread overview]
Message-ID: <YHRiXNX1JUF2Az0A@kernel.org> (raw)

Hi,
 
	The v1.21 release of pahole and its friends is out, this time it's
about using clang to build the kernel with LTO, some DWARF5 fixes, supporting
floating types in the BTF encoder for s/390 sake and some misc fixes and
improvements. Ah, it should also be faster due to switching to using libbpf's
hashing routines.

Main git repo:

   git://git.kernel.org/pub/scm/devel/pahole/pahole.git

Mirror git repo:

   https://github.com/acmel/dwarves.git

tarball + gpg signature:

   https://fedorapeople.org/~acme/dwarves/dwarves-1.21.tar.xz
   https://fedorapeople.org/~acme/dwarves/dwarves-1.21.tar.bz2
   https://fedorapeople.org/~acme/dwarves/dwarves-1.21.tar.sign

	Thanks a lot to all the contributors and distro packagers, you're on the
CC list, I appreciate a lot the work you put into these tools,

Best Regards,
 
 - Arnaldo

DWARF loader:

- Handle DWARF5 DW_OP_addrx properly

  Part of the effort to support the subset of DWARF5 that is generated when building the kernel.

- Handle subprogram ret type with abstract_origin properly

  Adds a second pass to resolve abstract origin DWARF description of functions to aid
  the BTF encoder in getting the right return type.

- Check .notes section for LTO build info

  When LTO is used, currently only with clang, we need to do extra steps to handle references
  from one object (compile unit, aka CU) to another, a way for DWARF to avoid duplicating
  information.

- Check .debug_abbrev for cross-CU references

  When the kernel build process doesn't add an ELF note in vmlinux indicating that LTO was
  used and thus intra-CU references are present and thus we need to use a more expensive
  way to resolve types and (again) thus to encode BTF, we need to look at DWARF's .debug_abbrev
  ELF section to figure out if such intra-CU references are present.

- Permit merging all DWARF CU's for clang LTO built binary

  Allow not trowing away previously supposedly self contained compile units
  (objects, aka CU, aka Compile Units) as they have type descriptions that will
  be used in later CUs.

- Permit a flexible HASHTAGS__BITS

  So that we can use a more expensive algorithm when we need to keep previously processed
  compile units that will then be referenced by later ones to resolve types.

- Use a better hashing function, from libbpf

  Enabling patch to combine compile units when using LTO.

BTF encoder:

- Add --btf_gen_all flag

  A new command line to allow asking for the generation of all BTF encodings, so that we
  can stop adding new command line options to enable new encodings in the kernel Makefile.

- Match ftrace addresses within ELF functions

  To cope with differences in how DWARF and ftrace describes function boundaries.

- Funnel ELF error reporting through a macro

  To use libelf's elf_error() function, improving error messages.

- Sanitize non-regular int base type

  Cope with clang with dwarf5 non-regular int base types, tricky stuff, see yhs
  full explanation in the relevant cset.

- Add support for the floating-point types

  S/390 has floats'n'doubles in its arch specific linux headers, cope with that.

Pretty printer:

- Honour conf_fprintf.hex when printing enumerations

  If the user specifies --hex in the command line, honour it when printing enumerations.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

                 reply	other threads:[~2021-04-12 15:08 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=YHRiXNX1JUF2Az0A@kernel.org \
    --to=acme@kernel.org \
    --cc=andriin@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=cavok@debian.org \
    --cc=dblaikie@gmail.com \
    --cc=dwarves@vger.kernel.org \
    --cc=iii@linux.ibm.com \
    --cc=jengelh@inai.de \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maskray@google.com \
    --cc=mjw@redhat.com \
    --cc=morbo@google.com \
    --cc=ndesaulniers@google.com \
    --cc=sedat.dilek@gmail.com \
    --cc=yhs@fb.com \
    --cc=zzam@gentoo.org \
    /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).