lkml.org 
[lkml]   [2008]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BUILD-FAILURE] linux-next: Tree for June 30
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.

-hpa




\
 
 \ /
  Last update: 2008-06-30 22:43    [W:0.161 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site