Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tQOX3-002GeD-84 for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Dec 2024 10:22:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tQOX1-00ClcJ-SL for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Dec 2024 10:22:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tQOX1-00Clc5-HP for pgsql-hackers@lists.postgresql.org; Wed, 25 Dec 2024 10:22:23 +0000 Received: from lahtoruutu.iki.fi ([2a0b:5c81:1c1::37]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tQOWu-001XDN-A7 for pgsql-hackers@postgresql.org; Wed, 25 Dec 2024 10:22:22 +0000 Received: from [192.168.1.110] (dsl-hkibng22-50ddb7-241.dhcp.inet.fi [80.221.183.241]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4YJ79L3tR3z49Pyc; Wed, 25 Dec 2024 12:22:14 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1735122135; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eQgjHfXBqSeQJJ8c4wlu5VwiFwZmd8n1ncspG0HBDns=; b=eljdzvj6Z48CfAwUGreyke/2H5FCSbFjmmgGjEahEdBEjlrzY04AB2yxXnXJ2K9utxnYpI 89GEfLwHHullT+R+DLoiaKAPSWZJ7jb/e/v45RttW4KlTQ0bx/72NRTND8g7eFTH6fVVNh CTm9qvnnsecJJ6OCln9fjMy2EQJY8JQpp27mJWNreLot5bS8RBD0Ouifz+hb3gslHrZY05 nieJ05a7Fp222E4T5OBNBd6b1Uuh0frx/s//T5JuiK0N/SDU6SOOlZvbRizPh1yC7JmDD+ HYvOSs8HvGgfi44AsQYYwcEF5t2c0/ALx8yIxbf1Q5CJ/Bk5OFRj3RiDKRkRzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1735122135; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eQgjHfXBqSeQJJ8c4wlu5VwiFwZmd8n1ncspG0HBDns=; b=eL9i+tSBIQJ6h/z/KfWxy7tVpgFh2BVLSy/PxmgYOrCbkkSTW2eQovORZYtxKmxe2Hq+sW suxTHGS/E0f2+z2cvAbQZY3grLs4RqC5XJOP+zppSqMoYLIgvHlcjtaDfLCtqkbXtu2gJE l2vkC9roAhufv5EeGUE/IWWcfr+ieGr20jb1vQ3QsMKxPgG4kmrwpnmi+072w98Iha/bgf UHDIQQ6yFTKBPXSQs7Z4+7Yzw4JxOp1Y0HdD/AYBGCwyAwkMAk+n9byonGKTSvHgT4TJpI xXBR0J4IwOJ0PNMBAtmDpsFQDxMwPFF7OD7THUQDwZoWaUXLXQrC2GnvdZK1Vw== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1735122135; a=rsa-sha256; cv=none; b=e+tkqUg1Zj4QC5Vpl/e+wCorGbookJGqw9wIuobMrENYy59eOlZG+NjqXexZ0IT6QJn//z HRgIhaIR/z22pmA4G40BxG94lW03V41EbnHq9MhTVViix8GcjiYHOSp0pwO+UGE8LMFvby AYtPmiGCQouq6vwN/mxJK3T1xYMqMlhLyG262gsywAhVxCOyIyJj9zq/0i3kX47JdCYe8R TuCkIIhASnjaCQiGLB3uDOVw5XQIbc0iRXt8EFh0Uex8ABuQ9I7h+DnlmUS77bfM7enuLq oYCl4m7xRuhZCngoo9rr+ezFDluqQJ3f5DVu4areW8yvYn6gS6DF/eLJxHW8EQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi Message-ID: Date: Wed, 25 Dec 2024 12:22:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: AIX support To: Srirama Kucherlapati , "pgsql-hackers@postgresql.org" , "postgres-ibm-aix@wwpdl.vnet.ibm.com" Cc: Bruce Momjian , Robert Haas , Peter Eisentraut , Alvaro Herrera , Laurenz Albe , Noah Misch , Michael Paquier , Andres Freund , Thomas Munro , "tvk1271@gmail.com" , Tom Lane References: <7751f9c5-e2e6-4252-a9fa-14b3e78ddec9@iki.fi> <73dafd11-32f4-4238-b374-74eb917aa7fc@iki.fi> Content-Language: en-US From: Heikki Linnakangas In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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 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. > > > + > + > 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/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)