Skip to content

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

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom
Open
nathanchance opened this issue Feb 7, 2020 · 9 comments
Open

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

nathanchance opened this issue Feb 7, 2020 · 9 comments
Labels
[BUG] llvm A bug that should be fixed in upstream LLVM [PATCH] Exists There is a patch that fixes this issue Reported upstream This bug was filed on LLVM’s issue tracker, Phabricator, or the kernel mailing list. [TOOL] llvm-objdump The issue is relevant to LLVM objdump

Comments

@nathanchance
Copy link
Member 

$ 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
...
@nathanchance 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 added a commit to nathanchance/continuous-integration that referenced this issue Feb 7, 2020
@nathanchance
driver: Add support for s390
2a94c49 
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 <natechancellor@gmail.com>
nathanchance added a commit to nathanchance/continuous-integration that referenced this issue Feb 7, 2020
@nathanchance
driver: Add support for s390
8df10c9 
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 <natechancellor@gmail.com>
tpimh pushed a commit to ClangBuiltLinux/continuous-integration that referenced this issue Feb 14, 2020
@nathanchance @tpimh
driver: Add support for s390
931b90a 
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 <natechancellor@gmail.com>
@nathanchance
Copy link
Member Author

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
Copy link
Member Author

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 nathanchance mentioned this issue Apr 2, 2020
Merged
@nathanchance
Copy link
Member Author

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
Copy link
Member

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

@rupprecht
Copy link

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 nickdesaulniers added the Reported upstream This bug was filed on LLVM’s issue tracker, Phabricator, or the kernel mailing list. label Jun 23, 2021
@nickdesaulniers
Copy link
Member

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 nathanchance mentioned this issue Feb 14, 2024
Closed
@nathanchance 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 nathanchance changed the title s390 warning + error when using llvm-objdump llvm-objdump -t does not respect -j Feb 19, 2024
@nathanchance
Copy link
Member Author

I've retitled this issue to be a little bit more accurate in light of my comments at https://lore.kernel.org/20240219231623.GA2565406@dev-arch.thelio-3990X/, 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
Copy link
Member Author

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/

nathanchance added a commit to nathanchance/continuous-integration2 that referenced this issue Feb 21, 2024
@nathanchance
generator: yml: Use LLVM=1 for ARCH=s390 on linux-next with tip of tr…
c41724b 
…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 <nathan@kernel.org>
@nathanchance nathanchance mentioned this issue Feb 21, 2024
Merged
@nathanchance
Copy link
Member Author

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

staging-kernelci-org pushed a commit to kernelci/linux that referenced this issue Feb 23, 2024
@nathanchance @hcahca
s390/boot: workaround current 'llvm-objdump -t -j ...' behavior
7f115ff 
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 <hca@linux.ibm.com>
Closes: https://lore.kernel.org/20240219113248.16287-C-hca@linux.ibm.com/
Link: ClangBuiltLinux#859
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20240220-s390-work-around-llvm-objdump-t-j-v1-1-47bb0366a831@kernel.org
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
[BUG] llvm A bug that should be fixed in upstream LLVM [PATCH] Exists There is a patch that fixes this issue Reported upstream This bug was filed on LLVM’s issue tracker, Phabricator, or the kernel mailing list. [TOOL] llvm-objdump The issue is relevant to LLVM objdump
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rupprecht @nickdesaulniers @nathanchance