How to build an IBM PowerLinux application on an Intel x86 server

How to build an IBM PowerLinux application on an Intel x86 server

IBM®The practical value of Advanced Toolchain for PowerLinux cross compiler is that developers can compile and build IBM Power Architecture on a development platform they are already familiar with (in most cases x86 ).®Application. This article describes how developers can use the Toolchain cross compiler to easily build source code running on Power Architecture. This article will also answer questions about the performance, functions, and features of cross-compiled applications in IBM PowerLinux™The ability to debug cross-compiling applications in the original environment on the server.

Introduction

Linux®To port an application to another platform, for example, PowerLinux, you need to set up a different Build Environment to compile the application, right? No. You can use the cross compiler on the x86 server to build a different platform architecture (such as IBM Power®. The cross-compiler already exists for a long time. They are mainly used to build applications for embedded systems with limited resources to run operating systems that can support native compilers. The first time I learned about cross-compiler, I was involved in a project for handheld devices. I write and compile the source code on the x86 workstation, and load these binaries into the device through a serial communication connection. Recently, I am using a cross compiler to build a simple application to control the servo motor of a remote control device I have studied. Now, let's go to the topic.

This article describes the cross compilers included in IBM Advance Toolchain for PowerLinux. From here on, I will refer to IBM Advance Toolchain for PowerLinux as"Toolchain".ToolchainIs a group of open-source development tools and runtime libraries that allow users to take advantage of IBM's latest Power hardware features on Linux.ToolchainIt is self-contained and independent from the system toolchain. It is installed on/optSo it does not overwrite the default Linux release toolchain. As of this article, the latest version includes the latest stable version of the following packages:

• GNU Compiler Collection (gcc, g ++, and gfortran) and various supported IBM POWER®CPU optimized gcc Runtime
• The gnu c library (glibc) is separately optimized for supported POWER processors.
• GNU binary utility (binutils)
• Optimized the decimal Floating Point Library (libdfp) and added®And IBM POWER8™Hardware DFP support for processor servers
• AUXV Library (libauxv)
• GNU Debugger (gdb)
• Performance analysis tools (oprofile, valgrind, and itrace)
• Multi-core exploitation Library (Intel®TBB, Userspace RCU), starting from 5.0-3
• And multiple supported libraries (such as libhugetlbfs and zlib)

DownloadToolchainFor more information, see the references section at the end of this article.

For the purpose of this article, we will mainly introduce the toolchain cross compiler. This topic describes how to useToolchainThe cross-compiler builds binary executable programs suitable for PowerLinux on x86 servers. The following questions are also answered.

• Can cross-compiling applications built on the x86 platform have better execution performance than native binary programs built on PowerLinux?
• Does the cross-compiled application and library built on the x86 platform have the same binary functions as the application built on PowerLinux?
• Will the cross-compiled applications built on the x86 platform generate binary programs that can be executed for native debugging on PowerLinux?

To answer these questions, I used two popular open-source application PostgreSQL and Apache httpd servers. Both PostgreSQL and Apache httpd source code releases are used on x86 servers.ToolchainIt is built by a cross-compiler and is native on the PowerLinux server. These applications are then installed and run in different installation directories on a PowerLinux server. I ran two benchmarking tools for these applications and compared their performance and functions.

The test results are described in the following sections. For those interested in re-creating a test, the environment and configuration section and the section on building an application using toolchain respectively describe the environment configuration and how to build these applications.

Result

To test these applications, I used some public benchmarking tools. For PostgreSQL, I used pgbench-tool from GitHub. It uses the pgbench tool that comes with the PostgreSQL source code release. For Apache httpd, I use the Apache release (AB) tool that is included in the apache httpd source code release. Refer to the reference section at the bottom of this article to learn about the download of pgbench-tools.

PostgreSQL test settings and results

After a PostgreSQL application is built using a cross compiler on an x86 server, the complete set of binary programs is transferred to a PowerLinux server. We have made the following changes to the default configuration file:

Postgresql.confmax_connections = 4096shared_buffers = 2048MBsynchronous_commit = offcheckpoint_segments = 3checkpoint_timeout = 5min

Modifykernel.semValue.

sysctl.confkernel.sem = 250     32000   32   12288

Modify the pgbench-tools configuration file

MAX_WORKERS="32"。

According to the introduction on the pgbench-tools website, perform the following steps for PostgreSQL testing:

1. Create pgbench AND results databases.
2. Initialize the results database.
3. Create a test set that contains the description.
4. Run the test using the runset script.
5. Compile and submit the test results.

For more information, see the pgbench-tools readme file.

Postgresql results (cross-compilation)

The following is the result of running pgbench-tools on the Power server for the cross-compiled binary program.

Figure 1. Proportional Coefficient of the Cross-compiled PostgreSQL binary Program

This proportional coefficient shows the change trend of the number of transactions processed per second as the database size increases. The green line indicates the database size (MB), and the red line indicates the number of transactions processed per second. This chart shows that as the database size increases, the number of transactions processed per second will decrease.

Figure 2. Cross-compiled PostgreSQL binary program scalability

Figure 2 shows the scalability. It indicates that as the number of clients increases, the number of transactions processed per second also increases.

PostgreSQL results (native compilation)

When testing the native compiled binary program, the configuration settings and database location (/tmp/usr/local/pgsql/data) are exactly the same as those of the Cross-compiled PostgreSQL ). To ensure that the database is clean, discard the results and pgbench databases before starting the test.

