From: Simon Marchi <simon.marchi@polymtl.ca>
To: Fangrui Song <maskray@google.com>, Alan Modra <amodra@gmail.com>,
Jan Beulich <jbeulich@suse.com>, Nick Clifton <nickc@redhat.com>
Cc: binutils@sourceware.org, gdb-patches@sourceware.org
Subject: Re: [PATCH v3] binutils, gdb: support zstd compressed debug sections
Date: Fri, 23 Sep 2022 10:32:43 -0400 [thread overview]
Message-ID: <7eadf897-9370-5a00-ae57-8e07251b8702@polymtl.ca> (raw)
In-Reply-To: <20220923040837.550160-1-maskray@google.com>
On 2022-09-23 00:08, Fangrui Song wrote:
> PR29397 PR29563: The new configure option --with-zstd defaults to auto.
> If pkgconfig/libzstd.pc is found, define HAVE_ZSTD and support zstd
> compressed debug sections for most tools.
>
> * bfd: for addr2line, objdump --dwarf, gdb, etc
> * gas: support --compress-debug-sections=zstd
> * ld: support ELFCOMPRESS_ZSTD input and --compress-debug-sections=zstd
> * objcopy: support ELFCOMPRESS_ZSTD input for
> --decompress-debug-sections and --compress-debug-sections=zstd
> * gdb: support ELFCOMPRESS_ZSTD input. The bfd change references zstd
> symbols, so gdb has to link against -lzstd in this patch.
>
> If zstd is not supported, ELFCOMPRESS_ZSTD input triggers an error. We
> can avoid HAVE_ZSTD if binutils-gdb imports zstd/ like zlib/, but this
> is too heavyweight, so don't do it for now.
>
> ```
> % ld/ld-new a.o
> ld/ld-new: a.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
> ...
>
> % ld/ld-new a.o --compress-debug-sections=zstd
> ld/ld-new: --compress-debug-sections=zstd: ld is not built with zstd support
>
> % binutils/objcopy --compress-debug-sections=zstd a.o b.o
> binutils/objcopy: --compress-debug-sections=zstd: binutils is not built with zstd support
>
> % binutils/objcopy b.o --decompress-debug-sections
> binutils/objcopy: zstd.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
> ...
> ```
> ---
> Changes from v1:
> * use PKG_CHECK_MODULES to check libzstd.pc
>
> Changes from v2:
> * Improve PKG_CHECK_MODULES, autoreconf -vf
> * objcopy: check --compress-debug-sections=zstd in a !HAVE_ZSTD build
Just one question: you moved PKG_PROG_PKG_CONFIG up in ld/configure.ac,
which I think is ok. But what about the other configure.ac files, don't
they need PKG_PROG_PKG_CONFIG too? gdb/configure.ac, for instance, uses
pkg-config for debuginfod. So if the user passes --without-debuginfod
--with-zstd, I expect things to fail, as the pkg-config will be skipped.
binutils/configure.ac probably has the same problem, since it uses
PKG_CHECK_MODULES for msgpack.
I would suggest using PKG_PROG_PKG_CONFIG at the top of all configure.ac
that use AM_ZSTD, out of precaution.
Simon
next prev parent reply other threads:[~2022-09-23 14:32 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-23 4:08 Fangrui Song
2022-09-23 14:32 ` Simon Marchi [this message]
2022-09-26 5:12 ` Alan Modra
2022-09-26 7:20 ` Fangrui Song
2022-09-26 13:30 ` Alan Modra
2022-09-26 14:08 ` Simon Marchi
2022-09-27 0:33 ` Alan Modra
2022-09-23 15:45 ` Nick Clifton
2022-09-23 15:58 ` Simon Marchi
2022-09-23 18:20 ` Fangrui Song
2022-09-23 18:57 ` Simon Marchi
2022-09-23 20:34 ` Fangrui Song
2022-09-24 5:43 ` Eli Zaretskii
2022-09-24 6:53 ` Enze Li
2022-09-24 7:13 ` Fangrui Song
2022-09-27 18:06 ` Tom Tromey
2022-09-27 18:08 ` Tom Tromey
2022-09-27 18:53 ` Fangrui Song
2022-09-29 11:43 ` Martin Liška
2022-09-29 20:17 ` Fangrui Song
2022-09-30 9:48 ` [PATCH][RFC] add --enable-zstd-compressed-debug-sections configure option Martin Liška
2022-09-30 11:25 ` Pedro Alves
2022-09-30 12:42 ` Martin Liška
2022-10-01 7:31 ` Fangrui Song
2022-10-03 7:49 ` Martin Liška
2022-10-03 7:50 ` [PATCH 1/2] refactor usage of compressed_debug_section_type Martin Liška
2022-10-11 7:14 ` Martin Liška
2022-10-11 12:06 ` Nick Clifton
2022-10-11 13:27 ` Martin Liška
2022-10-03 7:50 ` [PATCH 2/2] add --enable-default-compressed-debug-sections-algorithm configure option Martin Liška
2022-10-11 7:14 ` Martin Liška
2022-10-11 12:08 ` Nick Clifton
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=7eadf897-9370-5a00-ae57-8e07251b8702@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=jbeulich@suse.com \
--cc=maskray@google.com \
--cc=nickc@redhat.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 read-only IMAP folder(s) and NNTP newsgroup(s).