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?
--
M?ns Rullg?rd
[email protected]
On Mon, Jan 05, 2004 at 02:21:37AM +0100, M?ns Rullg?rd wrote:
>
> 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
--
| 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] |
Thorsten Kranzkowski <[email protected]> writes:
> On Mon, Jan 05, 2004 at 02:21:37AM +0100, M?ns Rullg?rd wrote:
>>
>> 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.
> : 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?
--
M?ns Rullg?rd
[email protected]
On Mon, Jan 05, 2004 at 02:21:37AM +0100, M?ns Rullg?rd wrote:
> 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.
--- 2.6/arch/alpha/kernel/module.c Wed May 28 01:05:20 2003
+++ linux/arch/alpha/kernel/module.c Mon Aug 11 23:23:02 2003
@@ -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;
On Tue, Jan 06, 2004 at 12:44:35AM +0000, Thorsten Kranzkowski wrote:
> : 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.
> 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.
--- rc3/lib/inflate.c Thu Jan 8 16:52:19 2004
+++ linux/lib/inflate.c Thu Jan 8 17:55:14 2004
@@ -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 */
On Thu, 08 Jan 2004 16:30:46 +0100, you wrote in linux.kernel:
> 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.
Isn't this code also used for zisofs?
--
Ciao,
Pascal
On Thu, Jan 08, 2004 at 05:18:52PM +0100, Pascal Schmidt wrote:
> Isn't this code also used for zisofs?
No. AFAIKS, zizofs uses zlib stuff.
Ivan.
On Thu, Jan 08, 2004 at 06:15:02PM +0300, Ivan Kokshaysky wrote:
> On Tue, Jan 06, 2004 at 12:44:35AM +0000, Thorsten Kranzkowski wrote:
> > : 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.
> 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.
seems this patch gets rid of the issue - I just successfully booted
rc1 with your patch and sound enabled. It even plays mp3's :)
> Ivan.
Thanks,
Thorsten (advancing to rc3 and examining dmesg closer ....)
--
| 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] |