[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Early x86 boot code build system questions
>>> On 23.11.15 at 21:06, <daniel.kiper@xxxxxxxxxx> wrote: > Some people reported that after applying v2 of my patches they cannot build > xen.gz due to following error: > > objdump -h reloc.o | sed -n '/[0-9]/{s,00*,0,g;p;}' |\ > while read idx name sz rest; do \ > case "$name" in \ > .data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \ > test $sz != 0 || continue; \ > echo "Error: non-empty $name: 0x$sz" >&2; \ > exit $(expr $idx + 1);; \ > esac; \ > done > Error: non-empty .rodata: 0x01c > build32.mk:22: recipe for target 'reloc.o' failed > > Surprisingly second run usually builds xen.gz without any issue. The problem > is > in xen/arch/x86/boot/build32.mk %.o: %.c recipe and I will post relevant fix > for this in v3. If there is a build problem, may I ask for the fix being submitted right away, rather than being deferred until whenever you'll have v3 ready. Or alternatively the problem being explained so someone else could have a go? > So, I asked myself why we do not allow .rodata sections (and others) in > intermediate > *.o files? I did some tests with relevant checks disabled and xen.gz works > without > any issue. Of course final image is larger due to some alignments but I do > not believe > that this is real explanation for this restriction. So, I would like to ask > why these > constraints were put here and in other places? Could we safely remove them? > If yes then how? The question you should ask yourself is: What does the combination of the %.o -> %.lnk and %.lnk -> %.bin rules do to an object with multiple sections? Is it _well defined_ how relocations get handled in that case? If so, quoting the respective documentation in the commit message I think a patch to lift the restrictions could be acceptable (assuming of course such well-defined-ness didn't only get introduced by a binutils version newer than the oldest one we support). > Potentially we can go Linux way and avoid all above mentioned issues. > However, this requires huge changes in our build system. I'm not convinced huge changes to the build system would be needed for this, but ... > So, I think that right now we > can use workaround with -fno-tree-switch-conversion GCC option. ... this certainly sounds acceptable (again provided this works on all supported gcc versions). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |