Re: Clang/LLVM version requirements

[Keir Fraser <keir.xen@gmail.com>]

On 13/09/2012 16:05, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 13/09/2012 15:55, "Tim Deegan" <tim@xen.org> wrote:
> 
>> At 15:01 +0100 on 13 Sep (1347548504), Jan Beulich wrote:
>>>>>> On 13.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
>>>> 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.
>> 
>> OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
>> I tries gcc 3.4 but the build already fails in a few other places.
>> Do we really still support gcc 3.4 like the README says?
> 
> It's been a long while since we updated our compiler support. In general
> I've been happy to say we support each gcc release only for 2-3 years. In
> this case that would mean we could *even* update our support to be only gcc
> 4.2 and later.
> 
> What do people think about us forcing this? It might even let us get rid of
> GCC_HAS_VISIBILITY_ATTRIBUTE?

I should add, this is mainly a question of how aggressive we should be. I'm
quite happy to retire gcc-3.4 support if it happens it is now broken. In
that case, x86/Rules.mk should have its gcc version check updated. And
perhaps arch/arm may as well do the same? I would be happy to Ack a patch to
that effect.

 -- Keir

>  -- Keir
> 
>> Can I have an Ack, or would you like to apply it yourself?
>> 
>> Tim.
>> 
>> # HG changeset patch
>> # Parent 9e46d90d0182979a7220314ca19d2525e338aa5d
>> x86: check for data and BSS in reloc code at compile time.
>> 
>> This is a more useful failure mode than hanging at boot time, and
>> incidentally fixes the clang/LLVM build by removing a .subsection rune.
>> 
>> Signed-off-by: Tim Deegan <tim@xen.org>
>> 
>> diff -r 9e46d90d0182 xen/arch/x86/boot/build32.mk
>> --- a/xen/arch/x86/boot/build32.mk Thu Sep 13 15:00:26 2012 +0100
>> +++ b/xen/arch/x86/boot/build32.mk Thu Sep 13 15:04:32 2012 +0100
>> @@ -20,6 +20,15 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
>>  
>>  %.o: %.c
>> $(CC) $(CFLAGS) -c -fpic $< -o $@
>> + $(OBJDUMP) -h $@ | 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
>>  
>>  reloc.o: $(BASEDIR)/include/asm-x86/config.h
>>  .PRECIOUS: %.bin %.lnk
>> diff -r 9e46d90d0182 xen/arch/x86/boot/reloc.c
>> --- a/xen/arch/x86/boot/reloc.c Thu Sep 13 15:00:26 2012 +0100
>> +++ b/xen/arch/x86/boot/reloc.c Thu Sep 13 15:04:32 2012 +0100
>> @@ -18,10 +18,7 @@ asm (
>>      "    call 1f                       \n"
>>      "1:  pop  %ebx                     \n"
>>      "    mov  %eax,alloc-1b(%ebx)      \n"
>> -    "    mov  $_end,%ecx               \n"  /* check that BSS is empty! */
>> -    "    sub  $__bss_start,%ecx        \n"
>> -    "    jz reloc                      \n"
>> -    "1:  jmp 1b                        \n"
>> +    "    jmp  reloc                    \n"
>>      );
>>  
>>  /* This is our data.  Because the code must be relocatable, no BSS is
>> @@ -30,9 +27,6 @@ asm (
>>  asm (
>>      "alloc:                            \n"
>>      "    .long 0                       \n"
>> -    "    .subsection 1                 \n"
>> -    "    .p2align 4, 0xcc              \n"
>> -    "    .subsection 0                 \n"
>>      );
>>  
>>  typedef unsigned int u32;
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
> 
>