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: PATCH: Fix mixing MIPS object files.


On Wed, Nov 06, 2002 at 07:58:52PM +0000, Richard Sandiford wrote:

> Or, starting from the beginning...
> 
> There seems to be two ways of interpreting the EF_MIPS_MACH
> and EF_MIPS_ARCH bits:
> 
> 1. They are almost orthogonal.  If EF_MIPS_ARCH = X and
>    EF_MIPS_MACH = Y, then the binary uses two sets of
>    instructions:
> 
>    - those which are defined by ISA X
>    - those which are defined by the ISA for processor Y,
>      but not by the "standard" ISA on which it based.
> 
>    In other words, EF_MIPS_MACH acts as a sort of ASE enumeration.
> 
> 2. If EF_MIPS_MACH is a non-zero X, the code is written for
>    processor X, and can use any instruction that X understands,
>    subject to the other header flags (32-bit binaries can only
>    use 32-bit instructions, etc.).  EF_MIPS_ARCH (redundantly)
>    specifies the core ISA on which X is based.
> 
>    Otherwise, the code only uses instructions from the generic ISA
>    defined by EF_MIPS_ARCH.
> 
> Reasons why I prefer (2) over (1):
> 
> - If we accept (1), we presumably have to accept the idea of
>   MIPS I SB-1 code, MIPS II SB-1 code, MIPS III SB-1 code,
>   etc.  I guess a MIPS III SB-1 binary could use the SB-1
>   multimedia extensions, but not conditional moves.
>   It could get really complicated ;)

That is the whole idea of one of my patches. People are using that. I
don't see it is complicated. MIPS I SB-1 means MIPS I + SB-1 isns
which are not in MIPS II and above.

> 
> - It copes neatly with the situations where a processor doesn't
>   have certain instructions.  E.g. when a processor is based
>   on MIPS II or higher, but doesn't have LL or SC.  Or when
>   a processor only has a single-precision FPU.

I don't understand. You can always tell that by EF_MIPS_MACH.

> 
> - The main reason for varying EF_MIPS_ARCH for a given EF_MIPS_MACH
>   seems to be to say that a binary contains 32-bit code.  There are
>   other flags for that.

Linux 32bit MIPS kernel won't load any MIPS binaries marked MIPS III
or above.


H.J.


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