lkml.org 
[lkml]   [2008]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [BUILD-FAILURE] linux-next: Tree for June 30
H. Peter Anvin wrote:
> Sam Ravnborg wrote:
>>> ah, ok. So the patch below should solve this for now?
>>>
>>> is there any particular reason why we are limited to 100 sections?
>>> (is there some ELF limitation here perhaps?)
>>
>> I would still like to know if you see significant different numbers
>> than Kamalesh.
>> If you see a number close to 100 then OK.
>> But if you see a number say in the range of below 80 then we should
>> dive deeper into this.
>>
>> I do not even know what the program does - never looked at it befoe
>> so why the original limit was 100 I dunno.
>>
>
> It looks to me that the people who did the relocatable kernel code just
> put in a magic number. There is certainly no inherent reason for this
> limit.
>
> What's really ugly is that this is in a host-space program! It would
> have been one thing if it had been in a piece of code run in a
> restricted environment, e.g. in the decompressor, but this one runs in
> user space on the build environment.
>
> The quick solution is to change this number to something obscenely big
> (say 10000, but even that could be an issue if we end up doing stuff
> like section per function); the proper solution is to turn these arrays
> into a structure and allocate the array dynamically.

Here is a quick patch to just change the number; I'll take a quick pass
to see how much work it'd be to allocate it dynamically.

-hpa
diff --git a/arch/x86/boot/compressed/relocs.c b/arch/x86/boot/compressed/relocs.c
index edaadea..9daca63 100644
--- a/arch/x86/boot/compressed/relocs.c
+++ b/arch/x86/boot/compressed/relocs.c
@@ -10,7 +10,7 @@
#define USE_BSD
#include <endian.h>

-#define MAX_SHDRS 100
+#define MAX_SHDRS 10000
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
static Elf32_Ehdr ehdr;
static Elf32_Shdr shdr[MAX_SHDRS];
\
 
 \ /
  Last update: 2008-06-30 22:45    [W:0.069 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site