Relocation overflow with modules on Alpha
Subsystems (2)
I compiled Linux 2.6.0 for Alpha, and it mostly works, except the somewhat large modules. They fail to load with the message "Relocation overflow vs section 17", or some other section number. I've seen this with scsi-mod, nfsd, snd-page-alloc and possibly some more. Compiling them statically works. What's going on?
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 6 lines · Måns Rullgård
I compiled Linux 2.6.0 for Alpha, and it mostly works, except the somewhat large modules. They fail to load with the message "Relocation overflow vs section 17", or some other section number. I've seen this with scsi-mod, nfsd, snd-page-alloc and possibly some more. Compiling them statically works. What's going on?
I saw a similar thing, but I'm compiling everything statically:
: relocation truncated to fit: BRADDR .init.text init/built-in.o(.text+0xf10): In function `inflate_codes':
Disabling a not so important subsystem (sound) helped for the time being.
It seems my kernel crossed the 4 MB barrier in consumed RAM and possibly some relocation type(s) can't cope with that. Time to use -fpic or some such?
Thorsten
Signature · 3 lines
| Thorsten Kranzkowski Internet: [email protected] | | Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [email protected] [44.130.8.19] |
Quoted 9 lines · Thorsten Kranzkowski
Quoted 6 lines · Måns Rullgård
I compiled Linux 2.6.0 for Alpha, and it mostly works, except the somewhat large modules. They fail to load with the message "Relocation overflow vs section 17", or some other section number. I've seen this with scsi-mod, nfsd, snd-page-alloc and possibly some more. Compiling them statically works. What's going on?
I saw a similar thing, but I'm compiling everything statically:
I want the modules.
Quoted 8 lines
: relocation truncated to fit: BRADDR .init.text init/built-in.o(.text+0xf10): In function `inflate_codes':
Disabling a not so important subsystem (sound) helped for the time being.
It seems my kernel crossed the 4 MB barrier in consumed RAM and possibly some relocation type(s) can't cope with that. Time to use -fpic or some such?
I didn't think of that. Where's the proper place to set such things?
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 2 lines · Thorsten Kranzkowski
: relocation truncated to fit: BRADDR .init.text init/built-in.o(.text+0xf10): In function `inflate_codes':
Looks like it's a GCC-3.3 bug.lib/inflate.c is directly included in init/initramfs.c and init/do_mounts_rd.c, so the compiler assumes that all subroutines in these files as "local" and uses branches (bsr instead of jsr) for function calls. Even though some of those functions are in different sections (.text vs .init.text)...
GCC-3.4 seems to be OK.
Quoted 3 lines
It seems my kernel crossed the 4 MB barrier in consumed RAM and possibly some relocation type(s) can't cope with that. Time to use -fpic or some such?
I'm thinking about some __init tricks in lib/inflate.c. What about this patch? It has a nice side effect - the "inflate" code gets freed after init is done.
Ivan.
lib/inflate.c +14 -10
@@ -120,6 +120,10 @@ static char rcsid[] = "#Id: inflate.c,v#define slide window +#ifndef __init +#define __init/* included from bootloader */ +#endif +/* Huffman code lookup table entry--this entry is four bytes for machines that have 16-bit pointers (e.g. PC's in the small or medium model). Valid extra bits are 0..13. e == 15 is EOB (end of block), e == 16
@@ -271,7 +275,7 @@ STATIC const int dbits = 6; /*STATIC unsigned hufts;/* track memory usage */ -STATIC int huft_build( +STATIC int __init huft_build( unsigned *b, /* code lengths in bits (all assumed <= BMAX) */ unsigned n, /* number of codes (assumed <= N_MAX) */ unsigned s, /* number of simple-valued codes (0..s-1) */
@@ -490,7 +494,7 @@ DEBG("huft7 "); -STATIC int huft_free( +STATIC int __init huft_free(struct huft *t/* table to free */ )/* Free the malloc'ed tables built by huft_build(), which makes a linked
@@ -512,7 +516,7 @@ STATIC int huft_free( } -STATIC int inflate_codes( +STATIC int __init inflate_codes( struct huft *tl, /* literal/length decoder tables */ struct huft *td, /* distance decoder tables */ int bl, /* number of bits decoded by tl[] */
@@ -627,7 +631,7 @@ STATIC int inflate_codes( -STATIC int inflate_stored(void) +STATIC int __init inflate_stored(void)/* "decompress" an inflated type 0 (stored) block. */ {unsigned n;/* number of bytes in block */
@@ -686,7 +690,7 @@ DEBG("<stor"); -STATIC int inflate_fixed(void) +STATIC int __init inflate_fixed(void)/* decompress an inflated type 1 (fixed Huffman codes) block. We should either replace this with a custom decoder, or at least precompute the Huffman tables. */
@@ -740,7 +744,7 @@ DEBG("<fix"); -STATIC int inflate_dynamic(void) +STATIC int __init inflate_dynamic(void)/* decompress an inflated type 2 (dynamic Huffman codes) block. */ {int i;/* temporary variables */
@@ -921,7 +925,7 @@ DEBG("dyn7 "); -STATIC int inflate_block( +STATIC int __init inflate_block(int *e/* last block flag */ )/* decompress an inflated block */
@@ -972,7 +976,7 @@ STATIC int inflate_block( -STATIC int inflate(void) +STATIC int __init inflate(void)/* decompress an inflated entry */ {int e;/* last block flag */
@@ -1034,7 +1038,7 @@ static ulg crc; /* initialized in makec* gzip-1.0.3/makecrc.c. */ -static void +static void __init makecrc (void ) {/* Not copyrighted 1990 Mark Adler */
@@ -1082,7 +1086,7 @@ makecrc(void)/* * Do the uncompression! */ -static int gunzip (void ) +static int __init gunzip (void ) {uch flags;unsigned char magic[2 ];/* magic header */
Quoted 5 lines · Ivan Kokshaysky
Quoted 2 lines · Thorsten Kranzkowski
: relocation truncated to fit: BRADDR .init.text init/built-in.o(.text+0xf10): In function `inflate_codes':
Looks like it's a GCC-3.3 bug.
will try 3.3.2 soon.
Quoted 3 lines
I'm thinking about some
__inittricks inlib/inflate.c. What about this patch? It has a nice side effect - the "inflate" code gets freed after init is done.
seems this patch gets rid of the issue - I just successfully booted rc1 with your patch and sound enabled. It even plays mp3's :)
Quoted 1 line
Ivan.
Thanks,
Thorsten (advancing to rc3 and examining dmesg closer ....)
Signature · 3 lines
| Thorsten Kranzkowski Internet: [email protected] | | Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [email protected] [44.130.8.19] |
PATCH 1/1 Relocation overflow with modules on Alpha
In reply to Måns RullgårdQuoted 3 lines · Måns Rullgård
I compiled Linux 2.6.0 for Alpha, and it mostly works, except the somewhat large modules. They fail to load with the message "Relocation overflow vs section 17", or some other section number.
This failure happens with GPRELHIGH relocation, which is *signed* short, but relocation overflow check in module.c doesn't take into account the sign extension.
Appended patch should help.
Ivan.
arch/alpha/kernel/module.c +1 -1
@@ -259,7 +259,7 @@ apply_relocate_add(Elf64_Shdr *sechdrs, *(u64 *)location = value;break ;case R_ALPHA_GPRELHIGH : - value = (value - gp +0x8000 ) >>16 ; + value = (long )(value - gp +0x8000 ) >>16 ;if ((short ) value != value) goto reloc_overflow; *(u16 *)location = value;