Содержание


Компиляция приложений для IBM PowerLinux на серверах Intel x86

Работа с кросс-компилятором IBM Advance Toolchain for PowerLinux

Comments

Как известно, для переноса Linux®-приложений архитектуры x86 на другую платформу (например, на платформу PowerLinux) требуется настроить отдельную среду компиляции. Однако делать это вовсе не обязательно. При помощи кросс-компилятора можно генерировать на сервере x86 исполняемые файлы, которые будут работать на платформе с другой архитектурой, например, на платформе IBM Power®. Кросс-компиляторы используются уже очень давно. В основном с их помощью создаются приложения для встраиваемых систем, производительность которых недостаточна для исполнения операционной системы, под управлением которой мог бы работать нативный компилятор. Мое первое знакомство с кросс-компиляторами состоялось, когда я работал над проектом для портативного устройства. Я написал и скомпилировал исходный код на рабочей станции x86, после чего загрузил полученные исполняемые файлы на устройство через последовательный интерфейс. А совсем недавно с помощью кросс-компилятора я создал простые приложения для управления сервоприводами робота, над которым я работал. Но давайте перейдем от моих историй непосредственно к делу.

В этой статье мы рассмотрим кросс-компилятор, входящий в состав инструментария IBM Advance Toolchain for PowerLinux. Далее в этой статье я буду называть инструментарий IBM Advance Toolchain for PowerLinux просто "toolchain-инструментарием". Toolchain-инструментарий – это набор Open Source-инструментов разработчика и библиотек времени исполнения, позволяющий пользователям Linux использовать все новейшие аппаратные преимущества платформы IBM Power. Сам toolchain-инструментарий является независимым продуктом и не требует наличия дополнительных системных компонентов. Он устанавливается в директорию /opt и не замещает собой встроенный инструментарий, содержащийся в дистрибутиве Linux по умолчанию. На момент написания этой статьи последняя версия toolchain-инструментария включала в себя стабильные версии следующих пакетов:

  • Пакет GNU Compiler Collection (gcc, g++ и gfortran), а также специально оптимизированные библиотеки времени исполнения gcc для поддерживаемых процессоров IBM POWER®
  • Библиотека GNU C (glibc), специально оптимизированная для поддерживаемых процессоров POWER
  • Двоичные утилиты GNU (binutils)
  • Оптимизированная библиотека libdfp с аппаратной поддержкой операций с плавающей десятичной точкой для серверов на базе процессоров IBM POWER7® и IBM POWER8™
  • Библиотека AUXV (libauxv)
  • Отладчик GNU debugger (gdb)
  • Инструменты для анализа производительности (oprofile, valgrind, itrace)
  • Библиотеки для работы с многоядерными процессорами (Intel® TBB, Userspace RCU), начиная с версии 5.0-3
  • Несколько вспомогательных библиотек (например, libhugetlbfs, zlib и т. д.)

Для получения информации о загрузке toolchain-инструментария обратитесь к разделу "Ресурсы" в конце статьи.

В этой статье мы преимущественно будем рассматривать кросс-компилятор, входящий в состав toolchain-инструментария. Вы узнаете, как с помощью кросс-компилятора создавать исполняемые файлы для платформы PowerLinux, работая на сервере x86. Также вы получите ответы на следующие вопросы:

  • Будут ли кросс-компилированные приложения, созданные на платформе x86, работать так же хорошо, как приложения, созданные в нативной среде PowerLinux?
  • Будут ли кросс-компилированные приложения и библиотеки, созданные на платформе x86, иметь такую же функциональность, как приложения, созданные в среде PowerLinux?
  • Можно ли в среде PowerLinux выполнять отладку двоичных файлов кросс-компилированных приложений, созданных на платформе x86?

Чтобы ответить на эти вопросы, я использовал два популярных Open Source-приложения – СУБД PostgreSQL и http-сервер Apache. Оба этих приложения были скомпилированы из исходного кода с помощью кросс-компилятора toolchain-инструментария на сервере x86 и с помощью встроенного компилятора на сервере PowerLinux. Затем эти приложения были проинсталлированы и запущены на сервере PowerLinux из различных директорий. Для сравнения их производительности и функциональности я воспользовался несколькими пакетами для оценки производительности.

Результаты тестов приведены в следующих разделах. Если вы захотите воспроизвести эти тесты в своей среде, то информацию о конфигурации среды вы найдете в разделе Тестовая среда и ее конфигурация, а информацию о параметрах компиляции приложений – в разделе Компиляция приложений при помощи toolchain-инструментария.

Результаты

