On 24 February 2024 23:29:36 EET, Andres Freund <andres@anarazel.de> wrote:
>Hi,
>
>On 2024-02-24 11:50:24 -0800, Noah Misch wrote:
>> > We see this happen with both xlc and gcc (new enough to know how to do
>> > this). One idea would be that the AIX *linker* is unable to align it,
>> > as that is the common tool-chain component here (and unlike stack and
>> > heap objects, this scope is the linker's job). There is a
>> > pre-existing example of a zero-buffer that is at file scope like that:
>> > pg_prewarm.c. Perhaps it doesn't get tested?
>> >
>> > Hmm.
>>
>> GCC docs do say "For some linkers, the maximum supported alignment may be very
>> very small.", but AIX "man LD" says "data sections are aligned on a boundary
>> so as to satisfy the alignment of all CSECTs in the sections". It also has -H
>> and -K flags to force some particular higher alignment.
>
>Some xlc manual [1] states that
>
> n must be a positive power of 2, or NIL. NIL can be specified as either
> __attribute__((aligned())) or __attribute__((aligned)); this is the same as
> specifying the maximum system alignment (16 bytes on all UNIX platforms).
>
>Which does seems to suggest that this is a platform restriction.
My reading of that paragraph is that you can set it to any powet of two, and it should work. 16 bytes is just what you
getif you set it to NIL.
>Let's just drop AIX. This isn't the only alignment issue we've found and the
>solution for those isn't so much a fix as forcing everyone to carefully only
>look into one direction and not notice the cliffs to either side.
I think the way that decision should go is that as long as someone is willing to step up and do the work keep AIX
supportgoing, we support it. To be clear, that someone is not me. Anyone willing to do it?
Regarding the issue at hand, perhaps we should define PG_IO_ALIGN_SIZE as 16 on AIX, if that's the best the linker can
doon that platform.
We could also make the allocation 2*PG_IO_ALIGN_SIZE and round up the starting address ourselves to PG_IO_ALIGN_SIZE.
Orallocate it in the heap.
- Heikki
