Re: AIX support - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: AIX support
Date
Msg-id e0dc2bff-300b-4edd-912b-b6c52274bdc5@iki.fi
Whole thread Raw
In response to Re: AIX support  (Sriram RK <sriram.rk@outlook.com>)
Responses RE: AIX support
List pgsql-hackers
On 23/12/2024 17:55, Srirama Kucherlapati wrote:
> Hello Team,
> 
> In response to our previous discussions, we have refined the code to address
> 
> only the necessary adjustments focusing solely on the essential 
> modifications
> 
> for AIX compatibility. The codebase was pulled from the GitHub repository
> 
> (https://github.com/postgres/postgres.git <https://github.com/postgres/ 
> postgres.git>) and we resolved all issues
> 
> encountered during the configure and build processes. The following are the
> 
> minimal alterations needed to ensure AIX is supported.

Thanks, getting better.

Please generate the patches against 'master', rather than v17. We might 
choose to backport this to v17 later, but let's focus on the current 
development branch for now.

> Overview of Changes
> 
> We consulted with internal teams (GCC/Linker and Open Source) for each
> 
> modification. Details of the changes for the relevant files are as follows:
> 
> - configure:
> 
>    - Addressed AIX-specific alignment issues to support MAXALIGN_ALIGNOF.
> 
>    - Added comments regarding AIX alignment rules in the file.

The patch modifies 'configure', but that file is generated from 
'configure.ac'. Please show the changes to 'configure.ac'

Please also update the meson build system accordingly.

> +# AIX alignment info: We assume long's alignment is at least as strong as char, short, or
> +# int; but we must check long long (if it is being used for int64) and double.
> +#
> +# The AIX 'power' alignment rules apply the natural alignment of the "first
> +# member" if it is of a floating-point data type (or is an aggregate whose
> +# recursively "first" member or element is such a type). The alignment
> +# associated with these types for subsequent members use an alignment value
> +# where the floating-point data type is considered to have 4-byte alignment.
> +# 
> +# The double is aligned to 4-bytes on AIX in aggregates. But to maintain
> +# alignement across platforms the max alignment of long should be considered.

I don't quite understand this comment. Maybe some rephrasing or examples 
would help.

What is an aggregate in this context? A struct or union?

We use C99 int64_t for the int64 datatype nowadays, not "long long", so 
this seems a little outdated. (Since commit 962da900ac)

> - doc/src/sgml/dfunc.sgml:
> 
>    - Updated related documentation.

> diff --git a/doc/src/sgml/dfunc.sgml b/doc/src/sgml/dfunc.sgml
> index b94aefcd0c..554f9fac4c 100644
> --- a/doc/src/sgml/dfunc.sgml
> +++ b/doc/src/sgml/dfunc.sgml
> @@ -202,4 +202,23 @@ gcc -G -o foo.so foo.o
>    server expects to find the shared library files.
>   </para>
>  
> +<!--
> +Under AIX, object files are compiled normally but building the shared
> +library requires a couple of steps.  First, create the object file:
> +.nf
> +cc <other flags> -c foo.c
> +.fi
> +You must then create a symbol \*(lqexports\*(rq file for the object
> +file:
> +.nf
> +mkldexport foo.o `pwd` > foo.exp
> +.fi
> +Finally, you can create the shared library:
> +.nf
> +ld <other flags> -H512 -T512 -o foo.so -e _nostart \e
> +   -bI:.../lib/postgres.exp -bE:foo.exp foo.o \e
> +   -lm -lc 2>/dev/null
> +.fi
> +  -->
> +
>  </sect2>

Why is this commented out?

You say "updated related documentation", but these instructions were 
first added to the tree in year 1999, in commit f2f43efbe1, which 
apparently copied them from old man pages. Are they still current and 
relevant?

> - Shared Libraries Build Process:
> 
>    - Files Affected:
> 
>      src/Makefile.shlib
> 
>      src/backend/Makefile
> 
> - src/backend/port/aix/mkldexport.sh
> 
>    - Implemented AIX-specific changes for shared library creation using 
> export
> 
>      files.

>    - As per discussions with the linker team, the current design 
> mandates using
> 
>      the script method to extract symbols and build shared libraries.
> 
>    - This approach aligns with practices in other open-source projects like
> 
>      Python, OpenBLAS and other gnu tools(references, link).
> 
> https://github.com/python/cpython/blob/main/Modules/ld_so_aix.in 
> <https://github.com/python/cpython/blob/main/Modules/ld_so_aix.in>
> 
> https://github.com/OpenMathLib/OpenBLAS/ 
>
commit/892f8ff3e55e24fda9af3f6364319cce3f60116b#diff-4011a114c75fe804332139868806cbe23f275963e4e6afa9b57e51b2b9817293R261
<https://github.com/OpenMathLib/OpenBLAS/commit/892f8ff3e55e24fda9af3f6364319cce3f60116b#diff-4011a114c75fe804332139868806cbe23f275963e4e6afa9b57e51b2b9817293R261>

Thanks for the links. It's disappointing there isn't a standard way to 
do this. It's nice to see the comments in cpython's makeexp_aix script 
explaining the "hidden tricks". I'd love to see similar comments in 
mkldexport.sh explaining what it does. And also why the script is needed 
on AIX in the first place.

I wonder if meson's AIX support would have something built-in to do this?

>    - src/makefiles/Makefile.aix: Introduced AIX-specific makefile for 
> building.

> +# when building with gcc, need to make sure that libgcc can be found
> +ifeq ($(GCC), yes)
> +libpath := $(libpath):$(dir $(shell gcc -print-libgcc-file-name))
> +endif
> +
> +rpath = -Wl,-blibpath:'$(rpathdir)$(libpath)'

Is this still needed? I have no idea, but it seems surprising if gcc and 
ld don't handle this automatically.

> +LDFLAGS_SL += -Wl,-bnoentry -Wl,-H512 -Wl,-bM:SRE

What do all these options do? Why are they needed?

>    - src/template/aix: Defined memset flags for AIX.

Why? Did you benchmark it? How big is the difference?

I don't know if the default we have for MEMSET_LOOP_LIMIT is any good on 
modern compilers and systems in general. Perhaps we should just always 
use the system memset(). So for this patch, e key question is whether 
there's something AIX specific here. I'd assume no. I'd assume it to 
depend on the hardware rather than the OS.

-- 
Heikki Linnakangas
Neon (https://neon.tech)




pgsql-hackers by date:

Previous
From: Vladlen Popolitov
Date:
Subject: Re: COPY performance on Windows
Next
From: Vladlen Popolitov
Date:
Subject: Re: Windows meson build