This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: check mips abi x linker emulation compatibility


Alexandre Oliva <aoliva@redhat.com> writes:
> @@ -116,31 +127,31 @@ proc regsize_conflict {arglist} {
>  abi_conflict { "-mabi=eabi -mgp32" "-mips4 -mabi=32" } EABI32 O32
>  abi_conflict { "-mips4 -mabi=o64" "-mips3 -mabi=eabi" } O64 EABI64
>  
> -isa_conflict { "-march=vr5500" "-march=sb1" } 5500 sb1
> -isa_conflict { "-march=vr5400" "-march=4120" } 5400 4120
> -isa_conflict { "-march=r3900" "-march=r6000" } 3900 6000
> -isa_conflict { "-march=r4010" "-march=r4650" } 4010 4650
> -isa_conflict { "-mips3 -mgp32" "-mips32" } 4000 isa32
> -isa_conflict { "-march=sb1 -mgp32" "-mips32r2" } sb1 isa32r2
> +isa_conflict { "-march=vr5500 -32" "-march=sb1 -32" } 5500 sb1
> +isa_conflict { "-march=vr5400 -32" "-march=4120 -32" } 5400 4120
> +isa_conflict { "-march=r3900 -32" "-march=r6000 -32" } 3900 6000
> +isa_conflict { "-march=r4010 -32" "-march=r4650 -32" } 4010 4650
> +isa_conflict { "-mips3 -mgp32 -32" "-mips32 -32" } 4000 isa32
> +isa_conflict { "-march=sb1 -mgp32 -32" "-mips32r2 -32" } sb1 isa32r2
>  
> -regsize_conflict { "-mips4 -mgp64" "-mips2" }
> +regsize_conflict { "-mips4 -mgp64 -mabi=o64" "-mips2 -32" }
>  regsize_conflict { "-mips4 -mabi=o64" "-mips4 -mabi=32" }
>  regsize_conflict { "-mips4 -mabi=eabi -mgp32" "-mips4 -mabi=eabi -mgp64" }
> -regsize_conflict { "-march=vr5000 -mgp64" "-march=vr5000 -mgp32" }
> -regsize_conflict { "-mips32" "-mips64" }
> -regsize_conflict { "-mips32r2" "-mips64" }
> -
> -good_combination { "-mips4 -mgp32" "-mips2" } { mips4 32bitmode }
> -good_combination { "-mips4 -mabi=32" "-mips2" } { mips4 o32 }
> -good_combination { "-mips2" "-mips4 -mabi=32" } { mips4 o32 }
> -good_combination { "-mips2" "-mips4 -mabi=eabi -mgp32" } { mips4 eabi32 }
> -good_combination { "-mips2" "-mips32" "-mips32r2" } { mips32r2 }
> -good_combination { "-mips1" "-mips32r2" "-mips32" } { mips32r2 }
> -
> -good_combination { "-march=vr4100" "-march=vr4120" } { 4120 }
> -good_combination { "-march=vr5400" "-march=vr5500" "-mips4" } { 5500 }
> -good_combination { "-mips3" "-mips4" "-march=sb1" "-mips5" } { sb1 }
> -good_combination { "-mips1" "-march=3900" } { 3900 }
> +regsize_conflict { "-march=vr5000 -mgp64 -mabi=o64" "-march=vr5000 -mgp32 -32" }
> +regsize_conflict { "-mips32 -32" "-mips64 -mabi=o64" }
> +regsize_conflict { "-mips32r2 -32" "-mips64 -mabi=o64" }
> +
> +good_combination { "-mips4 -mgp32 -32" "-mips2 -32" } { mips4 o32 }
> +good_combination { "-mips4 -mabi=32" "-mips2 -32" } { mips4 o32 }
> +good_combination { "-mips2 -32" "-mips4 -mabi=32" } { mips4 o32 }
> +good_combination { "-mips2 -mabi=eabi" "-mips4 -mabi=eabi -mgp32" } { mips4 eabi32 }
> +good_combination { "-mips2 -32" "-mips32 -32" "-mips32r2 -32" } { mips32r2 }
> +good_combination { "-mips1 -32" "-mips32r2 -32" "-mips32 -32" } { mips32r2 }
> +
> +good_combination { "-march=vr4100 -32" "-march=vr4120 -32" } { 4120 }
> +good_combination { "-march=vr5400 -32" "-march=vr5500 -32" "-mips4 -32" } { 5500 }
> +good_combination { "-mips3 -32" "-mips4 -32" "-march=sb1 -32" "-mips5 -32" } { sb1 }
> +good_combination { "-mips1 -32" "-march=3900 -32" } { 3900 }
>  
>  good_combination { "-march=vr4120 -mabi=32" "-mips3 -mabi=32" } { 4120 o32 }
> -good_combination { "-march=sb1 -mgp32" "-march=4000 -mgp32" } { sb1 32bitmode }
> +good_combination { "-march=sb1 -mgp32 -32" "-march=4000 -mgp32 -32" } { sb1 o32 }

I object to this.  One of the main motivations for the test was to
make sure that NO_ABI behaves correctly.  Adding ABI options to every
line means we no longer do that.

I thought from your message that you were going to just disable the
combinations that don't work for mips64-linux-gnu.  That seems like
a better approach to me.  I guess the "+" lines would still be useful
as a bit of extra testing.  But pleast don't remove the lines that
are already there.

How about mirroring the ABI selection logic that you added to
the configure scripts?  Then use that to decide which combinations
should be tested.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]