gas: documents .gnu_attribute Tag_GNU_MIPS_ABI_MSA

Message ID 20230505092716.885338-1-yunqiang.su@cipunited.com
State Accepted
Headers
Series gas: documents .gnu_attribute Tag_GNU_MIPS_ABI_MSA |

Checks

Context Check Description
snail/binutils-gdb-check success Github commit url

Commit Message

YunQiang Su May 5, 2023, 9:27 a.m. UTC
  It is added since 2016 by
  Add support for .MIPS.abiflags and .gnu.attributes sections
  b52717c0e104eb603e8189c3c0d3658ef5d903f5
But never documented.
---
 gas/doc/as.texi | 11 +++++++++++
 1 file changed, 11 insertions(+)
  

Comments

Maciej W. Rozycki May 19, 2023, 11:54 a.m. UTC | #1
On Fri, 5 May 2023, YunQiang Su wrote:

> It is added since 2016 by
>   Add support for .MIPS.abiflags and .gnu.attributes sections
>   b52717c0e104eb603e8189c3c0d3658ef5d903f5
> But never documented.

 Hmm, I can see this has been committed, but who has actually approved 
this change?

  Maciej
  
YunQiang Su May 19, 2023, 12:16 p.m. UTC | #2
Maciej W. Rozycki <macro@orcam.me.uk> 于2023年5月19日周五 19:54写道:
>
> On Fri, 5 May 2023, YunQiang Su wrote:
>
> > It is added since 2016 by
> >   Add support for .MIPS.abiflags and .gnu.attributes sections
> >   b52717c0e104eb603e8189c3c0d3658ef5d903f5
> > But never documented.
>
>  Hmm, I can see this has been committed, but who has actually approved
> this change?
>

Yes. I believe this change is an "obvious" change, as descripted in

Read-write Git access - GNU Project: https://gcc.gnu.org/gitwrite.html

"
Free for all

The following changes can be made by everyone with write access:

Obvious fixes can be committed without prior approval. Just check in
the fix and copy it to gcc-patches. A good test to determine whether a
fix is obvious: will the person who objects to my work the most be
able to find a fault with my fix? If the fix is later found to be
faulty, it can always be rolled back. We don't want to get overly
restrictive about checkin policies.

Similarly, no outside approval is needed to revert a patch that you checked in."
""

>   Maciej
  
Maciej W. Rozycki May 19, 2023, 12:41 p.m. UTC | #3
On Fri, 19 May 2023, YunQiang Su wrote:

> > > It is added since 2016 by
> > >   Add support for .MIPS.abiflags and .gnu.attributes sections
> > >   b52717c0e104eb603e8189c3c0d3658ef5d903f5
> > > But never documented.
> >
> >  Hmm, I can see this has been committed, but who has actually approved
> > this change?
> >
> 
> Yes. I believe this change is an "obvious" change, as descripted in
> 
> Read-write Git access - GNU Project: https://gcc.gnu.org/gitwrite.html

 Under this rule you can push a commit right away as long as you post the 
change committed to our mailing list afterwards, or if you post beforehand 
mentioning that you intend to push unless you hear objections within some 
reasonable time, but you do need to state there that the change has been 
or will be committed under the "obviously correct" rule.

 Also your change is actually not obviously correct, because it has a
defect in formatting: an overlong line that exceeds 79 columns (staying 
within 74 is preferred where feasible).

 Finally for a non-native English speaker it's always good to have 
documentation changes reviewed as this is what our users will read, and 
the last thing we want is documentation that seems unprofessional.  In 
this case you have an inconsistency between the two cases: one uses the 
singular and the other one uses the plural form of the noun, which is bad 
style.  I find the style of the commit description so-so as well.  Being 
internal only it's less of a problem, albeit unfixable once pushed.

  Maciej
  
Maciej W. Rozycki June 15, 2023, 3:50 a.m. UTC | #4
On Fri, 19 May 2023, Maciej W. Rozycki wrote:

>  Also your change is actually not obviously correct, because it has a
> defect in formatting: an overlong line that exceeds 79 columns (staying 
> within 74 is preferred where feasible).
> 
>  Finally for a non-native English speaker it's always good to have 
> documentation changes reviewed as this is what our users will read, and 
> the last thing we want is documentation that seems unprofessional.  In 
> this case you have an inconsistency between the two cases: one uses the 
> singular and the other one uses the plural form of the noun, which is bad 
> style.  I find the style of the commit description so-so as well.  Being 
> internal only it's less of a problem, albeit unfixable once pushed.

 I have now committed a fix addressing the defects with your change.  In a 
detailed review, which should have happened *before* your change went in, 
it has turned out the whole paragraph was inconsistent with one covering 
Tag_GNU_MIPS_ABI_FP immediately above.  I have rewritten it accordingly.

  Maciej
  

Patch

diff --git a/gas/doc/as.texi b/gas/doc/as.texi
index 353ff860f1b..ea40a9ed75e 100644
--- a/gas/doc/as.texi
+++ b/gas/doc/as.texi
@@ -7816,6 +7816,17 @@  registers and 32-bit general-purpose registers.
 registers, 32-bit general-purpose registers and a rule that forbids the
 direct use of odd-numbered single-precision floating-point registers.
 @end itemize
+
+@item Tag_GNU_MIPS_ABI_MSA (8)
+The MIPS SIMD Architecture (MSA) ABI used by this object file.  The value will be:
+
+@itemize @bullet
+@item
+0 for file not tagged or not using any ABIs affected by MSA.
+@item
+1 for files using 128 bit MSA.
+@end itemize
+
 @end table
 
 @subsection PowerPC Attributes