On Tue, May 05, 2020 at 03:58:59PM +0100, Will Deacon wrote:
> On Wed, Apr 29, 2020 at 10:16:38PM +0100, Mark Brown wrote:

> > +#define GNU_PROPERTY_AARCH64_FEATURE_1_BTI      (1U << 0)
> > +#define GNU_PROPERTY_AARCH64_FEATURE_1_PAC      (1U << 1)

> > +.macro emit_aarch64_feature_1_and

> Might be useful to take the features as a macro argument, so we can
> re-use this when extra features get added in the future.

I was unsure about that - it'd be a bit annoying to have to have all the
callers of the macro list things like BTI where 

> > +3:      .long   GNU_PROPERTY_AARCH64_FEATURE_1_AND
> > +	.long   5f - 4f
> > +4:
> > +	.long   GNU_PROPERTY_AARCH64_FEATURE_1_PAC | \
> > +		GNU_PROPERTY_AARCH64_FEATURE_1_BTI

> Hmm. The Linux ABI doc [1] says this field is:

> 	unsigned char pr_data[PR_DATASZ];

> but the AArch64 PCS [2] says:

> 	"It has a single 32-bit value for the pr_data field."

> What does this mean for endianness?

It's not entirely clear is it?  What we're doing here means that we're
emitting as a long rather than a character array so the endianness
matters.  The ABI doc does have language about the elements being "an
array of X-byte integers in the format of the target processor" which
seems to align with that as well, my impression is that the intention of
the ABI doc is that there should be a Processor_Word type corresponding
to the Elf_Word type but there isn't so the char arrays are used to
handle the word size difference between AArch32 and AArch64.

Unless I'm missing something this at least appears to agree with what
the compilers (both GCC and clang) are emitting for both big and little
endian and what a readelf that understands these is decoding so I think
at this point it's de facto the way things are interpreted.