Для тестирования приложений я использовал несколько общедоступных инструментов. Для тестирования PostgreSQL я воспользовался инструментом pgbench-tool, который можно загрузить из GitHub. Этот инструмент использует утилиту pgbench, входящую в инсталляционный дистрибутив PostgreSQL. Для тестирования http–сервера Apache я использовал утилиту apache bench (ab) из инсталляционного дистрибутива Apache httpd. Ссылка для загрузки инструмента pgbench-tools приведена в разделе "Ресурсы" в конце статьи.

Тестовая настройка PostgreSQL и полученные результаты

Я скомпилировал приложение PostgreSQL с помощью кросс-компилятора на сервере x86 и перенес полученные исполняемые файлы на сервер PowerLinux. Начальные конфигурационные файлы были изменены следующим образом:

Postgresql.conf
max_connections = 4096
shared_buffers = 2048MB
synchronous_commit = off
checkpoint_segments = 3
checkpoint_timeout = 5min

Измените значение параметра kernel.sem в системных настройках PowerLinux.

sysctl.conf
kernel.sem = 250     32000   32   12288

Измените конфигурационный файл утилиты pgbench-tools.

MAX_WORKERS="32".

Тестирование PostgreSQL проводилось в соответствии с документацией, размещенной на Web-сайте утилиты pgbench-tools, по следующему алгоритму:

  1. Создание тестовой базы данных pgbench и базы данных результатов.
  2. Инициализация базы данных результатов.
  3. Создание набора тестов с описаниями.
  4. Запуск тестов с помощью сценария runset.
  5. Обработка и публикация результатов тестирования.

Для получения подробной информации об используемых в тестах командах обратитесь к документации pgbench-tools README (EN).

Результаты тестирования кросс-компилированного приложения Postgresql

Ниже представлены результаты тестирования кросс-компилированных исполняемых файлов PostgreSQL на сервере Power.

Рисунок 1. Коэффициент масштабирования для кросс-компилированных исполняемых файлов PostgreSQL
Рисунок 1. Коэффициент масштабирования для кросс-компилированных исполняемых файлов PostgreSQL
Рисунок 1. Коэффициент масштабирования для кросс-компилированных исполняемых файлов PostgreSQL

Коэффициент масштабирования показывает зависимость количества выполняемых в секунду транзакций от размера базы данных. Зеленая линия соответствует размеру базы данных в мегабайтах, а красная линия – количеству выполняемых в секунду транзакций. Из полученного графика видно, что по мере роста базы данных количество выполняемых в секунду транзакций уменьшается.

Рисунок 2. Диаграмма масштабируемости для кросс-компилированных исполняемых файлов PostgreSQL
Рисунок 2. Диаграмма масштабируемости для кросс-компилированных исполняемых файлов PostgreSQL
Рисунок 2. Диаграмма масштабируемости для кросс-компилированных исполняемых файлов PostgreSQL

На рисунке 2 изображена диаграмма масштабируемости, из которой видно, что при увеличении количества клиентских подключений количество выполняемых в секунду транзакций также увеличивается.

Результаты тестирования приложения Postgresql, скомпилированного в нативной среде

При тестировании исполняемых файлов, скомпилированных в нативной среде, использовались те же настройки конфигурации и базы данных (/tmp/usr/local/pgsql/data), что и при тестировании кросс-компилированных файлов. Чтобы очистить базы данных перед началом тестирования, выполните следующие команды:

Postgresql# drop database results;
DROP DATABASE

postgresql# drop database pgbench;
DROP DATABASE

Коэффициент масштабирования и диаграмма масштабируемости показаны на рисунке 3 и рисунке 4. Как уже было сказано, Коэффициент масштабирования показывает зависимость количества выполняемых в секунду транзакций от размера базы данных. Зеленая линия соответствует размеру базы данных в мегабайтах, а красная линия – количеству выполняемых в секунду транзакций.

Рисунок 3. Коэффициент масштабирования для исполняемых файлов PostgreSQL, скомпилированных в нативной среде
Рисунок 3. Коэффициент масштабирования для исполняемых файлов PostgreSQL, скомпилированных в нативной среде
Рисунок 3. Коэффициент масштабирования для исполняемых файлов PostgreSQL, скомпилированных в нативной среде

Диаграмма масштабируемости на рисунке 4 показывает, что при увеличении количества клиентских подключений количество выполняемых в секунду транзакций также увеличивается.

Рисунок 4. Диаграмма масштабируемости для исполняемых файлов PostgreSQL, скомпилированных в нативной среде
Рисунок 4. Диаграмма масштабируемости для исполняемых файлов PostgreSQL, скомпилированных в нативной среде
Рисунок 4. Диаграмма масштабируемости для исполняемых файлов PostgreSQL, скомпилированных в нативной среде