Postgresql # drop database results;
DROP DATABASE

Postgresql # drop database pgbench;
DROP DATABASE

The proportional coefficient and scalability diagram are shown in figure 3 and figure 4. As mentioned earlier, this proportional coefficient shows the changing trend of the number of transactions processed per second as the database size increases. The green line indicates the database size (MB), and the red line indicates the number of transactions processed per second.

Figure 3. Proportional Coefficient of the native PostgreSQL binary Program

The scalability diagram in figure 4 shows that as the number of clients increases, the number of transactions processed per second also increases.

Figure 4. Native PostgreSQL binary program scalability

You can note that the curve of the Cross-compiled binary program is very similar to that of the native compiled binary program. This simple test shows that cross-compiling on the x86 server can produce binary programs with the same performance characteristics as the native compiled code.

Apache httpd test settings and results

To test Apache httpd, I used the benchmark testing tool that is included with the Apache httpd source code release.AB. Similar to PostgreSQL, Apache httpd usesToolchainBuilt by the cross compiler and transmitted the binary program to the PowerLinux server. I modified the default httpd. conf fileHtdocsChange the directory to the local document directory. Retain the default value for the remaining settings.

I used to runABThe command line and parameters of the tool are as follows:

#./ab -n 500000 -c 100 -g out1.data http://9.3.4.241/

I run this command three times, write the output to out1.data, out2.data, and out3.data, and useGnuplotThe utility and parameters in the benchmark. tpl file depict the images of these files, as shown below.

# gnuplot benchmark.tpl
benchmark.tpl# output as png imageset terminal png
# save file to "benchmark.png"set output "benchmark.png"
# graph titleset title "Benchmark for 9.3.4.241"
# aspect ratio for image sizeset size 1,1
# enable grid on y-axisset grid y
# x-axis label set xlabel "Request"
# y-axis labelset ylabel "Response Time (ms)"
# plot data using column 10 with smooth sbezier linesplot "out1.data" using 10 smooth sbezier with lines title "Benchmark 1:", \"out2.data" using 10 smooth sbezier with lines title "Benchmark 2:", \"out3.data" using 10 smooth sbezier with lines title "Benchmark 3:"

For more information about the Apache benchmarking tool, see references at the end of this article.

Apache httpd results (native compilation and cross-compilation)

GnuplotThe utility generates a file named benchmark.png for each test. These images can be viewed using any image viewer. See Figure 5 and figure 6.

Figure 5 shows the native httpd graph.

Figure 5. Native compiled httpd response time Graph

Figure 6 shows the cross-compiled httpd graph.

Figure 6. Cross-compiled httpd response time Graph

You can note that the two curves show very similar performance characteristics. You can use different Web documents and data to perform more tests.

Back to Top

