Re: [Xen-devel] Early x86 boot code build system questions

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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