Обратите внимание, что графики для кросс-компилированных приложений и графики для приложений, скомпилированных в нативной среде, очень похожи. Проведенное тестирование показывает, что двоичные файлы приложений, полученные кросс-компиляцией на серверах x86, могут иметь такую же производительность, что и при компиляции кода в нативной среде.

Тестовая настройка http-сервера Apache и полученные результаты

Для тестирования http-сервера Apache я использовал инструмент под названием ab, который включен в дистрибутив Apache httpd. Как и в случае с PostgreSQL, сервер Apache был собран при помощи кросс-компилятора из состава toolchain-инструментария, а полученные исполняемые файлы были скопированы на сервер PowerLinux. Я изменил директорию htdocs в конфигурационном файле httpd.conf так, чтобы она указывала на локальную директорию с документами. Значения всех остальных параметров остались без изменений.

При запуске утилиты ab я указывал следующие аргументы и параметры командной строки:

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

Я запускал эту команду три раза, записывая результаты в файлы out1.data, out2.data и out3.data. Затем на основе этих данных я строил графики с помощью утилиты gnuplot, запуская ее со следующими параметрами (файл benchmark.tpl):

# gnuplot benchmark.tpl
benchmark.tpl # output as png image set terminal png
# save file to "benchmark.png" set output "benchmark.png"
# graph title set title "Benchmark for 9.3.4.241"
# aspect ratio for image size set size 1,1
# enable grid on y-axis set grid y
# x-axis label set xlabel "Request"
# y-axis label set ylabel "Response Time (ms)"
# plot data using column 10 with smooth sbezier lines plot "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:"

Для получения дополнительной информации об утилите тестирования Apache обратитесь к разделу Ресурсы в конце этой статьи.

Результаты тестирования Apache httpd (скомпилированного в нативной среде и кросс-компилированного)

Для каждого теста утилита gnuplot создает файл с именем benchmark.png, который можно открыть в любом графическом редакторе. Оба графика представлены на рисунке 5 и рисунке 6.

На рисунке 5 изображен график для httpd-сервера, скомпилированного в нативной среде.

Рисунок 5. График времени отклика для http-сервера, скомпилированного в нативной среде
Рисунок 5. График времени отклика для http-сервера, скомпилированного в нативной среде

На рисунке 6 изображен график для кросс-компилированного httpd-сервера.

Рисунок 6. График времени отклика для кросс-компилированного http-сервера
Рисунок 6. График времени отклика для кросс-компилированного http-сервера

Обратите внимание, что оба графика показывают практически одинаковую производительность. Я призываю читателей самостоятельно провести дополнительные тесты, используя различные Web-документы и данные.

Результаты сравнения функциональности и возможностей отладки

Помимо производительности разработчиков интересуют и другие вопросы, связанные с использованием кросс-компилятора toolchain-инструментария. В этом разделе мы ответим на следующие вопросы, связанные с функциональностью и возможностями отладки кросс-компилированных двоичных файлов:

  • Совместимы ли кросс-компилированные библиотеки с исполняемыми файлами, скомпилированными в нативной среде?
  • Можно ли выполнять отладку кросс-компилированных двоичных файлов на сервере PowerLinux?

Для ответа на этот вопрос мы рассмотрим два простых сценария.

  • Сценарий 1. Мы заменим одну или несколько общих библиотек http-сервера, скомпилированных в нативной среде, библиотеками, скомпилированными с использованием кросс-компилятора из состава toolchain-инструментария, и проверим, будет ли http-сервер работать корректно.
  • Сценарий 2. С помощью отладчика мы подключимся к запущенному процессу на сервере PowerLinux. Это будет процесс исполняемого файла, кросс-компилированного на сервере x86. Мы установим контрольную точку, зададим исходную директорию и сделаем листинг функции.

Сценарий 1. Тестирование функциональности

Ниже представлены пошаговые инструкции для выполнения тестов в первом сценарии:

  1. Проинсталлируйте в директорию /home/usr/local пакет httpd, скомпилированный в нативной среде.
  2. Запустите утилиту ldd , указав директорию /home/use/local/bin/httpd, чтобы просмотреть зависимости общих библиотек. Заметьте, что файлы libaprutil-1.so.0 и libapr-1.so.0 расположены в директории/home/usr/local/lib. Эти библиотеки являются частью необходимых для работы 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)
  1. Удалите файлы libaprutil-1.so.0 и libapr-1.so.0.
  2. Скопируйте кросс-компилированные библиотеки libaprutil-1.so.0 и libapr-1.so.0 в директорию /tmp/usr/local/lib.
  3. Добавьте директорию /tmp/usr/local/lib в переменную 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
  1. Снова запустите утилиту ldd и вы увидите, что теперь httpd использует библиотеки из директории /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)
  1. Запустите приложение, чтобы проверить, будет ли оно правильно функционировать.