Function and debugging discovery

In addition to performance, developers may have otherToolchainCross-compiler usage problems. This section answers questions related to functions and the ability to debug cross-compiled binary programs. These problems are:

• Is the binary program built by the cross compiler functionally compatible with the native executable program?
• Can I debug a cross-compiled binary program on a PowerLinux server?

The following two simple cases help to answer these questions.

• Example 1: replace one or more shared libraries of a native httpdToolchainShared libraries built by the cross compiler. Check whether the native httpd is still running normally.
• Case 2: append a debugger to a running process on the PowerLinux server. This process is a cross-compiled binary executable program built from the x86 server. Set a breakpoint, set the source code directory, and execute a group of functions.

Case 1: Function Test

The operation instructions I followed in Case 1 are as follows:

1. Install httpd built locally in/home/usr/local.
2. Run the/home/use/local/bin/httpd binary ProgramLddUtility to display its shared binary dependencies. You can notice that both the libaprutil-1.so.0 and libapr-1.so.0 are located in/home/usr/local/lib. These libraries are part of the native libraries required by httpd.

[root@localhost lib]# ldd ../../bin/httpd    linux-vdso64.so.1 => (0x00000fffa1140000)    libaprutil-1.so.0 => /home/usr/local/apr/lib/libaprutil-1.so.0 (0x00000fffa10c0000)    libapr-1.so.0 => /home/usr/local/apr/lib/libapr-1.so.0 (0x00000fffa1060000)    librt.so.1 => /opt/at7.0-5-rc1/lib64/power7/librt.so.1 (0x00000fffa1040000)    libcrypt.so.1 => /opt/at7.0-5-rc1/lib64/power7/libcrypt.so.1 (0x00000fffa0ff0000)    libpthread.so.0 => /opt/at7.0-5-rc1/lib64/power7/libpthread.so.0 (0x00000fffa0fb0000)    libdl.so.2 => /opt/at7.0-5-rc1/lib64/power7/libdl.so.2 (0x00000fffa0f90000)    libc.so.6 => /opt/at7.0-5-rc1/lib64/power7/libc.so.6 (0x00000fffa0da0000)    /opt/at7.0-5-rc1/lib64/ld64.so.1 => /lib64/ld64.so.1 (0x00000000267a0000)

3. Delete the shared library libaprutil-1.so.0 and libapr-1.so.0.
4. Copy the cross-compiled library libaprutil-1.so.0 and libapr-1.so.0 to/tmp/usr/local/lib.
5. Include/tmp/usr/local/lib in LD_LIBRARY_PATH.

# cd /home/usr/local/apr/lib # rm libaprutil-1.so.0 # rm libapr-1.so.0 # export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/tmp/usr/local/lib

6. Run againLddUtility, you can see that httpd now uses the library in/tmp/usr/local/lib.

[root@localhost lib]# ldd ../../bin/httpd    linux-vdso64.so.1 => (0x00000fff951a0000)    libaprutil-1.so.0 => /tmp/usr/local/apr/lib/libaprutil-1.so.0 (0x00000fff95150000)    libapr-1.so.0 => /tmp/usr/local/apr/lib/libapr-1.so.0 (0x00000fff950f0000)    librt.so.1 => /opt/at7.0-5-rc1/lib64/power7/librt.so.1 (0x00000fff950d0000)    libcrypt.so.1 => /opt/at7.0-5-rc1/lib64/power7/libcrypt.so.1 (0x00000fff95080000)    libpthread.so.0 =>/opt/at7.0-5-rc1/lib64/power7/libpthread.so.0 (0x00000fff95040000)    libdl.so.2 => /opt/at7.0-5-rc1/lib64/power7/libdl.so.2 (0x00000fff95020000)    libc.so.6 => /opt/at7.0-5-rc1/lib64/power7/libc.so.6 (0x00000fff94e30000)    libexpat.so.0 => /tmp/usr/local/apr/lib/libexpat.so.0 (0x00000fff94df0000)    /opt/at7.0-5-rc1/lib64/ld64.so.1 => /lib64/ld64.so.1 (0x0000000022730000)

