llvm-objdump -t does not respect -j #859

nathanchance · 2020-02-07T16:37:48Z

$ make -j$(nproc) -s ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- CC=clang-11 HOSTCC=clang-11 O=out OBJDUMP=llvm-objdump-11 distclean defconfig bzImage
...
llvm-objdump-11: warning: section '.boot.preserved.data' mentioned in a -j/--section option, but not found in any input file
llvm-objdump-11: warning: section '.boot.data' mentioned in a -j/--section option, but not found in any input file
llvm-objdump-11: warning: section '.boot.preserved.data' mentioned in a -j/--section option, but not found in any input file
error: section .boot.preserved.data differs between vmlinux and arch/s390/boot/compressed/vmlinux
make[3]: *** [/linux/arch/s390/boot/Makefile:65: arch/s390/boot/section_cmp.boot.preserved.data] Error 1
make[3]: *** Waiting for unfinished jobs....
llvm-objdump-11: warning: section '.boot.data' mentioned in a -j/--section option, but not found in any input file
error: section .boot.data differs between vmlinux and arch/s390/boot/compressed/vmlinux
...

The text was updated successfully, but these errors were encountered:

We do not boot with QEMU because it only supports MARCH_Z900, which is disabled with clang: https://github.com/groeck/linux-build-test/blob/b8650ca8cdef921992b71db582b9bbdc4efb0ab3/rootfs/s390/run-qemu-s390.sh#L22 https://git.kernel.org/linus/c263a4e990b7296b074e33aa077239a0a28a818e We do not use llvm-objdump for the time being because of ClangBuiltLinux/linux#859. Signed-off-by: Nathan Chancellor <[email protected]>

nathanchance · 2020-02-18T06:28:55Z

llvm-objdump complains that it cannot find the section but it appears there when listing the section headers and it has the same size...

$ s390x-linux-gnu-objdump -h -j .boot.preserved.data out.s390/vmlinux

out.s390/vmlinux:     file format elf64-s390

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
 22 .boot.preserved.data 00001090  000000000136b000  000000000136b000  0126c000  2**12
                  CONTENTS, ALLOC, LOAD, DATA

$ llvm-objdump -h -j .boot.preserved.data out.s390/vmlinux

out.s390/vmlinux:       file format ELF64-s390

Sections:
Idx Name                 Size     VMA              Type
 22 .boot.preserved.data 00001090 000000000136b000 DATA

$ s390x-linux-gnu-objdump -t -j .boot.preserved.data out.s390/vmlinux

out.s390/vmlinux:     file format elf64-s390

SYMBOL TABLE:
000000000136b000 l    d  .boot.preserved.data   0000000000000000 .boot.preserved.data
000000000136c040 g     O .boot.preserved.data   0000000000000008 __swsusp_reset_dma
000000000136c090 g       .boot.preserved.data   0000000000000000 _edata
000000000136b000 g     O .boot.preserved.data   0000000000001000 ipl_block
000000000136b000 g       .boot.preserved.data   0000000000000000 __boot_data_preserved_start
000000000136c020 g     O .boot.preserved.data   0000000000000008 __sdma
000000000136c038 g     O .boot.preserved.data   0000000000000008 __stop_dma_ex_table
000000000136c08c g     O .boot.preserved.data   0000000000000004 zlib_dfltcc_support
000000000136c008 g     O .boot.preserved.data   0000000000000008 __edma
000000000136c028 g     O .boot.preserved.data   0000000000000008 __start_dma_ex_table
000000000136c018 g     O .boot.preserved.data   0000000000000008 __kaslr_offset
000000000136c078 g     O .boot.preserved.data   0000000000000008 ipl_cert_list_size
000000000136c084 g     O .boot.preserved.data   0000000000000004 ipl_secure_flag
000000000136c080 g     O .boot.preserved.data   0000000000000004 ipl_block_valid
000000000136c000 g     O .boot.preserved.data   0000000000000008 __diag210_tmp_dma
000000000136c088 g     O .boot.preserved.data   0000000000000004 prot_virt_guest
000000000136c048 g     O .boot.preserved.data   0000000000000028 diag_dma_ops
000000000136c030 g     O .boot.preserved.data   0000000000000008 __stext_dma
000000000136c010 g     O .boot.preserved.data   0000000000000008 __etext_dma
000000000136c090 g       .boot.preserved.data   0000000000000000 __boot_data_preserved_end
000000000136c070 g     O .boot.preserved.data   0000000000000008 ipl_cert_list_addr

$ llvm-objdump -t -j .boot.preserved.data out.s390/vmlinux

out.s390/vmlinux:       file format ELF64-s390

SYMBOL TABLE:
0000000000100000 l    d  .text  00000000 .text
0000000000ea6000 l    d  .rodata        00000000 .rodata
000000000112ae94 l    d  .interp        00000000 .interp
000000000112aea3 l    d  .dynstr        00000000 .dynstr
0000000001138708 l    d  .hash  00000000 .hash
0000000001141098 l    d  .gnu.hash      00000000 .gnu.hash
...
llvm-objdump: warning: section '.boot.preserved.data' mentioned in a -j/--section option, but not found in any input file

cc @rupprecht

nathanchance · 2020-02-18T06:29:33Z

This comes from arch/s390/boot/Makefile, where it is doing some section comparisons to make sure that they match: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/s390/boot/Makefile#n48

nathanchance · 2021-04-22T22:46:37Z

The warnings are still present but the build does not error:

$ make -skj"$(nproc)" ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- LD=s390x-linux-gnu-ld LLVM=1 OBJCOPY=s390x-linux-gnu-objcopy defconfig all
...
llvm-objdump: warning: section '.boot.data' mentioned in a -j/--section option, but not found in any input file
llvm-objdump: warning: section '.boot.preserved.data' mentioned in a -j/--section option, but not found in any input file
llvm-objdump: warning: section '.boot.data' mentioned in a -j/--section option, but not found in any input file
llvm-objdump: warning: section '.boot.preserved.data' mentioned in a -j/--section option, but not found in any input file
...

Might mean the check might not be working properly?

nickdesaulniers · 2021-04-23T01:55:37Z

Does the error string "error: section $* differs between $< and $(word 2,$^)" print and show which object files are being compared?

rupprecht · 2021-04-23T02:47:36Z

I'm not sure what the original error was. The warning seems benign (should not be firing) but should be fixed. Filed as http://llvm.org/PR50085.

It looks like the warning for -j only fires correctly for certain flags. We keep track of which sections we "see" in different flags (e.g. -h), but for -t, we print the symbol table, we don't iterate over any sections -- so in a sense we never "saw" any sections, and by extension, we never saw the .boot.data sections, hence the (erroneous) warning.

More minimal repro:

$ bin/clang -xc -c /dev/null -o /tmp/null.o
$ bin/llvm-objdump -j .text -h /tmp/null.o  # -j and -h work fine

/tmp/null.o:    file format elf64-x86-64

Sections:
Idx Name          Size     VMA              Type
  2 .text         00000000 0000000000000000 TEXT
$ bin/llvm-objdump -j .text -t /tmp/null.o  # -j and -t don't work fine

/tmp/null.o:    file format elf64-x86-64

SYMBOL TABLE:
0000000000000000 l    df *ABS*  0000000000000000 null
bin/llvm-objdump: warning: section '.text' mentioned in a -j/--section option, but not found in any input file

However, GNU objdump prints the same warning for my minimal repro above. And it looks like you don't see the warning with s390x-linux-gnu-objdump? Strange...

nickdesaulniers · 2023-08-24T20:18:20Z

So I still see these warnings with llvm-objcopy-18, but I no longer see the error+build failure.

...
$ make LLVM=1 ARCH=s390 LD=s390x-linux-gnu-ld.bfd OBJCOPY=s390x-linux-gnu-objcopy -j128 all
  SECTCMP .boot.preserved.data
llvm-objdump: warning: section '.boot.preserved.data' mentioned in a -j/--section option, but not found in any input file
llvm-objdump: warning: section '.boot.data' mentioned in a -j/--section option, but not found in any input file
llvm-objdump: warning: section '.boot.preserved.data' mentioned in a -j/--section option, but not found in any input file
llvm-objdump: warning: section '.boot.data' mentioned in a -j/--section option, but not found in any input file
  OBJCOPY arch/s390/boot/bzImage
$ echo $?
0

nathanchance · 2024-02-19T23:22:07Z

I've retitled this issue to be a little bit more accurate in light of my comments at https://lore.kernel.org/[email protected]/, where I also suggest a kernel side workaround for s390 (even though this is no longer s390 specific).

$ s390x-linux-gnu-objdump -t -j .boot.data vmlinux.full