# cd /home/usr/local/bin 
# ./apachectl start 
# ps –ef | grep http
root 11022 1 0 15:41 ? 00:00:00 /home/usr/local/bin/httpd -k start
daemon 11023 11022 0 15:41 ? 00:00:00 /home/usr/local/bin/httpd -k start
daemon 11024 11022 0 15:41 ? 00:00:00 /home/usr/local/bin/httpd -k start
daemon 11025 11022 0 15:41 ? 00:00:00 /home/usr/local/bin/httpd -k start
daemon 11111 11022 0 15:41 ? 00:00:00 /home/usr/local/bin/httpd -k start
  1. Введите в строке браузера адрес сервера PowerLinux, на котором запущен процесс httpd. Вы должны увидеть следующую надпись:

It works!

В этом сценарии мы использовали кросс-компилированные библиотеки вместе с библиотеками, скомпилированными в нативной среде. Кросс-компилированные библиотеки были собраны с опцией архитектуры ppc64. Рассмотренный пример доказывает, что на сервере PowerLinux можно совместно использовать кросс-компилированные библиотеки и библиотеки, скомпилированные в нативной среде.

Сценарий 2. Отладка

Во втором сценарии мы попытаемся доказать, что на сервере PowerLinux можно выполнять отладку кросс-компилированных исполняемых файлов. Ниже представлены пошаговые инструкции по выполнению теста.

  1. Подключитесь к процессу httpd с помощью команды gdb. Убедитесь, что используется версия httpd, собранная на сервере x86 при помощи кросс-компилятора из состава toolchain-инструментария.
[root@localhost ~]# gdb attach 25412 
GNU gdb (GDB) 7.6.50.20130722-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "powerpc64-linux". 
…
(gdb)
  1. Задайте в качестве директории инсталляционную директорию.
(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
  1. Перейдите к функции apr_sleep.
(gdb) up 
#1 0x00000fff7cd38274 in apr_sleep (t=<optimized out>) at time/unix/time.c:246
246        select(0, NULL, NULL, NULL, &tv);
  1. Получите листинг исходного кода функции apr_sleep.
(gdb) list
241       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
  1. Отключитесь от процесса.
(gdb) detach 
Detaching from program: /tmp/usr/local/bin/httpd, process 25412
(gdb) quit

Удаленная отладка

В состав toolchain-инструментария также входит программа gdbserver, позволяющая подключаться к приложениям из удаленного gdb-сеанса. При запуске программы gdbserver на сервере PowerLinux убедитесь, что вы запускаете версию программы из состава toolchain-инструментария. В моем случае я убедился, что команда запускается из нужной директории.

# type gdbserver
gdbserver is hashed (/opt/at7.0-5-rc1/bin/gdbserver)

Ниже представлен пример использования программы gdbserver на сервере PowerLinux. Мы подключаемся к запущенному процессу httpd.

[root@stgisv241 bin]# gdbserver --attach 9.3.4.240:2345 22589 
Attached; pid = 22589
Listening on port 2345

Запустите программу powerpc64-linux-gdb на сервере x86, указав исполняемый файл httpd, расположенный на локальном сервере. Заметьте, что версия gdb из состава toolchain-инструментария называется powerpc64-linux-gdb. Используемый исполняемый файл httpd является той же самой кросс-компилированной версией, что и версия, запущенная на сервере PowerLinux.

# 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 <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. 
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details. 
This GDB was configured as "--host=i686-linux --target=powerpc64-linux".
Type "show configuration" for configuration details. 
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
.. 
Reading symbols from /tmp/usr/local/bin/httpd...done. 
(gdb)

Не выходя из сеанса gdb на сервере x86, выполните следующую команду в командной оболочке gdb:

(gdb) target remote 9.3.4.241:2345
Remote debugging using 9.3.4.241:2345
warning: 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.0
Reading symbols from /tmp/usr/local/apr/lib/libexpat.so.0...done.
Loaded symbols for /tmp/usr/local/apr/lib/libexpat.so.0
Reading 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.so
warning: 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)

