Re: [BUILD-FAILURE] linux-next: Tree for June 30

[H. Peter Anvin]

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/