vmlinux.full:     file format elf64-s390

SYMBOL TABLE:
0000000001951000 l     O .boot.data     0000000000003000 sclp_info_sccb
00000000019550e0 l     O .boot.data     0000000000000001 sclp_info_sccb_valid
00000000019550e2 g     O .boot.data     0000000000001000 early_command_line
0000000001954018 g     O .boot.data     00000000000010c8 physmem_info
0000000001954010 g     O .boot.data     0000000000000008 ident_map_size
0000000001954000 g     O .boot.data     0000000000000008 early_ipl_comp_list_addr
0000000001954008 g     O .boot.data     0000000000000008 early_ipl_comp_list_size
0000000001957000 g       .boot.data     0000000000000000 _samode31
0000000001951000 g       .boot.data     0000000000000000 __boot_data_start
00000000019560e2 g       .boot.data     0000000000000000 __boot_data_end

$ llvm-objdump -t -j .boot.data vmlinux.full

vmlinux.full:   file format elf64-s390

SYMBOL TABLE:
0000000000100040 l     O .text  0000000000000010 dw_psw
0000000000000000 l    df *ABS*  0000000000000000 main.c
00000000001001b0 l     F .text  00000000000000c6 trace_event_raw_event_initcall_level
0000000000100280 l     F .text  0000000000000100 perf_trace_initcall_level
0000000000100380 l     F .text  000000000000007c trace_event_raw_event_initcall_start
0000000000100400 l     F .text  00000000000000b8 perf_trace_initcall_start
00000000001004c0 l     F .text  0000000000000084 trace_event_raw_event_initcall_finish
0000000000100550 l     F .text  00000000000000c0 perf_trace_initcall_finish
0000000000100610 l     F .text  0000000000000006 __bpf_trace_initcall_level
0000000000100620 l     F .text  0000000000000006 __bpf_trace_initcall_start
0000000000100630 l     F .text  000000000000000a __bpf_trace_initcall_finish
00000000018d7000 l     F .init.text     0000000000000016 set_reset_devices
00000000018d7020 l     F .init.text     0000000000000018 debug_kernel
00000000018d7040 l     F .init.text     0000000000000018 quiet_kernel
00000000018d7060 l     F .init.text     000000000000005e loglevel
...

With this issue resolved, ARCH=s390 on Linux 6.9+ should build cleanly with LLVM=1 using LLVM 19.0.0+ :)

nathanchance · 2024-02-20T20:45:43Z

I've submitted the workaround on the kernel side: https://lore.kernel.org/20240220-s390-work-around-llvm-objdump-t-j-v1-1-47bb0366a831@kernel.org/

…ee LLVM With LLVM main, which has the necessary changes to ld.lld and llvm-objcopy to support s390, and linux-next, which has the necessary changes to the kernel to support these tools, ARCH=s390 builds cleanly with LLVM=1. Cut builds that satisfy these conditions over to LLVM=1 so that regressions with this working setup do not occur. Link: llvm/llvm-project@fe3406e Link: llvm/llvm-project@3c02cb7 Link: ClangBuiltLinux/linux#859 Link: ClangBuiltLinux/linux#1991 Link: ClangBuiltLinux/linux#1992 Link: ClangBuiltLinux/linux#1993 Link: ClangBuiltLinux/linux#1994 Link: ClangBuiltLinux/linux#1995 Link: ClangBuiltLinux/linux#1996 Signed-off-by: Nathan Chancellor <[email protected]>

nathanchance · 2024-02-22T16:53:45Z

Kernel workaround accepted: https://git.kernel.org/s390/c/7f115ff4fc20698452ff4a1cbb9c790be10b0066