Обратите внимание на предупреждения о том, что gdb не может найти символы той или иной библиотеки. Команда gdbinfo sharedlibrary выводит список всех библиотек, символы которых не смог прочитать gdb. В следующем листинге показан вывод команды, содержащий список таких библиотек для нашего примера. Заметим, что библиотеки являются частью системы, и если они не были скомпилированы с включенными символами, то беспокоиться о них не нужно.

(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.s
0x00000fffa91f7940 0x00000fffa922aa18 Yes       /tmp/usr/local/apr/lib/libexpat.so.0
0x00000fffa9192e60 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_f
0x00000fffa8ea0c00 0x00000fffa8ea1878 Yes       /tmp/usr/local/modules/mod_authn_file
0x00000fffa8e810a0 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_group
0x00000fffa8e208e0 0x00000fffa8e20f18 Yes       /tmp/usr/local/modules/mod_authz_user.
0x00000fffa8e019e0 0x00000fffa8e046d8 Yes       /tmp/usr/local/modules/mod_authz_core.
...

Как показывает рассмотренный сценарий, отладка (как локальная, так и удаленная) кросс-компилированных приложений, запущенных на сервере PowerLinux, ничем не отличается от отладки приложений, скомпилированных в нативной среде. Также обратите внимание на то, что исполняемые файлы были скомпилированы с опцией –g, позволяющей генерировать отладочную информацию.

Тестовая среда и ее конфигурация

Тестовая среда состоит из системы IBM Flex System® с несколькими вычислительными узлами IBM Flex System x240 и двумя узлами на базе процессора IBM POWER7 (серверы Flex System p260 и Flex System p460). Для кросс-компиляции приложений Apache httpd и PostgreSQL в нашем проекте я использовал один из серверов Flex System x240. После компиляции приложений я перенес их на сервер Flex System p460. Схема тестовой среды изображена на рисунке 7.

Рисунок 7. Тестовая среда IBM Flex System
Рисунок 7. Тестовая среда IBM Flex System
Рисунок 7. Тестовая среда IBM Flex System

Ниже приводятся конфигурация моей тестовой среды, уровни операционной системы и прочая информация о настройках системы.

Узел Flex System x240

Сервер на базе процессора Intel, предназначенный для кросс-компиляции приложений, для успешной компиляции двоичных файлов под архитектуру Power должен иметь достаточно процессорных ресурсов и оперативной памяти. Мой сервер имел следующую конфигурацию:

  • Гипервизор KVM Red Hat 6.5
    • 32 процессора
    • 64 ГБ оперативной памяти
    • Диск, подключенный к SAN-системе хранения IBM Storwize® V7000
  • Гостевая виртуальная машина KVM
    • Red Hat Enterprise Linux 6.5
    • 4 процессора
    • 16 ГБ оперативной памяти
    • Один виртуальный диск объемом 100 ГБ (virtio)
    • Один виртуальный сетевой интерфейс (устройство br0)

Все остальные виртуальные машины KVM были остановлены, чтобы исключить влияние на тестовую среду.

Узел Flex System p440

Узел Flex System p440 состоит из нескольких логических разделов (LPAR), один из которых сконфигурирован в качестве тестового сервера. Сервер PowerLinux имеет следующую конфигурацию:

  • Гостевая виртуальная машина IBM PowerVM®
    • Red Hat Enterprise Linux 6.5
    • 8 выделенных процессоров
    • 32 ГБ оперативной памяти
    • Диск объемом 50 ГБ, подключенный к SAN-системе хранения Storwize V7000
    • Общий сетевой адаптер, подключенный через виртуальный сервер ввода-вывода (VIOS)
  • Конфигурация логического LPAR-раздела
    • Режим работы: Dedicated (выделенный)
      • Минимальное количество процессоров: 8
      • Начальное количество процессоров: 8
      • Максимальное количество процессоров: 32
    • Выделенная оперативная память
      • Минимальный объем: 256 МБ
      • Начальный объем: 32 ГБ
      • Максимальный объем: 64 ГБ
  • Виртуальный Ethernet-адаптер (через VIOS)
    • Идентификатор (ID) адаптера: 2
    • Номер VLAN: 1
    • Опция "This adapter is required for virtual server activation": установлена

Также я выполнил следующие дополнительные команды:

# ppc64_cpu --frequency 
min:    3.56 GHz (cpu 28) 
max:    3.56 GHz (cpu 4) 
avg:    3.56 GHz 
# ppc64_cpu --cores-present Number of cores present = 8
# sysctl.conf kernel.sem = 250     32000   32    12288

Компиляция приложений при помощи toolchain-инструментария

Процесс компиляции Open Source-дистрибутива, как правило, является итерационным. Если вам повезет, то приложение удастся скомпилировать "из коробки". К сожалению, поскольку большинство Open Source-дистрибутивов компилируется на серверах x86, при компиляции их на сервере с другой архитектурой (например, IBM Power) можно столкнуться с проблемами.

Если вы сталкиваетесь с проблемами при компиляции Open Source-пакетов на сервере Power, рекомендуется поискать в Интернете похожие случаи. Если аналогичный случай обнаружится, есть шанс найти советы по решению проблемы.

В моем случае после выбора правильных параметров конфигурационного сценария мне удалось без проблем скомпилировать пакет postgresql, однако при компиляции Apache httpd я столкнулся с определенными трудностями. В следующем разделе я опишу исправления, которые мне потребовалось сделать, чтобы скомпилировать Apache httpd на сервере с архитектурой Power.

Опыт работы с кросс-компилятором

На момент написания этой статьи я использовал внутреннюю версию кросс-компилятора IBM, специально собранную для исправления ошибки, с которой я столкнулся во время тестирования. Читатели могут загрузить версию AT 7.0-5 – последнюю (на момент написания статьи) версию кросс-компилятора, содержащую исправление ошибки, описанной в нескольких следующих абзацах.

При попытке кросс-компиляции пакета apr-1.5.1 я получил следующее сообщение компилятора:

"sorry - this program has been built without plugin support"

Следуя совету поискать возможные решения проблемы в Интернете, я нашел несколько упоминаний того, что компилятор должен быть скомпилирован с опцией "plugin enabled". Я сообщил об этом в группу поддержки toolchain-инструментария, и мне быстро предоставили модифицированную версию, скомпилированную с поддержкой подключаемых модулей. Обратите внимание на то, что эта поддержка должна быть включена как при сборке кросс-компилятора, так и при сборке нативной версии toolchain-инструментария. После получения исправленной версии toolchain-инструментария я смог закончить необходимые действия.

Это был мой первый опыт работы с toolchain-инструментарием PowerLinux.

Кросс-компиляция httpd 2.4.3

Чтобы выполнить кросс-компиляцию http-сервера Apache, понадобятся три дополнительных пакета: apr, apr-util и pcre. Найдите ссылки на загрузку последних версий этих пакетов и загрузите их, после чего скомпилируйте их на сервере x86 с помощью кросс-компилятора toolchain-инструментария.

Во время компиляции пакета apr-1.5.1 я столкнулся с проблемой, касающейся модуля gen_test_char.o. Дополнительную информацию вы найдете по ссылке ASF Bugzilla – Bug 51257 (EN). Я изменил файл Makefile.in, как показано ниже, и запустил сценарий buildconf, чтобы внести эти изменения в конфигурационный сценарий.

В файл Makefile.in были внесены следующие изменения:

[root@stgisv240 apr-1.5.1]# diff -u Makefile.in ../../apr-1.5.1/Makefile.in
--- Makefile.in 2014-03-17 10:10:26.000000000 -0500
+++ ../../apr-1.5.1/Makefile.in 2014-07-03 13:36:11.125013781 -0500
@@ -46,7 +46,6 @@ 
CLEAN_TARGETS = apr-config.out apr.exp exports.c export_vars.c .make.dirs \ build/apr_rules.out tools/gen_test_char@EXEEXT@ \ - tools/gen_test_char.o tools/gen_test_char.lo \ include/private/apr_escape_test_char.h DISTCLEAN_TARGETS = config.cache config.log config.status \ include/apr.h include/arch/unix/apr_private.h \ @@ -132,10 +131,9 @@ make_tools_dir: $(APR_MKDIR) tools
-OBJECTS_gen_test_char = tools/gen_test_char.lo $(LOCAL_LIBS) -tools/gen_test_char.lo: make_tools_dir -tools/gen_test_char@EXEEXT@: $(OBJECTS_gen_test_char) - $(LINK_PROG) $(OBJECTS_gen_test_char) $(ALL_LIBS) +tools/gen_test_char@EXEEXT@: make_tools_dir +tools/gen_test_char@EXEEXT@: tools/gen_test_char.c + $(BUILD_CC) $(CFLAGS_FOR_BUILD) $< -o $@ include/private/apr_escape_test_char.h: tools/gen_test_char@EXEEXT@ $(APR_MKDIR) include/private

После внесения изменений в файл Makefile.in я запустил утилиту buildconf для создания нового конфигурационного сценария. В следующем абзаце я покажу, какие аргументы и переменные я использовал в конфигурационном сценарии. Кстати, эти аргументы я выбрал в соответствии с рекомендациями других разработчиков, которые пытались выполнять кросс-компиляцию Apache httpd и его компонентов на других платформах (например, на платформе ARM).

При запуске конфигурационного сценария для пакета apr-1.5.1 на сервере x86 я использовал следующие аргументы и переменные среды:

# Config script using Power Linux toolchain on x86 
BUILD_CC=gcc
CC_FOR_BUILD=gcc
CC=powerpc64-linux-gcc
CPP=powerpc64-linux-cpp
AS=powerpc64-linux-as
AR=powerpc64-linux-ar 
RANLIB=powerpc64-linux-gcc-ranlib
CXX=powerpc64-linux-c++
LD=powerpc64-linux-ld
STRIP=powerpc64-linux-strip 
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/tmp/usr/local/apr --host=powerpc64-linux ac_cv_file__dev_zero=no ac_cv_func_setpgrp_void=no apr_cv_tcp_nodelay_with_cork=no ac_cv_sizeof_struct_iovec=1
BUILD_CC=gcc make install

Этот же дистрибутив с указанными модификациями я использовал на сервере Power. Обратите внимание, что toolchain-инструментарий PowerLinux для серверов Power использует исполняемые файлы с теми же именами (например, cpp и ld), что и имена "нативных" системных пакетов cpp и binutils. Измените в сценарии переменные CPP и LD, как показано ниже. Убедитесь, что директория с toolchain-инструментарием Power указана в переменной PATH первой.

При запуске конфигурационного сценария для пакета apr-1.5.1 на сервере Power я использовал следующие аргументы и переменные среды:

# Config script using PowerLinux toolchain on Power 
BUILD_CC=gcc
CC_FOR_BUILD=gcc 
CC=powerpc64-linux-gcc 
CPP=cpp                                   # Note the difference
AS=powerpc64-linux-as
AR=powerpc64-linux-ar 
RANLIB=powerpc64-linux-gcc-ranlib 
CXX=powerpc64-linux-c++ 
LD=ld                                     # Note the difference 
STRIP=powerpc64-linux-strip 
#CFLAGS="-mcpu=440fp -mtune=440fp --sysroot $SYSROOT"
#LDFLAGS=-L$SYSROOT/lib
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/home/usr/local/apr ac_cv_file__dev_zero=no ac_cv_func_setpgrp_void=no apr_cv_tcp_nodelay_with_cork=no ac_cv_sizeof_struct_iovec=1 ac_cv_struct_rlimit=yes BUILD_CC=gcc make install

При запуске конфигурационного сценария для пакета apr-util-1.5.3 на сервере x86 я использовал следующие аргументы и переменные среды:

# Configure script for apr-util-1.5.3 on x86 
BUILD_CC=gcc 
CC_FOR_BUILD=gcc
CC=powerpc64-linux-gcc 
CPP=powerpc64-linux-cpp 
AS=powerpc64-linux-as 
AR=powerpc64-linux-ar
RANLIB=powerpc64-linux-gcc-ranlib
CXX=powerpc64-linux-c++ 
LD=powerpc64-linux-ld
STRIP=powerpc64-linux-strip 
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/tmp/usr/local/apr --host=powerpc64-linux --with- apr=/tmp/usr/local/apr ac_cv_file__dev_zero=no ac_cv_func_setpgrp_void=no apr_cv_tcp_nodelay_with_cork=no ac_cv_sizeof_struct_iovec=1

При запуске конфигурационного сценария для пакета apr-util-1.5.3 на сервере Power я использовал следующие аргументы и переменные среды:

# Configure script for apr-util-1.5.3 on Power
BUILD_CC=gcc 
CC_FOR_BUILD=gcc
CC=powerpc64-linux-gcc 
CPP=cpp 
AS=powerpc64-linux-as
AR=powerpc64-linux-ar
RANLIB=powerpc64-linux-gcc-ranlib
CXX=powerpc64-linux-c++
LD=ld 
STRIP=powerpc64-linux-strip 
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/home/usr/local/apr --host=powerpc64-linux --with- apr=/tmp/usr/local/apr ac_cv_file__dev_zero=no ac_cv_func_setpgrp_void=no apr_cv_tcp_nodelay_with_cork=no ac_cv_sizeof_struct_iovec=1

При запуске конфигурационного сценария для пакета httpd на сервере x86 я использовал следующие аргументы и переменные среды:

# Configure script for httpd 2.4.3 on x86 
CC_FOR_BUILD=gcc
CC=powerpc64-linux-gcc 
CPP=powerpc64-linux-cpp 
AS=powerpc64-linux-as 
AR=powerpc64-linux-ar
RANLIB=powerpc64-linux-gcc-ranlib 
CXX=powerpc64-linux-c++ 
LD=powerpc64-linux-ld
STRIP=powerpc64-linux-strip 
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/tmp/usr/local --host=ppc64 ap_cv_void_ptr_lt_long=no --with- pcre=/tmp/usr/local/bin/pcre-config --with-apr=/tmp/usr/local/apr --with-mpm=worker-- with-apr-util=/tmp/usr/local/apr/bin/apu-1-config

При запуске конфигурационного сценария для пакета httpd на сервере Power я использовал следующие аргументы и переменные среды:

# Configure script for httpd 2.4.3 on Power
CC_FOR_BUILD=gcc
CC=powerpc64-linux-gcc
CPP=cpp 
AS=powerpc64-linux-as 
#ASCPP=powerpc-apm-linux-gnu-as
AR=powerpc64-linux-ar 
RANLIB=powerpc64-linux-gcc-ranlib
#CXXCPP=powerpc-apm-linux-gnu-cpp
CXX=powerpc64-linux-c++ 
LD=/opt/at7.0-5-rc1/bin/ld
STRIP=powerpc64-linux-strip
#CFLAGS="-mcpu=440fp -mtune=440fp --sysroot $SYSROOT" 
#LDFLAGS=-L$SYSROOT/lib
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/home/usr/local --host=ppc64 ap_cv_void_ptr_lt_long=no--with- pcre=/home/usr/local/bin/pcre-config --with-apr=/home/usr/local/apr --with-mpm=worker-- with-apr-util=/home/usr/local/apr/bin/apu-1-config

Кросс-компиляция PostgreSQL 9.4.3

В отличие от предыдущего случая, при кросс-компиляции PostgreSQL не возникло никаких проблем. СУБД PostgreSQL был скомпилирована "как есть" с использованием следующего конфигурационного сценария.

При запуске конфигурационного сценария для PostgresSQL на сервере x86 я использовал следующие аргументы и переменные среды:

# Configure script for postgresql-9.3.4 on x86 
CC=powerpc64-linux-gcc
CPP=powerpc64-linux-cpp 
AS=powerpc64-linux-as
AR=powerpc64-linux-ar
RANLIB=powerpc64-linux-gcc-ranlib
CXX=powerpc64-linux-c++ 
D=powerpc64-linux-ld
STRIP=powerpc64-linux-strip 
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/tmp/usr/local --host=powerpc64-linux --without-readline --without-zlib

Как и в случае с Apache, инструментарий PowerLinux toolchain for the Power server использует исполняемые файлы с теми же именами (например, cpp и ld), что и имена "нативных" системных пакетов cpp и binutils. Измените в сценарии переменные CPP и LD, как показано ниже. Убедитесь, что директория с toolchain-инструментарием Power указана в переменной PATH первой.

При запуске конфигурационного сценария для PostgresSQL на сервере Power я использовал следующие аргументы и переменные среды:

# Configure script for postgresql-9.3.4 on Power
CC=powerpc64-linux-gcc
CPP=cpp 
AS=powerpc64-linux-as 
AR=powerpc64-linux-ar
RANLIB=powerpc64-linux-gcc-ranlib
CXX=powerpc64-linux-c++
LD=powerpc64-linux-ld 
STRIP=powerpc64-linux-strip 
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/home/usr/local --host=powerpc64-linux --without-readline --without-zlib

Заключение

Главное достоинство кросс-компилятора заключается в том, что разработчики могут создавать приложения для архитектуры Power, работая в своей привычной среде. Чаще всего этой средой является платформа x86. Примеры, рассмотренные в этой статье, показывают, что toolchain-инструментарий позволяет создавать двоичные исполняемые файлы и библиотеки, которые работают так же хорошо, как и приложения, скомпилированные в нативной среде. Кроме того, можно выполнять отладку кросс-компилированных приложений встроенными средствами – как локально, так и удаленно при помощи отладчика gdb.

Использование toolchain-инструментария для PowerLinux ничем не отличается от использования нативного toolchain-инструментария для Linux на платформе x86. Я надеюсь, эта статья позволила читателям лучше понять возможности toolchain-инструментария для PowerLinux.

Ресурсы

Благодарности

Я хотел бы поблагодарить за поддержку при написании этой статьи сотрудников IBM Тулио Фильо (Tulio Filho), Стива Манро (Steve Munroe) и Стива Прэтта (Steve Pratt).


Ресурсы для скачивания


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux
ArticleID=1003380
ArticleTitle=Компиляция приложений для IBM PowerLinux на серверах Intel x86
publish-date=04142015