From: Jiri Olsa <jolsa@redhat.com>
To: Yonghong Song <yhs@fb.com>
Cc: Jiri Olsa <jolsa@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Mark Wielaard <mjw@redhat.com>, Nick Clifton <nickc@redhat.com>,
Jesper Dangaard Brouer <brouer@redhat.com>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Andrii Nakryiko <andriin@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@chromium.org>,
Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH bpf-next] tools/resolve_btfids: Fix sections with wrong alignment
Date: Wed, 19 Aug 2020 19:36:18 +0200 [thread overview]
Message-ID: <20200819173618.GH177896@krava> (raw)
In-Reply-To: <254246ed-1b76-c435-a7bd-0783a29094d9@fb.com>
On Wed, Aug 19, 2020 at 08:31:51AM -0700, Yonghong Song wrote:
>
>
> On 8/19/20 2:23 AM, Jiri Olsa wrote:
> > The data of compressed section should be aligned to 4
> > (for 32bit) or 8 (for 64 bit) bytes.
> >
> > The binutils ld sets sh_addralign to 1, which makes libelf
> > fail with misaligned section error during the update as
> > reported by Jesper:
> >
> > FAILED elf_update(WRITE): invalid section alignment
> >
> > While waiting for ld fix, we can fix compressed sections
> > sh_addralign value manually.
> >
> > Adding warning in -vv mode when the fix is triggered:
> >
> > $ ./tools/bpf/resolve_btfids/resolve_btfids -vv vmlinux
> > ...
> > section(36) .comment, size 44, link 0, flags 30, type=1
> > section(37) .debug_aranges, size 45684, link 0, flags 800, type=1
> > - fixing wrong alignment sh_addralign 16, expected 8
> > section(38) .debug_info, size 129104957, link 0, flags 800, type=1
> > - fixing wrong alignment sh_addralign 1, expected 8
> > section(39) .debug_abbrev, size 1152583, link 0, flags 800, type=1
> > - fixing wrong alignment sh_addralign 1, expected 8
> > section(40) .debug_line, size 7374522, link 0, flags 800, type=1
> > - fixing wrong alignment sh_addralign 1, expected 8
> > section(41) .debug_frame, size 702463, link 0, flags 800, type=1
> > section(42) .debug_str, size 1017571, link 0, flags 830, type=1
> > - fixing wrong alignment sh_addralign 1, expected 8
> > section(43) .debug_loc, size 3019453, link 0, flags 800, type=1
> > - fixing wrong alignment sh_addralign 1, expected 8
> > section(44) .debug_ranges, size 1744583, link 0, flags 800, type=1
> > - fixing wrong alignment sh_addralign 16, expected 8
> > section(45) .symtab, size 2955888, link 46, flags 0, type=2
> > section(46) .strtab, size 2613072, link 0, flags 0, type=3
> > ...
> > update ok for vmlinux
> >
> > Another workaround is to disable compressed debug info data
> > CONFIG_DEBUG_INFO_COMPRESSED kernel option.
>
> So CONFIG_DEBUG_INFO_COMPRESSED is required to reproduce the bug, right?
correct
>
> I turned on CONFIG_DEBUG_INFO_COMPRESSED in my config and got a bunch of
> build failures.
>
> ld: drivers/crypto/virtio/virtio_crypto_algs.o: unable to initialize
> decompress status for section .debug_info
> ld: drivers/crypto/virtio/virtio_crypto_algs.o: unable to initialize
> decompress status for section .debug_info
> ld: drivers/crypto/virtio/virtio_crypto_algs.o: unable to initialize
> decompress status for section .debug_info
> ld: drivers/crypto/virtio/virtio_crypto_algs.o: unable to initialize
> decompress status for section .debug_info
> drivers/crypto/virtio/virtio_crypto_algs.o: file not recognized: File format
> not recognized
>
> ld: net/llc/llc_core.o: unable to initialize decompress status for section
> .debug_info
> ld: net/llc/llc_core.o: unable to initialize decompress status for section
> .debug_info
> ld: net/llc/llc_core.o: unable to initialize decompress status for section
> .debug_info
> ld: net/llc/llc_core.o: unable to initialize decompress status for section
> .debug_info
> net/llc/llc_core.o: file not recognized: File format not recognized
>
> ...
>
> The 'ld' in my system:
>
> $ ld -V
> GNU ld version 2.30-74.el8
> Supported emulations:
> elf_x86_64
> elf32_x86_64
> elf_i386
> elf_iamcu
> i386linux
> elf_l1om
> elf_k1om
> i386pep
> i386pe
> $
>
> Do you know what is the issue here?
mine's: GNU ld version 2.32-31.fc31
there's version info in commit:
10e68b02c861 Makefile: support compressed debug info
Compress the debug information using zlib. Requires GCC 5.0+ or Clang
5.0+, binutils 2.26+, and zlib.
cc-ing Nick Desaulniers, author of that patch.. any idea about the error above?
thanks,
jirka
next prev parent reply other threads:[~2020-08-19 17:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 9:23 [PATCH bpf-next] tools/resolve_btfids: Fix sections with wrong alignment Jiri Olsa
2020-08-19 15:31 ` Yonghong Song
2020-08-19 17:36 ` Jiri Olsa [this message]
2020-08-19 18:16 ` Nick Desaulniers
2020-08-19 21:30 ` Yonghong Song
2020-08-20 2:27 ` Fāng-ruì Sòng
2020-08-20 3:23 ` Yonghong Song
2020-08-20 10:18 ` Jiri Olsa
2020-08-20 10:18 ` Mark Wielaard
2020-08-20 15:51 ` Yonghong Song
2020-08-20 17:36 ` Mark Wielaard
2020-08-20 17:54 ` Yonghong Song
2020-08-20 21:24 ` Alexei Starovoitov
2020-08-19 17:02 ` Jesper Dangaard Brouer
2020-08-19 21:32 ` Yonghong Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200819173618.GH177896@krava \
--to=jolsa@redhat.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=kpsingh@chromium.org \
--cc=mjw@redhat.com \
--cc=ndesaulniers@google.com \
--cc=netdev@vger.kernel.org \
--cc=nickc@redhat.com \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.