On 31.07.19 21:37, James Bottomley wrote:
On Wed, 2019-07-31 at 21:28 +0200, Helge Deller wrote:
* Sven Schnelle <svens@xxxxxxxxxxxxxx>:
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@xxxxxx>
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.
But the second patch I just sent is better anyway.
Helge
