Re: [PATCH v4 02/15] ARC: ABI Implementation

[Vineet Gupta <vineetg76@gmail.com>]

On 3/25/20 6:52 PM, Joseph Myers wrote:
> On Thu, 12 Mar 2020, Vineet Gupta via Libc-alpha wrote:
>> +/* ARC has selectable endianness.  */
>> +#ifdef __BIG_ENDIAN__
>> +# define __BYTE_ORDER __BIG_ENDIAN
>> +#else
>> +# define __BYTE_ORDER __LITTLE_ENDIAN
>> +#endif
> 
> Elsewhere you say the port is little-endian only.  In such cases we 
> generally have an error somewhere if you attempt to build glibc for the 
> other endianness, to avoid an other-endian configuration accidentally 
> building but not working and having a broken ABI.  For example, see what 
> Nios II does: sysdeps/nios2/bits/endianness.h handles both endiannesses, 
> but sysdeps/nios2/configure.ac produces an error for big-endian.

Hardware-wise, ARC can be configured to be LE or BE and software supports that
(cfr Linux or uClibc). The initial glibc port was only aiming LE but we ended up
with BE as well due to a customer engagement. And given much of ARC port is
currently generic (minimal asm), no real change was needed except enabling it in
this header. We do plan to officially support it so I guess we need some more
changes in Documentation / ABI listing etc.

> 
>> +/* PLT jump into resolver passes PC of PLTn, while _dl_fixup expects the
>> +   address of corresponding .rela.plt entry.  */
>> +
>> +#ifdef __A7__
>> +# define ARC_PLT_SIZE	12
>> +#else
>> +# define ARC_PLT_SIZE	16
>> +#endif
> 
> Is this some sort of ABI difference between two incompatible ABIs?  (The 
> ABI document you pointed to only seems to mention 12-byte PLT entries.)

Right, we've had 2 ARC ISA: current generation ARCv2 (basis for HS3x and HS4x
processors) and the older ARCompact (ARC700 cores which run Linux and still
supported e.g. in Mellanox NPS cores). From instruction set pov they are very
similar (although not binary compatible).

ARCompact PLT entry is 12 bytes
    b18c:	ld    r12,[pcl,0x00065584]	#8
    b194:	j_s.d [r12]			#2
    b196:	mov_s r12,pcl			#2

ARCv2 prohibits--> mov_s with PCL and thus we have
    b18c:	ld    r12,[pcl,0x00065584]	#8
    b194:	j.d   [r12]			#4
    b198:	mov   r12,pcl			#4

Again this is the only change needed for *testing* a ARCompact build as rest is
all taken care by how gcc is configured etc (and generates __A7__). This has also
been tested and boots Linux fine. We can add the necessary elaborations for
supporting it officially.

>> +#define reloc_index						\
>> +({								\
>> +  unsigned long int plt0 = D_PTR (l, l_info[DT_PLTGOT]);	\
>> +  unsigned long int pltn = reloc_arg;				\
>> +  /* Exclude PL0 and PLT1.  */					\
> 
> Should PL0 be PLT0 here?

Fixed.

>> +  unsigned long int idx = (pltn - plt0)/ARC_PLT_SIZE - 2;	\
> 
> Missing spaces around '/'.

Fixed.

> 
>> diff --git a/sysdeps/arc/gmp-mparam.h b/sysdeps/arc/gmp-mparam.h
>> new file mode 100644

[snip...]

>> +
>> +#define IEEE_DOUBLE_BIG_ENDIAN 0
> 
> Plenty of architectures that have, or support, little-endian floating 
> point do not have gmp-mparam.h at all.  IEEE_DOUBLE_BIG_ENDIAN is only 
> used to define union ieee_double_extract, which is nowhere used in glibc.  
> So I don't think you need this header at all 

Removed now.

(and it shows up the scope
> for a more general cleanup possible for other ports, I suspect only the 
> x32 and mips64 versions of this header, the ones that define 
> _LONG_LONG_LIMB for ILP32 configurations with 64-bit registers, are the 
> only non-generic ones that do anything useful - but you don't need to do 
> that cleanup).

Thx for taking a look.

-Vineet



_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc