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: Contribution: Intel's iWMMXt processor


> Hi Richard,
> 
> > Actually, it's a combination of all the areas related to this.
> > 
> > 1) The assembler sets the architecture to v5e if the user hasn't specified 
> > any particular architecture.   It should probably be set to unknown.
> >
> > 2) The bit of code above should be able to combine files with different 
> > architecture specifications with the result being the most specific 
> > architecture requested (provided they are compatible); except that 
> > unknown+anything is always unknown, unless some command-line option forces 
> > it otherwise.
> >
> > 3) I also don't like the fact that it is directly exporting the internal 
> > bfd numbers, which haven't been logically selected.  If we must do 
> > something like this, it should be based on names and the tools should map 
> > the names onto internal numbers as files are read and written.
> >
> > Finally, the use of .note.arm.ident for a GNU extension is a really BAD 
> > idea.  This should have "gnu" somewhere in the note name.
> 
> I agree with these points - but we do now need a effective way of
> identifying and labelling different types of ARM binaries.  The current
> method - bits in the flags field of the header is no longer sufficient
> and using a .note section seems the best way forward.
> 
> How about this compromise patch then ?  It:
> 
>   * Changes the name of the section to .note.gnu.arm.ident.
> 
>   * Changes the value stored in the section to be a string saying:
> 
>      "arch: <unknown|armv2|armv3|...etc"
> 
>   * Removes the bogus test for incompatible architectures and replaces
>     it with one that can handle the new notes.

Well, that's certainly a step in the right direction, and may well be 
enough for now.  But why is this suddenly so necessary?

Note, I'm trying to develop a sensible and more comprehensive equivalent 
to the above for the EABI, but doing this properly requires several 
attributes and some lattice theory.  Is there any chance this can wait 
until we have that specification sorted out?



>       arm_arch->output_section = arm_arch;
>       subseg_set (arm_arch, 0);
>   
> !     switch (mach)
> !       {
> !       default:
> !       case bfd_mach_arm_unknown: arch_string = "unknown"; break;
> !       case bfd_mach_arm_2:       arch_string = "armv2"; break;
> !       case bfd_mach_arm_2a:      arch_string = "armv2a"; break;
> !       case bfd_mach_arm_3:       arch_string = "armv3"; break;
> !       case bfd_mach_arm_3M:      arch_string = "armv3M"; break;
> !       case bfd_mach_arm_4:       arch_string = "armv4"; break;
> !       case bfd_mach_arm_4T:      arch_string = "armv4t"; break;
> !       case bfd_mach_arm_5:       arch_string = "armv5"; break;
> !       case bfd_mach_arm_5T:      arch_string = "armv5t"; break;
> !       case bfd_mach_arm_5TE:     arch_string = "armv5te"; break;
> !       case bfd_mach_arm_XScale:  arch_string = "XScale"; break;
> !       case bfd_mach_arm_ep9312:  arch_string = "ep9312"; break;
> !       case bfd_mach_arm_iWMMXt:  arch_string = "iWMMXt"; break;	
> !       }
> ! 
> !     arm_add_note (NOTE_ARCH_STRING, arch_string, NT_ARCH);
>   

This list is incomplete.  See config/tc-arm.c for a more comprehensive one.

> --- 11834,11841 ----
>     {"arm1020t",		ARM_ARCH_V5T,	 FPU_ARCH_VFP_V1},
>     {"arm1020e",		ARM_ARCH_V5TE,	 FPU_ARCH_VFP_V2},
>     /* ??? XSCALE is really an architecture.  */
> !   {"xscale",		ARM_ARCH_XSCALE, FPU_NONE},
> !   {"iwmmxt",		ARM_ARCH_IWMMXT, FPU_NONE},
>     {"i80200",		ARM_ARCH_XSCALE, FPU_ARCH_VFP_V2},
>     /* Maverick */
>     {"ep9312",		ARM_ARCH_V4T | ARM_CEXT_MAVERICK, FPU_NONE},

I think this is wrong. FPU_ARCH_VFP isn't VFP instructions it's the VFP 
word ordering of doubles.  It doesn't make sense for the XScale chips to 
be using the FPA format of doubles.  Instead, I think gcc should be fixed 
to use softvfp as its float format for xscale and the assembler left as it 
was (see the arm-NetBSD configuration).

R.



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