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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.09.12 at 14:21, Tim Deegan <tim@xxxxxxx> wrote:
> At 12:52 +0100 on 13 Sep (1347540769), Jan Beulich wrote:
>> >>> On 13.09.12 at 12:11, Tim Deegan <tim@xxxxxxx> wrote:
>> > At 11:04 +0100 on 07 Sep (1347015863), Jan Beulich wrote:
>> >> >>> On 07.09.12 at 10:50, Tim Deegan <tim@xxxxxxx> wrote:
>> >> > In any case we probably ought to check for stray .data symbols too.
>> >> 
>> >> Not really, no. Those would still be present in reloc.bin, and
>> >> hence make it into reloc.S.
>> > 
>> > But they would break the test, because the magic alignment happens in
>> > .text, right?  Anyway, compile-time failure seems more useful.  How
>> > about this, based on the similar checks for init-only files?
>> 
>> Yes, it's happening in .text currently. The problem, iirc, really was
>> that _end and __bss_start didn't always match (depending on
>> compiler version), apparently because at the linking stage _end
>> got aligned more strictly than __bss_start.
>> 
>> 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.
> 
> Allowing BSS would just need a few extra runes (AFAICS,
> "--set-section-flags .bss=alloc,load,contents") in the objcopy that
> makes reloc.bin.
>  But I'm not sure how to make sure everything is
> rip-relative, do if that's the real concern I'm inclined to go with
> this compile-time check and exclude .[ro]data[.*] as well.
> We can always fix it up to allow bss and data sections if we ever
> actually need them.

As said, I'm fine with any approach as long as it works with all
supported tool chains. So feel free to go the route you're
proposing.

Jan


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