[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Clang/LLVM version requirements



>>> On 13.09.12 at 14:40, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
> Il 13/09/2012 13:52, Jan Beulich ha scritto:
>> 
>> So the patch is fine by me if it covers that misalignment case.
>> But it seems a little heavy handed - I'd think that instead of the
>> sub-section, we could just create an arbitrary other section, or
>> even allow uninitialized variable (it's unclear to me why Paolo
>> wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
>> the way it is now) - after all we only need to make sure that
>> - the space gets properly allocated in trampoline.S, i.e. also in
>>   reloc.bin
>> - all accesses are PC-relative
>> Neither has anything to do with use of uninitialized variables.
> 
> We cannot use BSS because it doesn't appear in reloc.S.

That, imo, would be a binutils bug.

Jan

> Apart from BSS, there would be no benefit for reloc to move itself to
> BOOT_TRAMPOLINE, because BOOT_TRAMPOLINE is not a known location
> anymore.  So it was easier to just run it in place from where we put it,
> in the middle of head.S, but this means BSS disappears after extracting
> reloc.bin.
> 
> So it's not really because the code must be relocatable, but more
> because of the way we extract the binary data and put it in the middle
> of head.S.
> 
> Initialized data works as long as you pass -fno-zero-initialized-in-bss
> to the compiler or it is eaten.  I used assembly to declare the alloc
> variable, because I wasn't sure of which GCC versions need the option,
> and whether older versions are supported for compiling Xen.
> 
> Paolo




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.