[erlang-questions] Port of Erlang (19.2) on AIX

Boroska András andras.boroska@REDACTED
Sun Jan 15 19:43:49 CET 2017


Hi Tony,

On Friday I was too quick to reply and among others I missed the part that
you are from Bull. :) I used your R1502 version as the starting point.
Still, let me add a few more hints. Mind you my memory can fail (I was
working with AIX ~ 2 years ago). Hopefully the experts will correct me if I
got something wrong. View it as my 2 cents. It is not comprehensive as you
will realise it soon.

> “what are the main features that must be made available ?”

AIX users tend to be large banks and similar organisations, and I imagine
many of them interested in running RabbitMQ. So, based on my limited
knowledge on the matter if you can start RabbitMQ that might be good enough
for many. To list the minimal features I would say that SMP, 64bit, SSL are
very likely. Others readers might add theirs too.

HIPE:

Hipe is mainly a performance boost for some applications, but many Erlang
use cases do not require it and as Mikael said you can ignore it for now.
Linux is always there for people preferring performance over AIX features.
:)

SMP:

On the other hand I would argue that enabling smp support is probably a
must for most use cases and it is not too difficult to achieve. One of the
issues is that the AIX provided Assembler does not support the local labels
syntax of the GNU Assembler. So, one either experiments with the GNU
Assembler or change the labels and jumps in
erts/include/internal/ppc32/atomic.h. See [1] and [2].

One can replace the label “1:\t” with “L1%=:\t” and replace the
corresponding jump “bne- 1b\n\t” with “bne- L1%=\n\t”. Of course use a
different label each time (E.g. L1, L2, L3, ...) This might or might not
have performance implications, but definitely better than not having SMP
support.

Since Power8 offers up to 96 simultaneous threads, scheduler binding might
be of interest of some potential users. To achieve that replace [3] and [4]
with:

#include “sys/thread.h”
bindprocessor(BINDTHREAD, thread_self(), (cpu_t) cpu)
or something similar.

64 bit and compiler/linker flags:

OBJECT_MODE=64 env variable needs to be exported obviously.

GCC needs the following flags to link the executable:
-Wl,-bexpall,-brtl,-b64 -maix64

For example you might have success bootstrapping by:

CFLAGS=“-maix64 -g -O2 -D_LINUX_SOURCE_COMPAT -L/opt/freeware/lib64
-L/opt/freeware/lib” \
LDFLAGS=“-Wl,-bexpall,-brtl,-b64,-blibpath:/opt/freeware/lib64:opt/freeware/lib
-maix64” \
AR=“ar -X64” \
./otp_build autoconf --with-ssl=/opt/freeware --build=<name of your build>
--disable-hipe

and then the same flags for running ./otp_build configure

Optionally you can also put the flags into the respective conf files. :)

Maybe some apps will not compile, like os_mon or odbc. Tip to proceed
quickly: you can skip any app by placing an empty file called SKIP in their
directory. (lib/*/SKIP)

OTHER:

Note that the C standard allows the malloc(0) system call to return either
zero or a pointer that cannot be dereferenced. Unixes typically return a
non-zero pointer, but AIX returns 0 by default. The C interface of Erlang
(erl_interface) calls malloc(0) for empty strings and checks the return
value against 0 to catch allocation errors. To prevent core dumps in such
cases it helps to define -D_LINUX_SOURCE_COMPAT which enforces the non-zero
pointer returns. Defining it will probably not hurt and  users of C drivers
will appreciate.

As I mentioned R18 reworked clock/time handling. Expect some
incompatibilities in that area.

The missing vsyslog on AIX can potentially be worked around by using
printf. Or perhaps you know a better solution.

As openssl versions seems to go obsolete rather quickly, expect that many
users will be interested not only in the binary but also in your source rpm
package when you upload to BullFreeware, so they can potentially compile
and link with a different openssl version.

BASIC TESTING:

To check if core/thread number detection works start the Erlang shell and
note the smp information in the first line. It should match the number of
CPU threads you have. For example [smp:8:8]. See [5]

Also note the presence of [64-bit] on the same line.

Bonus (may not be critical for many) if you can bind schedulers, for
example: erl +sct L0-7c0-7 +stbt db +S8:8
then erlang:system_info(scheduler_bindings). returns {0,1,2,....}

and erlang:system_info(cpu_topology). returns
[{processor,[{core,{logical,0}},{core,{logical,1}},{core,{logical,2}}, ...
}]}]

While in the shell issue crypto:start(). that should return ok if linking
with ssl worked.

There are also test suites for the emulator. You can run ./otp_build setup
with the above CFLAGS, AR, LDFLAGS, add your bin dir to the PATH and run
./otp_build tests. Change dir to release/tests/test_server, run erl, then
ts:install(), ts:run(emulator, [batch]).

Take the above information with a grain of salt as I have no access to AIX
and not an expert on building Erlang. The OTP team or others might correct
my mistakes.

Thank you for your work!

Best regards,

Andras

[1] https://gcc.gnu.org/ml/gcc/2005-12/msg00671.html
[2] http://stackoverflow.com/questions/3898435/labels-in-gcc-inline-assembly
[3]
https://github.com/erlang/otp/blob/maint-19/erts/lib_src/common/erl_misc_utils.c#L591
[4] https://github.com/erlang/otp/blob/maint-19/erts/configure.in#L2294
[5] http://erlang.org/doc/man/erl.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170115/c057fcec/attachment.htm>


More information about the erlang-questions mailing list