7. Start the application to see if it can run as a normal application.

# cd /home/usr/local/bin # ./apachectl start # ps –ef | grep httproot 11022 1 0 15:41 ?00:00:00 /home/usr/local/bin/httpd -k startdaemon 11023 11022 0 15:41 ?00:00:00 /home/usr/local/bin/httpd -k startdaemon 11024 11022 0 15:41 ?00:00:00 /home/usr/local/bin/httpd -k startdaemon 11025 11022 0 15:41 ?00:00:00 /home/usr/local/bin/httpd -k startdaemon 11111 11022 0 15:41 ?00:00:00 /home/usr/local/bin/httpd -k start

8. Open the PowerLinux server running the httpd process in the browser and check whether the following message is displayed in the browser:

It works!

In this scenario, we use a native library and a cross-compiled library. The cross-compiled library is built using the ppc64 architecture option. In this case, we can prove that we can combine the cross-compiled library and native compiled executable programs on the PowerLinux server.

Case 2: Debugging

In the second case, we tried to prove that the cross-compiled executable program can be debugged on the PowerLinux server. The operation instructions I followed in Case 2 are as follows:

1. UseGdbTo the httpd process. Make sure that the httpd version used isToolchainCross-compiler version built on the x86 platform.

[root@localhost ~]# gdb attach 25412 GNU gdb (GDB) 7.6.50.20130722-cvsCopyright (C) 2013 Free Software Foundation, Inc.License GPLv3+:GNU GPL version 3 or later 

 

 
  
Set the directory to the source code release.

 
(gdb) set directories /home/ProjectToolchainPLCompile/apr-1.5.1
(gdb) where #0 0x00000fff7cb676f8 in ___newselect_nocancel () at ../sysdeps/unix/syscall-template.S:81 #1 0x00000fff7cd38274 in apr_sleep (t=<optimized out>) at time/unix/time.c:246 #2 0x0000000010034220 in ap_wait_or_timeout (status=0xfffeaa1e704, exitcode=0xfffeaa1e700,        ret=0xfffeaa1e6e0, p=0x1003d0c6138, s=<optimized out>) at mpm_common.c:195 #3 0x0000000010079238 in server_main_loop (remaining_children_to_start=<optimized out>)        at worker.c:1654 #4 worker_run (_pconf=<optimized out>, plog=<optimized out>, s=<optimized out>)        at worker.c:1823#5 0x0000000010033430 in ap_run_mpm (pconf=0x1003d0c6138, plog=0x1003d0f3378, s=0x1003d0ef4c0)        at mpm_common.c:96 #6 0x000000001002a5d8 in main (argc=3, argv=0xfffeaa1ee28) at main.c:777

 

 
  
Move a functionapr_sleep.

 
(gdb) up #1 0x00000fff7cd38274 in apr_sleep (t=<optimized out>) at time/unix/time.c:246246        select(0, NULL, NULL, NULL, &tv);

 

 
  
Listapr_sleepSource code.

 
(gdb) list241       delay(t/1000); 242    #else 243       struct timeval tv; 244       tv.tv_usec = t % APR_USEC_PER_SEC; 245       tv.tv_sec = t / APR_USEC_PER_SEC; 246       select(0, NULL, NULL, NULL, &tv); 247    #endif 248    } 249 250    #ifdef OS2

 

 
  
