All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Heiko Carstens <hca@linux.ibm.com>
Cc: gor@linux.ibm.com, agordeev@linux.ibm.com,
	borntraeger@linux.ibm.com, svens@linux.ibm.com, morbo@google.com,
	justinstitt@google.com, linux-s390@vger.kernel.org,
	llvm@lists.linux.dev, patches@lists.linux.dev,
	Ulrich Weigand <ulrich.weigand@de.ibm.com>
Subject: Re: [PATCH] s390/boot: Add 'alloc' to info.bin .vmlinux.info section flags
Date: Mon, 19 Feb 2024 16:16:23 -0700	[thread overview]
Message-ID: <20240219231623.GA2565406@dev-arch.thelio-3990X> (raw)
In-Reply-To: <20240219113248.16287-C-hca@linux.ibm.com>

Hi Heiko,

On Mon, Feb 19, 2024 at 12:32:48PM +0100, Heiko Carstens wrote:
> On Fri, Feb 16, 2024 at 12:55:53PM -0700, Nathan Chancellor wrote:
> > When attempting to boot a kernel compiled with OBJCOPY=llvm-objcopy,
> > there is a crash right at boot:
> > 
> >   Out of memory allocating 6d7800 bytes 8 aligned in range 0:20000000
> >   Reserved memory ranges:
> >   0000000000000000 a394c3c30d90cdaf DECOMPRESSOR
> >   Usable online memory ranges (info source: sclp read info [3]):
> >   0000000000000000 0000000020000000
> >   Usable online memory total: 20000000 Reserved: a394c3c30d90cdaf Free: 0
> >   Call Trace:
> >   (sp:0000000000033e90 [<0000000000012fbc>] physmem_alloc_top_down+0x5c/0x104)
> >    sp:0000000000033f00 [<0000000000011d56>] startup_kernel+0x3a6/0x77c
> >    sp:0000000000033f60 [<00000000000100f4>] startup_normal+0xd4/0xd4
> > 
> > GNU objcopy does not have any issues. Looking at differences between the
> > object files in each build reveals info.bin does not get properly
> > populated with llvm-objcopy, which results in an empty .vmlinux.info
> > section.
> ...
> > Closes: https://github.com/ClangBuiltLinux/linux/issues/1996
> > Link: https://github.com/llvm/llvm-project/commit/3c02cb7492fc78fb678264cebf57ff88e478e14f
> > Suggested-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> 
> Thanks a lot, applied!
> 
> However when building the kernel with "LLVM=1" I can see

Thanks for testing, we are so close!

