On Tue, Jun 24, 2014 at 11:26 AM, H. Peter Anvin <h...@zytor.com> wrote: > On 06/24/2014 11:19 AM, Andy Lutomirski wrote: >>>> >>>> One of the recent x86/urgent vdso commits causes this build failure: >>>> >>>> Error: too many copied sections (max = 13) >>> >>> I can't reproduce this with your config, which suggestes a binutils >>> issue, which is annoying. Can you tell me what version of ld you're >>> using and send me the output of: >>> >>> for i in arch/x86/vdso/*.so.dbg; do echo $i; eu-readelf -S $i; done >> >> Ping! >> >> The current state of this is obviously not so good, but I don't know >> how to proceed. >> > > We used to have this kind of problems with PHDRs, where ld would guess > how much space it would need, somehow guess wrong, and fall on its face. > > I think we want to actually print the number that we are trying to copy > in addition to the maximum, and I also noticed the test looks wrong. > Thus I would like to propose the following patch as a diagnostic: > > diff --git a/arch/x86/vdso/vdso2c.h b/arch/x86/vdso/vdso2c.h > index f42e2ddc663d..94158e100f26 100644 > --- a/arch/x86/vdso/vdso2c.h > +++ b/arch/x86/vdso/vdso2c.h > @@ -99,8 +99,9 @@ static void BITSFUNC(copy_section)(struct > BITSFUNC(fake_sections) *out, > if (!copy) > return; > > - if (out->count >= out->max_count) > - fail("too many copied sections (max = %d)\n", > out->max_count); > + if (out->count > out->max_count) > + fail("too many copied sections (max = %d, need = %d)\n", > + out->max_count, out->count); >
I think the old test was correct: we haven't incremented count yet (it's a couple lines below), so count is the zero-based index to which we're writing. I thought of doing the need = %d thing, but I think that the output is a foregone conclusion: count == max_count + 1 when this fails. A list of all the section names would be more interesting, but eu-readelf -S will tell is that. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/