linux-parisc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Helge Deller <deller@gmx.de>, Sven Schnelle <svens@stackframe.org>
Cc: linux-parisc@vger.kernel.org
Subject: Re: [PATCH] parisc: strip debug information when building compressed images
Date: Wed, 31 Jul 2019 12:45:49 -0700	[thread overview]
Message-ID: <1564602349.3319.49.camel@HansenPartnership.com> (raw)
In-Reply-To: <366ad43f-c9a6-1291-5cca-014172f0fd62@gmx.de>

On Wed, 2019-07-31 at 21:40 +0200, Helge Deller wrote:
> On 31.07.19 21:37, James Bottomley wrote:
> > On Wed, 2019-07-31 at 21:28 +0200, Helge Deller wrote:
> > > * Sven Schnelle <svens@stackframe.org>:
> > > > When compiling the kernel with debug information i got the
> > > > following error:
> > > > 
> > > > hppa-linux-gnu-ld: section .text LMA
> > > > [0000000000e78000,0000000000e7b41f] overlaps section
> > > > .rodata.compressed LMA [00000000000e0078,00000000015ad43d]
> > > > make[3]: *** [/home/svens/parisc-
> > > > linux/src/arch/parisc/boot/compressed/Makefile:28:
> > > > arch/parisc/boot/compressed/vmlinux] Error 1
> > > > make[2]: *** [/home/svens/parisc-
> > > > linux/src/arch/parisc/boot/Makefile:17:
> > > > arch/parisc/boot/compressed/vmlinux] Error 2
> > > > make[2]: Target 'arch/parisc/boot/bzImage' not remade because
> > > > of
> > > > errors.
> > > > 
> > > > While this might also be fixed by adjusting the linker script,
> > > > i
> > > > think we
> > > > should strip the debug information when generating the
> > > > compressed
> > > > image. This
> > > > reduces the size of vmlinuz/lifimage from ~69MB to 6.6MB when
> > > > full
> > > > debug
> > > > information is enabled.
> > > 
> > > I think keeping debug info is good.
> > > Can you test this patch instead?
> > > It converts a 141MB vmlinux boot file (with debug info) to a 32M
> > > vmlinuz for me.
> > > 
> > > Ideally I would prefer something like
> > >    . = MIN_OR_HIGHER_THAN_CURRENT_ADDR((SZ_end -
> > > SZparisc_kernel_start
> > > + KERNEL_BINARY_TEXT_START));
> > > to avoid the ifdef, but I'm missing the linker script expert
> > > knowledge...
> > > 
> > > Helge
> > > 
> > > ------------------------
> > > [PATCH] parisc: Allow building a compressed vmlinuz with
> > > CONFIG_DEBUG_INFO enabled.
> > > 
> > > Signed-off-by: Helge Deller <deller@gmx.de>
> > > 
> > > diff --git a/arch/parisc/boot/compressed/vmlinux.lds.S
> > > b/arch/parisc/boot/compressed/vmlinux.lds.S
> > > index bfd7872739a3..dac000ec3861 100644
> > > --- a/arch/parisc/boot/compressed/vmlinux.lds.S
> > > +++ b/arch/parisc/boot/compressed/vmlinux.lds.S
> > > @@ -49,7 +49,10 @@ SECTIONS
> > >   	}
> > > 
> > >   	/* bootloader code and data starts behind area of
> > > extracted
> > > kernel */
> > > +#if !defined(CONFIG_DEBUG_INFO)
> > > +	/* ensure at least max address when compiled without
> > > debug
> > > info: */
> > >   	. = (SZ_end - SZparisc_kernel_start +
> > > KERNEL_BINARY_TEXT_START);
> > > +#endif
> > 
> > This would cause the kernel to be built in a single section
> 
> Yes.
> 
> > for the !defined(CONFIG_DEBUG_INFO) case, meaning we'd always blow
> > through the 0x00100000-end text hole we need to leave for the
> > compressed kernel to decompress into.
> 
> The debug info occupied the memory (and more) in the 0x00100000-end
> text area, so we have the room to decompress to.

Only if the end of text in the compressed section occurs before
0x00100000.  That was the bug that caused my decompression to fail. 
Even for a moderately configured kernel, the compressed text size is
often bigger than the 128kb we have available between 0x000e0000 and
0x00100000.

James

> But the second patch I just sent is better anyway.
> 
> Helge
> 


      reply	other threads:[~2019-07-31 19:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-31 17:19 [PATCH] parisc: strip debug information when building compressed images Sven Schnelle
2019-07-31 19:28 ` Helge Deller
2019-07-31 19:36   ` Helge Deller
2019-07-31 19:55     ` Sven Schnelle
2019-07-31 20:07       ` Helge Deller
2019-07-31 20:19         ` Sven Schnelle
2019-07-31 19:37   ` James Bottomley
2019-07-31 19:40     ` Helge Deller
2019-07-31 19:45       ` James Bottomley [this message]

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=1564602349.3319.49.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=deller@gmx.de \
    --cc=linux-parisc@vger.kernel.org \
    --cc=svens@stackframe.org \
    /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 NNTP newsgroup(s).