When building with OBJDUMP=llvm-objdump, there are a series of warnings from the section comparisons that arch/s390/boot/Makefile performs between vmlinux and arch/s390/boot/vmlinux: llvm-objdump: warning: section '.boot.preserved.data' mentioned in a -j/--section option, but not found in any input file llvm-objdump: warning: section '.boot.data' mentioned in a -j/--section option, but not found in any input file llvm-objdump: warning: section '.boot.preserved.data' mentioned in a -j/--section option, but not found in any input file llvm-objdump: warning: section '.boot.data' mentioned in a -j/--section option, but not found in any input file The warning is a little misleading, as these sections do exist in the input files. It is really pointing out that llvm-objdump does not match GNU objdump's behavior of respecting '-j' / '--section' in combination with '-t' / '--syms': $ s390x-linux-gnu-objdump -t -j .boot.data vmlinux.full vmlinux.full: file format elf64-s390 SYMBOL TABLE: 0000000001951000 l O .boot.data 0000000000003000 sclp_info_sccb 00000000019550e0 l O .boot.data 0000000000000001 sclp_info_sccb_valid 00000000019550e2 g O .boot.data 0000000000001000 early_command_line ... $ llvm-objdump -t -j .boot.data vmlinux.full vmlinux.full: file format elf64-s390 SYMBOL TABLE: 0000000000100040 l O .text 0000000000000010 dw_psw 0000000000000000 l df *ABS* 0000000000000000 main.c 00000000001001b0 l F .text 00000000000000c6 trace_event_raw_event_initcall_level 0000000000100280 l F .text 0000000000000100 perf_trace_initcall_level ... It may be possible to change llvm-objdump's behavior to match GNU objdump's behavior but the difficulty of that task has not yet been explored. The combination of '$(OBJDUMP) -t -j' is not common in the kernel tree on a whole, so workaround this tool difference by grepping for the sections in the full symbol table output in a similar manner to the sed invocation. This results in no visible change for GNU objdump users while fixing the warnings for OBJDUMP=llvm-objdump, further enabling use of LLVM=1 for ARCH=s390 with versions of LLVM that have support for s390 in ld.lld and llvm-objcopy. Reported-by: Heiko Carstens <[email protected]> Closes: https://lore.kernel.org/[email protected]/ Link: ClangBuiltLinux#859 Signed-off-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/20240220-s390-work-around-llvm-objdump-t-j-v1-1-47bb0366a831@kernel.org Signed-off-by: Heiko Carstens <[email protected]>

nathanchance added [BUG] Untriaged Something isn't working [TOOL] llvm-objdump The issue is relevant to LLVM objdump [ARCH] s390 This bug impacts ARCH=s390 labels Feb 7, 2020

nathanchance mentioned this issue Apr 2, 2020

driver: Enable llvm-objcopy and llvm-strip ClangBuiltLinux/continuous-integration#253

Merged

nickdesaulniers added the Reported upstream This bug was filed on LLVM’s issue tracker, Phabricator, or the kernel mailing list. label Jun 23, 2021

nathanchance mentioned this issue Feb 14, 2024

s390: ld.lld: error: unknown emulation: elf64_s390 #1524

Closed

nathanchance added [BUG] llvm A bug that should be fixed in upstream LLVM [PATCH] Exists There is a patch that fixes this issue and removed [BUG] Untriaged Something isn't working [ARCH] s390 This bug impacts ARCH=s390 labels Feb 19, 2024

nathanchance changed the title ~~s390 warning + error when using llvm-objdump~~ llvm-objdump -t does not respect -j Feb 19, 2024

nathanchance mentioned this issue Feb 21, 2024

Use LLVM=1 for ARCH=s390 on linux-next with tip of tree LLVM ClangBuiltLinux/continuous-integration2#712

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

llvm-objdump -t does not respect -j #859

llvm-objdump -t does not respect -j #859

nathanchance commented Feb 7, 2020

nathanchance commented Feb 18, 2020

Uh oh!

nathanchance commented Feb 18, 2020

Uh oh!

nathanchance commented Apr 22, 2021

Uh oh!

nickdesaulniers commented Apr 23, 2021

Uh oh!

rupprecht commented Apr 23, 2021

Uh oh!

nickdesaulniers commented Aug 24, 2023

Uh oh!

nathanchance commented Feb 19, 2024

Uh oh!

nathanchance commented Feb 20, 2024

Uh oh!

nathanchance commented Feb 22, 2024

Uh oh!

llvm-objdump -t does not respect -j #859

llvm-objdump -t does not respect -j #859

Comments

nathanchance commented Feb 7, 2020

nathanchance commented Feb 18, 2020

Uh oh!

nathanchance commented Feb 18, 2020

Uh oh!

nathanchance commented Apr 22, 2021

Uh oh!

nickdesaulniers commented Apr 23, 2021

Uh oh!

rupprecht commented Apr 23, 2021

Uh oh!

nickdesaulniers commented Aug 24, 2023

Uh oh!

nathanchance commented Feb 19, 2024

Uh oh!

nathanchance commented Feb 20, 2024

Uh oh!

nathanchance commented Feb 22, 2024

Uh oh!