This is the mail archive of the 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 1/2] Add support for O32 FPXX ABI

> So I'm planning to commit a patch to update the code that checks and
> prints the tags.  Hopefully it should be easy to rebase yours on top.

Fine with me. That code is/was insane. I was merely going along with it.
> Matthew Fortune <> writes:
> > +      /* If floating-point code has been seen and the module is
> single-float
> > +	 then give this precedence over the double-precision cases below.
> > +	 Single-float can theoretically be used with any width register.
> */
> > +      else if (mips_seen_fp_code == TRUE
> > +	       && file_mips_opts.single_float == 1)
> > +	fpabi = Val_GNU_MIPS_ABI_FP_SINGLE;
> >
> > This is not OK. As we don't know if the user wrote .module singlefloat
> or used
> > -msingle-float. If it was .module then this shows intent that the code
> in this
> > module is designed for single-float so that would be OK.
> But .module should act like the corresponding command-line option,
> and vice versa.  I don't think any extra trust should be given to
> one over the other.
> I think we need to keep the interface as simple as possible.

I agree, but we also need safety.

> > I propose a further option to fix this. -minfer-abi and .module infer-
> fpabi.
> No!!! :-)  Even more options would just make things unnecessarily
> complicated.
> Anything passing the command-line options or generating the .module
> should
> say what the ABI is instead.

Are you saying you think the user should have to write .gnu_attribute 4,5 or .gnu_attribute 4,6 to get any FP ABI attribute other than 'any'? Your comment below suggests not...

> The general principle is that an asm file can include code that requires
> features outside the module-level setting.  We should never infer
> anything about the global FPU ABI from something like an ADD.D that
> we happen to see.  It might be that the ADD.D is part of an ifunc
> (or similar mechanism) that only runs when an FPU is available.
> IMO we should just leave the FPU ABI as "any" unless a command-line
> option,
> .module or .gnu_attribute says what the ABI actually is.

My problem is with the command line options, not .module. The writer of the code has control over .module but not over the command line options. I.e. consider a toolchain prepared with --with-fp=xx and a toolchain prepared with --with-fp=32/default. Depending on the toolchain used then any hand-crafted assembly code may be tagged with an incompatible FP ABI. While we could validly assume that options like -mfpxx won't be used explicitly by people building code that they did not write... implied options from the toolchain mean that the compiler driver may use them. For FPXX to work we have to enable linux distributions to include a compiler that is FPXX by default to facilitate the transition but do so safely. Any thoughts on how to make this safe?

The code I referred to as being broken when testing GCC was mips16.S from libgcc. It is a niche case given its purpose but demonstrates the problems of pre-existing FP code.


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