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

[Tim Deegan <tim@xxxxxxx>]

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.

Tim.

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