> something else which looks like an llvm-objdump bug to me:
> 
> $make LLVM=1 bzImage
> ...
>   SECTCMP .boot.data
> llvm-objdump: warning: section '.boot.data' mentioned in a -j/--section option, but not found in any input file
> 
> This works without warning with GNU objcopy, and actually the output
> is also different:
> 
> $ objdump -v
> GNU objdump (GNU Binutils for Ubuntu) 2.41
> 
> $ objdump -t -j .boot.data arch/s390/boot/vmlinux
> 
> arch/s390/boot/vmlinux:     file format elf64-s390
> 
> SYMBOL TABLE:
> 0000000000020000 l     O .boot.data     0000000000003000 sclp_info_sccb
> 00000000000240e0 l     O .boot.data     0000000000000001 sclp_info_sccb_valid
> 0000000000023010 g     O .boot.data     0000000000000008 ident_map_size
> 0000000000023018 g     O .boot.data     00000000000010c8 physmem_info
> 00000000000250e2 g       .boot.data     0000000000000000 __boot_data_end
> 0000000000020000 g       .boot.data     0000000000000000 __boot_data_start
> 00000000000240e2 g     O .boot.data     0000000000001000 early_command_line
> 0000000000023008 g     O .boot.data     0000000000000008 early_ipl_comp_list_size
> 0000000000023000 g     O .boot.data     0000000000000008 early_ipl_comp_list_addr
> 
> While with llvm-copy:
> 
> $ llvm-objdump --version
> LLVM (http://llvm.org/):
>   LLVM version 19.0.0git
> 
> $ llvm-objdump -t -j .boot.data arch/s390/boot/vmlinux
> 
> arch/s390/boot/vmlinux: file format elf64-s390
> 
> SYMBOL TABLE:
> 0000000000000200 l       .head.text     0000000000000000 ipl_start
> 0000000000010020 l       .head.text     00000000000000d4 startup_normal
> 00000000000101b0 l       .head.text     00000000000000b2 startup_kdump
> 0000000000010280 l       .head.text     000000000000005a startup_pgm_check_handler
> 000000000001025c l       .head.text     0000000000000000 startup_kdump_relocated
> 0000000000000000 l    df *ABS*  0000000000000000 als.c
> 000000000001e040 l     O .rodata        0000000000000018 als
> 000000000001f6f0 l     O .data  0000000000000050 print_missing_facilities.als_str
> 0000000000011800 l     F .text  00000000000000e2 print_machine_type
> ...
> 0000000000020000 l     O .boot.data     0000000000003000 sclp_info_sccb
> 00000000000240e0 l     O .boot.data     0000000000000001 sclp_info_sccb_valid
> ... and so on (everything is dumped)
> llvm-objdump: warning: section '.boot.data' mentioned in a -j/--section option, but not found in any input file
> 
> So somehow llvmdump's "-j/--section" option doesn not seem to work.

Re-reading Jordan's response to my initial report about this a couple of
years ago at https://github.com/ClangBuiltLinux/linux/issues/859, I
think I understand the issue now. '-j' / '--section' does work but not
for '-t'.  It works for '-h' and a couple of other flags:

https://github.com/llvm/llvm-project/blob/61a96e5afadd034e7d13126f0e43731bbad7ad89/llvm/test/tools/llvm-objdump/section-filter.test

and because '-t' does not work with '-j', there is a warning because the
'-j' argument values went unhandled:

https://github.com/llvm/llvm-project/blob/61a96e5afadd034e7d13126f0e43731bbad7ad89/llvm/tools/llvm-objdump/llvm-objdump.cpp#L485
https://github.com/llvm/llvm-project/blob/61a96e5afadd034e7d13126f0e43731bbad7ad89/llvm/tools/llvm-objdump/llvm-objdump.cpp#L3672

which is what Jordan's upstream report (https://llvm.org/pr50085) was
about fixing. However, it may not be too hard to fix '-t' to work with
'-j', I intend to take a look at it at some point this week.

However, since I am more of a kernel hacker than I am an LLVM one, I
came up with a potential solution in arch/s390/boot/Makefile, which is
basically just filtering the symbol table manually with grep... it
appears to produce stable results based on a small test Makefile I have
to make sure the output looks sane before running through sha256sum. I'd
be happy to send this as a formal patch if you'd accept it for full
LLVM=1 compatibility with LLVM 19.0.0+ and Linux 6.9+.

Cheers,
Nathan

diff --git a/arch/s390/boot/Makefile b/arch/s390/boot/Makefile
index d40135efdec4..be3655825b4c 100644
--- a/arch/s390/boot/Makefile
+++ b/arch/s390/boot/Makefile
@@ -56,9 +56,9 @@ clean-files += vmlinux.map
 
 quiet_cmd_section_cmp = SECTCMP $*
 define cmd_section_cmp
-	s1=`$(OBJDUMP) -t -j "$*" "$<" | sort | \
+	s1=`$(OBJDUMP) -t "$<" | grep "\s$*\s\+" | sort | \
 		sed -n "/0000000000000000/! s/.*\s$*\s\+//p" | sha256sum`; \
-	s2=`$(OBJDUMP) -t -j "$*" "$(word 2,$^)" | sort | \
+	s2=`$(OBJDUMP) -t "$(word 2,$^)" | grep "\s$*\s\+" | sort | \
 		sed -n "/0000000000000000/! s/.*\s$*\s\+//p" | sha256sum`; \
 	if [ "$$s1" != "$$s2" ]; then \
 		echo "error: section $* differs between $< and $(word 2,$^)" >&2; \

  reply	other threads:[~2024-02-19 23:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-16 19:55 [PATCH] s390/boot: Add 'alloc' to info.bin .vmlinux.info section flags Nathan Chancellor
2024-02-19 11:32 ` Heiko Carstens
2024-02-19 23:16   ` Nathan Chancellor [this message]
2024-02-20 19:15     ` Heiko Carstens

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=20240219231623.GA2565406@dev-arch.thelio-3990X \
    --to=nathan@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=justinstitt@google.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=morbo@google.com \
    --cc=patches@lists.linux.dev \
    --cc=svens@linux.ibm.com \
    --cc=ulrich.weigand@de.ibm.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.