Add support for a .base64 pseudo-op to gas

[Alan Modra]

On Thu, Jul 11, 2024 at 01:03:46PM +0100, Nick Clifton wrote:
> I have checked in a small patch to fix this problem - by generating padding
> octets at the end of the string.  But there is an issue - when should these
> padding octets be generated ?  I have chosen to put them at the end of the
> octets generated by all of the string(s) for one .base64 directive.  This
> ensures that if a single directive has multiple strings, there will be no
> padding between the strings, which is probably what the user is expecting,
> but it does also mean that a single .byte64 directive with multiple arguments
> can produce different results to multiple .base64 directives.

Sounds reasonable to me.  I think if I were implementing this I
probably would have only allowed a single string.  Because I'm lazy.

A further testsuite tweak:

Three extra octets are now expected with the latest change to base64.s.
They happened to be covered by patterns allowing for zero padding at
the end of the section, but we shouldn't allow fewer octets than
expected.

	PR 31964
	* testsuite/gas/all/base64.d: Adjust.

diff --git a/gas/testsuite/gas/all/base64.d b/gas/testsuite/gas/all/base64.d
index a35382d16a5..5a366de1654 100644
--- a/gas/testsuite/gas/all/base64.d
+++ b/gas/testsuite/gas/all/base64.d
@@ -13,4 +13,4 @@ Contents of section \.data:
 .* 00000040 00000000 00000040 00400000 .*
 .* 00000040 00400000 00000010 03000000 .*
 .* 00000010 03000000 00000008 00000000 .*
-.* 00000000 00000000 00(      |00    |000000) (        |00000000) .*
+.* 00000000 00000000 00000000 (        |00000000) .*


-- 
Alan Modra