This process is separated.

 
(gdb) detach Detaching from program:/tmp/usr/local/bin/httpd, process 25412(gdb) quit
Remote debugging
ToolchainAlso includeGdbserverProgram. It allows developers to remotelyGdbSessions are connected to their applications. Make sure to callGdbserverYou use gdb from toolchain. For me, be sure to check whether it is on my path.
# type gdbservergdbserver is hashed (/opt/at7.0-5-rc1/bin/gdbserver)
This is used on the PowerLinux ServerGdbserverAn example of a program. We will attach to a running httpd process:
[root@stgisv241 bin]# gdbserver --attach 9.3.4.240:2345 22589 Attached; pid = 22589Listening on port 2345
Call the httpd binary program on the local server on the x86 serverPowerpc64-linux-gdbProgram. Note thatGdbVersion namePowerpc64-linux-gdb. The httpd binary program used is the same cross-compiled binary program version running on the PowerLinux server.
# pwd /tmp/usr/local/bin [root@stgisv240 bin]# powerpc64-linux-gdb ./httpd GNU gdb (GDB) 7.6.50.20130722-cvs Copyright (C) 2013 Free Software Foundation, Inc.License GPLv3+:GNU GPL version 3 or later 
Still in the x86 gdb sessionGdbTo call the target Command, as shown in the following example.
(gdb) target remote 9.3.4.241:2345Remote debugging using 9.3.4.241:2345warning:Could not load shared library symbols for 7 libraries,    e.g. /opt/at7.0-5-rc1/lib64/power7/librt.so.1. Use the "info sharedlibrary" command to see the complete listing.Do you need "set solib-search-path" or "set sysroot"?Reading symbols from /tmp/usr/local/apr/lib/libaprutil-1.so.0...done.Loaded symbols for /tmp/usr/local/apr/lib/libaprutil-1.so.0Reading symbols from /tmp/usr/local/apr/lib/libexpat.so.0...done.Loaded symbols for /tmp/usr/local/apr/lib/libexpat.so.0Reading symbols from /tmp/usr/local/apr/lib/libapr-1.so.0...done.Loaded symbols for /tmp/usr/local/apr/lib/libapr-1.so.0 ….Reading symbols from /tmp/usr/local/modules/mod_alias.so...done. Loaded symbols for /tmp/usr/local/modules/mod_alias.sowarning:Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code.0x00000fffa8fe76f8 in ??()(gdb)
We can see someGdbWarning messages related to library symbols cannot be found.GdbCommandinfo sharedlibraryDisplays the libraries where gdb cannot read symbols from. The following sample output shows the libraries where gdb cannot read symbols from them. Note that these libraries are part of the system and you do not need to worry about them unless they are opened during compilation.
(gdb) info sharedlibrary From               To                 Syms Read Shared Object Library                                       No        linux-vdso64.so.1 0x00000fffa924ce80 0x00000fffa927e8a8 Yes       /tmp/usr/local/apr/lib/libaprutil-1.s0x00000fffa91f7940 0x00000fffa922aa18 Yes       /tmp/usr/local/apr/lib/libexpat.so.00x00000fffa9192e60 0x00000fffa91ca0b8 Yes       /tmp/usr/local/apr/lib/libapr-1.so.0                                       No        /opt/at7.0-5-rc1/lib64/power7/librt.s                                      No        /opt/at7.0-5-rc1/lib64/power7/libcrypt                                      No        /opt/at7.0-5-rc1/lib64/power7/libdl.s                                      No        /opt/at7.0-5-rc1/lib64/power7/libpthre                                       No        /opt/at7.0-5-rc1/lib64/power7/libc.so                                      No        /opt/at7.0-5-rc1/lib64/ld64.so.1                                      No        /opt/at7.0-5-rc1/lib64/power7/libnss_f0x00000fffa8ea0c00 0x00000fffa8ea1878 Yes       /tmp/usr/local/modules/mod_authn_file0x00000fffa8e810a0 0x00000fffa8e82108 Yes       /tmp/usr/local/modules/mod_authn_core.0x00000fffa8e60da0 0x00000fffa8e61bb0 Yes       /tmp/usr/local/modules/mod_authz_host. 0x00000fffa8e40f40 0x00000fffa8e41ed0 Yes       /tmp/usr/local/modules/mod_authz_group0x00000fffa8e208e0 0x00000fffa8e20f18 Yes       /tmp/usr/local/modules/mod_authz_user.0x00000fffa8e019e0 0x00000fffa8e046d8 Yes       /tmp/usr/local/modules/mod_authz_core....
As shown in Case 2, cross-compiled executable programs can be debugged locally or remotely on the PowerLinux server where native compiled executable programs are debugged. In addition, you can note that the binary program uses–gTo generate debugging information.
For more details, please continue to read the highlights on the next page:

  

 
   
 
    
 
     
 
      
 
       
1
 
       
2
 
       
Next Page