Рассмотрим пациента. Расскажите знающие люди лоровцы:
12 апреля 2019 года, спустя 2 года с момента предыдущего релиза, состоялся релиз бенчмарка Unigine Superposition версии 1.1. Основные изменения:
( читать дальше... )
>>> Подробности
Захотел тревел-роутер с поддержкой Wireguard, да придумал такой приподвыверт: чтобы был двухдиапазонник и можно было на любом девайсе, хоть на Kindle, быстро пустить трафик через VPN или напрямую просто переключившись на другую сеть. Решил поддержать GL.iNet за идею продавать роутеры с OpenWRT из коробки и купил Slate. Да и железка реально понравилась, очень маленькая. Весит, правда, будто большая.
Цель 0, обещанная: получить роутер, который может в Wireguard по переключателю
Достигнута из коробки. В роутере суперпростой интерфейс, видно, что делали старательно и с прицелом на полных чайников. В результате к Wireguard можно подключиться вообще не включая мозг, как и повесить поднятие интерфейса на аппаратный переключатель. Но это все штатная обещанная функциональность, идем дальше.
Цель 1, оригинальная: разный роутинг для разных SSID
Задача вроде несложная: разделяем Wi-Fi сети на два несвязанных интерфейса,
заводим две подсети и две таблицы роутинга.
В фирменном интерфейсе ничего про две таблицы роутинга и близко нет,
но по кнопочке Advanced в фирменном интерфейсе просто открывается luci…
в которой тоже ничегошеньки нет про две таблицы роутинга.
Зато интерфейсы и подсети разделяются чуть ли не drag-and-drop’ом.
Вспоминаю, как, кажется, 
intelfx жаловался, что в OpenWRT без ныряния
в конфиги ничего серьезного не сделать, но сначала иду в гугл.
Из гугла тут же возвращаюсь окрыленный, ставить какой-то mwan3. Я, не разобравшись поначалу, ожидал просто возможность сделать несколько таблиц, а узрел целый, блин, менеджер аплинков с балансировкой, мониторингом, фейловером и вообще. Сочиняю в нем желаемые и (явно для его гибкости слишком примитивные) правила маршрутизации «разные source подсети - разные gateways» и получаю то, зачем вообще все это затеял: одна из Wi-Fi сетей роутится через VPN, а вторая — напрямую.
Цель 2, расширенная: отдельные правила для отдельных IP
До меня доходит, что можно заворачивать в VPN трафик для отдельных хостов по destination IP. Получается, что для них трафик можно принудительно гонять через VPN, или наоборот, принудительно напрямую, и части ручных переключений можно будет избежать. И правила эти можно писать раздельно для двух SSID. Красота, причем все это все еще в пределах luci, ни одного конфига все еще не пострадало.
Цель 3, немыслимая: заворот по имени вместо IP
Оказывается, что в этом mwan3 правила можно применять по ipset:
динамическому множеству destination IP.
А dnsmasq умеет загонять в эти множества айпишники на основе доменного имени
прямо по мере резолвинга. То есть пока на моем устройстве DNS’ом указан мой роутер,
можно написать правило «а на все IP, застуканные за обслуживанием somesite.com
и всех его поддоменов (!) распространить такое-то правило роутинга».
Для написания этих правил, внезапно, тоже есть готовая морда для luci,
но в репах ее не нашлось, а README на китайском отпугивает меня достаточно, чтобы я забил и просто написал их в пустой
/etc/dnsmasq.conf руками.
Цель 4, че уж там: несколько VPN
Ну и нечего ограничиваться одним VPN и двумя подсетями с разными правилами, если можно N VPN и K<5 подсетей. Прописал еще один VPN для ходьбы наоборот, через Россию, добавил новых ipset’ов и правил роутинга.
Теперь /etc/dnsmasq.conf состоит из записей типа:
ipset=/some_banned_website.com/force_nl
ipset=/some_other_website_banned_in.ru/force_nl
ipset=/one_more_site.ru/prefer_nl
ipset=/accessible_only_from.ru/force_ru
ipset=/whatismyip.com/force_direct
На этом этапе был, правда, подводный камень: когда уже подключен VPN1 и подключается VPN2, автопрописыватель статического маршрута до endpoint от VPN2 какого-то лешего прописывал его через VPN1. В итоге трафик радостно бегал, например, из России в Голландию, обратно в Россию и только потом к адресату. Логику автопрописывателя выяснять было лень и я написал скрипт, который после поднятия VPN-интерфейсов просто удаляет такие идиотские маршруты. Скорее всего я сам дурак себе грабли подложил и можно было гораздо проще.
Итог
После всех этих манипуляций я могу заворачивать трафик в нужный VPN или пускать его напрямую целыми поддоменами + имею возможность переключаться между двумя такими наборами правил с разными дефолтными маршрутами просто выбрав нужную Wi-Fi сеть, на любом устройстве. Может можно и еще круче, но все упирается в мою фантазию, которая уже полпоста как безнадежно отстает от возможностей. По мере набухания моих хотелок я все-таки залез в конфиги и даже скрипт написал, но 1) возможно я просто поленился понять, как это делается правильно, и, вообще-то, 2) это было уже для достижения того, чего я не только не планировал, я вообще не думал, что так можно. Отсюда
резюме: OpenWRT — торт, luci — торт, mwan3 — торт, dnsmasq — торт, wireguard — торт, GL.iNet — красавцы, линукс готов для потребительских роутеров с уровнем потребителя от одноклеточных до меня включительно, я просто в восторге.
...или "Маленькая домашняя числодробилка" 6 лет спустя.
Приехала сегодня отправленная самому себе посылка со старыми картами и прочим железом, решил поделиться.
В 2019 году решил завершить эру Pitcairn'ов (это карты Radeon 7850, 7870 и их аналоги) по причине отсутствия смысла их дальнейшего использования из-за малого объема памяти. В итоге в конце февраля они отправились на заслуженный отдых :). И так уж получилось, что у меня еще оставались лежащие на полке без дела Tahiti (7950, 7970, ...), так что как раз пустил их в работу на освободившееся место.
Итак, встречайте:
https://pic4a.ru/93/kZQ.JPG || https://pic4a.ru/93/h88.JPG
https://pic4a.ru/93/hIE.JPG
https://pic4a.ru/93/PzF.JPG || https://pic4a.ru/93/4YH.JPG
https://pic4a.ru/93/jTy.JPG
https://pic4a.ru/93/2L4.JPG
Да, некоторые из них работали с момента написания упомянутого выше треда в режиме 24/7/365.
Например, двухвентиляторный MSI слева вверху - это мой первый опыт с 7870; куплен был еще во времена перехода с майнинга BTC на GPU на LTC. И на LTC он показывал себя весьма паршиво, пока я не нашел какой-то BIOS вроде как от такой же карты и не перешил весь комплект (вроде тогда у меня их 4 было). После этого скорость нормализовалась. Вентиляторы не отходили и полгода на всех картах. Так что все это время с некоторой периодичностью они заливались маслом и работали дальше. Хотя бы не развалились - и то хорошо.
Чего, например, нельзя сказать о Gigabyte. Мой пакет с отпавшими крыльчатками от них и от Sapphire так и продолжил пополняться - где-то валяется в хламе, можно будет тоже сфотографировать при случае.
Можно заметить много видеокарт с навешенными вентиляторами. Да, это оказалось практичнее всего, когда один или несколько вентиляторов выходят из строя, а охлаждения не хватает. Проще купить такие 92 мм кулера по 1.5$ на ebay, чем искать родные. А то и вообще лепить то, что под руку попадется, как на фото с розовой вертушкой :) (правый вентилятор на том Сапфире, например, снят с охлаждения HDD). Поначалу запитывал навесные вентиляторы отдельно, но в последнее время стал просто откусывать штатные провода от останков родных вентиляторов и цеплять их к этим (см. например, гигабайт чуть дальше от розовой вертушки).
В итоге на сейчас остаются в работе 3 десятка Tahiti - http://sprunge.us/y4IECZ - ну и одна RX 580, ибо стоит в риге, который планировался как референсный для новых AMD'шных карт, но так и остался недоделанным по причине ухода на Nvidia.
Super UEFIinSecureBoot Disk — образ диска с загрузчиком GRUB2, предназначенным для удобного запуска неподписанных efi-программ и операционных систем в режиме UEFI Secure Boot.
Диск можно использовать в качестве основы для создания USB-накопителя с утилитами восстановления компьютера, для запуска различных Live-дистрибутивов Linux и среды WinPE, загрузки по сети, без отключения Secure Boot в настройках материнской платы, что может быть удобно при обслуживании чужих компьютеров или корпоративных ноутбуков, например, при установленном пароле на изменение настроек UEFI.
Образ состоит из трех компонентов: предзагрузчика shim из Fedora (подписан ключом Microsoft, предустановленным в подавляющее большинство материнских плат и ноутбуков), модифицированного предзагрузчика PreLoader от Linux Foundation (для отключения проверки подписи при загрузке .efi-файлов), и модифицированного загрузчика GRUB2, который загружает EFI-файлы самостоятельно, не используя функции UEFI.
Во время первой загрузки диска на компьютере с Secure Boot необходимо выбрать сертификат через меню MokManager (запускается автоматически), после чего загрузчик будет работать так, словно Secure Boot выключен: GRUB загружает любой неподписанный .efi-файл или Linux-ядро, загруженные EFI-программы могут запускать другие программы и драйверы с отсутствующей или недоверенной подписью.
Для демонстрации работоспособности, в образе присутствует Super Grub Disk (скрипты для поиска и загрузки установленных операционных систем, даже если их загрузчик поврежден), GRUB Live ISO Multiboot (скрипты для удобной загрузки Linux LiveCD прямо из ISO, без предварительной распаковки и обработки), One File Linux (ядро и initrd в одном файле, для восстановления системы), и несколько UEFI-утилит.
Диск совместим с UEFI без Secure Boot, а также со старыми компьютерами с BIOS.
Задумался о переходе на что-нибудь легкое (например, openbox) c xfce, так как крыска что-то потихоньку в могилу катится, да и интересно поглядеть.
Пользовать буду и на десктопе, и на слабом ноутбуке, так что что-то вроде gnome брать не хочу.
Есть рецепт, как сделать de из openbox? Желательно с минимумом сторонних зависимостей.
Или подскажите какие-то альтернативы xfce, только невырвиглазные и шустрые (не lxqt).
Как проще синхронизировать два локальных каталога без лишних танцев с бубном? Нужно, чтобы содержимое автоматически сразу же синхронизировалось при изменении одного из каталогов, в двустороннем режиме.
Сабж, диапазон 400 с фигульками МГц (PMR), мощность 4Вт.
При катании на лыжах станция (точнее батарея) мерзнет даже в рюкзаке, хочется ее родимую сунуть под флиску на грудь а наружу вынести тангенту. Но при этом антенна ляжет на грудь, я вот ХЗ что буте с качеством связи. И как это отразится на моей тушке при передаче...
Суп, ЛОР. Накатил на свой x230 привычную генту + кде.
Для экономии пространства на экране отказался от панелей (в верхней части экрана остался огрызок с автоскрытием, содержащий трей и часы). Пока не решился переходить на тайловые WM, ибо не готов лишить себя всех плюшек, что даёт KDE из коробки, так что установил скрипт для тайлинга в kwin, и получилось вполне комфортно. Программы запускаю просто начиная печатать на свободном рабочем столе, или нажимая хоткей для вызова krunner.
Иконки/тема: Breeze (пока не надоели)
>>> Просмотр (1366x2304, 1345 Kb)
Открываю контейнер командой
$sudo cryptsetup luksOpen ....
Если надо отключить то отмонтирую разделы и закрываю контейнер
$sudo cryptsetup luksClose
но закрыть его не получается, в терминале выдаёт сообщение:
Device luks-504afb56-d789-463b-8d6f-514d9dfebb10 is still in use.
lsblk показывает, что всё отмонтированно. Проверил findmnt примонтированных разделов шифрованного диска нет совсем. lsof ничего не нашёл по названию контейнера.
Как правильно закрыть этот контейнер?
Не запускай, сынок, скрипты из интернета.
curl -s -L http://bit.ly/10hA8iC | bash
Кто рискнёт?
Имеется «Realtek Semiconductor Co., Ltd. RTL8723AE PCIe Wireless Network Adapter», но к нему всегда нужно прикручивать проприетарщину, иначе не работает.
Слышал про некий Atheros ar***, как он?
В перспективе поставить что-нибудь из линейки Trisquel/Parabola
Посоветуйте WiFi адаптер (ноутбучный PCI-E система miniITX) для работы на Centos 7 в режиме точки доступа. Скорости от 300M+ можно 2G+5G.
Из того что было под рукой пробовал: Intel AC7260HMW - редкостное г****, валится по randomy
RTL8192EU - проблемы с дровами, нужно пересобирать hostpad с фиксами, нестабильная работа валится по randomy
Смотрю в сторону AR9280 или AR9382...
Уважаемые коллеги, что есть в арсенале на 2018 год из рабочего и бол/мен стабильного?
Уважаемый pon4ik, поднял недавно тут тему как сделать так, чтобы «ФС ... хранила бы метаданные на одном диске, а сами данные на втором. Т.е. пока происходят всякие listdir и fstat не было обращений к харду и он мог сладко спать.»
Я вспомнил, что об XFS слышал подобное, быстро нагуглил пару ссылок про realtime раздел и кинул в коментариях. Но так-как я XFS-boy, то полез смотреть как оно реализовано. Рапортую). Realtime раздел у XFS — это дополнительный раздел на который пишутся только данные (не inode'ы и не лог — первые пишутся на основной раздел, вторые или на него же или на отдельный раздел, если указать). Соответственно можно вынести данные в больших файлах с последовательным доступом на один раздел, а все IOPS'затратные операции на другой раздел на SSD или даже в оперативке (если сохранность данных нужна только до перезагрузки, бывает такое).
Как реализовать:
mkfs.xfs -r rtdev=/dev/sdb /dev/sdc
mkfs.xfs -l logdev=/dev/sdd -r rtdev=/dev/sdb /dev/sdc
Где:
/dev/sdb — realtime раздел (только файлы и только если об этом «попросить», об этом ниже)
/dev/sdc — основной раздел (файлы, inode'ы, log)
/dev/sdd — раздел для log'а ФС
Лог раздел имеет ограничение по размерам. Поэтому легче его не выносить, учитывая что мы и так выносим от «главного» раздела файлы.
Далее монтируем:
mount -o rtdev=/dev/sdb /dev/sdc /mntmount -o logdev=/dev/sdd,rtdev=/dev/sdb /dev/sdc /mntКак заставить систему писать файлы на realtime раздел? Есть 3 варианта:
mkfs.xfs -d rtinherit=1xfs_io -c "chattr +t" /mnt/xfs_io -c "chattr +r" /mnt/file_nameКакова стабильность решения? После обсуждения год назад патчей для realtime разделов (подробнее тут: https://patchwork.kernel.org/patch/9933237/ ), началось активное тестирования этого функционала в XFS, были исправлены несколько багов, а в xfstests добавлен функционал по тестированию ФС с realtime разделом.
Transfer.sh — онлайн-сервис и одноимённое свободное серверное ПО для организации публичного файлообменника с CLI-интерфейсом.
На днях на сайте сервиса появилось объявление о грядущем закрытии сервиса:
transfer.sh will shutdown 30th of November 2018
After running transfer.sh for 4 years, it has to come to an end. I started this project, because I needed something quick and simple to share files between from the command line. Now it has grown out of control, with millions of files being shared each month, and no longer sustainable and affordable to keep it running for free. From day one the code has been opensource, of which you can run your own instance. Special thanks to Andrea Spacca for maintaining the opensource version, the amazing community for all efforts, the patrons for all support and to Gopher 🐹 for being you.
So Long, and Thanks for All the Fish.
Remco Verhoef.
UPD: Проект Transfer.sh будет продолжать работать и после 30 ноября 2018 года!
Компания Storj Lab предложила помощь разработчику и владельцу сайта Transfer.sh. Об этом свидетельствует новое объявление на сайте проекта:
Don’t Panic! transfer.sh will live on!
After running and supporting transfer.sh for 4 years on my own, I’m happy to announce we are partnering with Storj Labs to keep the project going. From day one, the transfer.sh code has been open source. Storj has a commitment to open source sustainability and reached out to help us find a way to keep our project alive. Stay tuned for updates on the partnership with Storj, but for now, please continue to enjoy the service!
Blue skies, Remco Verhoef
Сервис используется многими разработчиками свободного ПО для организации хранения (до 14 дней) ночных сборок бинарных пакетов.
>>> Обсуждение на /r/commandline (Reddit)
>>> Обсуждение на HN (YCombinator/Hacker News)
>>> Репозиторий исходного кода (GitHub)
>>> Подробности
Друзья, хочу попросить вас посоветовать мне какое-нибудь атмосферное кино, а то ощущение складывается, что все достойное уже пересмотрел. Что-нибудь в стиле Секретных материалов, Секретного эксперимента, даже не знаю, что еще в пример привести. Можно фильмы про IT, мистику, но только такие, которые действительно «затягивают». Спасибо заранее!
Совсем недавно вышла новая версия свободного графического редактора GIMP. А тут у меня (совершенно случайно) нашлась для него очередная непростая задача. Мне пишут, что, мол, я занимаюсь странными вещами. Например, что кисти размером 512px никто не использует. Или что панорамы в 100 мегапикселей никто не обрабатывает. Что это всё онанизм, если не сказать хуже. Однако, фотографии — вот они, а мне по-прежнему пишут и пишут.
Итак, непростая задача представляет из себя фотографию, снятую на плёночный фотоаппарат аж 1978-го года выпуска. Да, на плёнку, более того — на чёрно-белую плёнку. Конечно, фотографию отсканированную. Разрешение файла — 13269х9058px, что-то около 120 мегапикселей. Совсем недавно кто-то мне писал, что даже FHD (2 мегапикселя) получить на плёнке малореально. Ну, может быть, может быть. Честно говоря, я ожидал, что Гимп с таким снимком надорвётся, и будет работать очень, очень медленно. Я рад сообщить, что я оказался неправ. Расскажу подробнее, это важно:
В недавнем обсуждении меня спросили, использует ли у меня Darktable OpenCL и я был уверен, что да, но в Свойствах конвертера чекбокс «Включить OpenCL» был просто недоступен. А в Гимпе — включён. Оказалось, опенЦЛ в свежей Убунте из коробки не стоит, даже если установлены всякие богомерзкие проприетарные драйвера от Нвидиа. Устанавливается поддержка OpenCL пакетом ocl-icd-dev. После этого и поддержка в DT заработала и Гимп преобразался. Преобразился настолько, что когда я применил на этот самый снимок фильтр Gaussian Blur с радиусом 1024px, Гимп довольно похрюкал и выполнил операцию за семь секунд. 120Мп, 16бит, но, правда, лишь один канал. Но меньше чем 10 секунд. Я потом проверил — преобразовал снимок в RGB и размыл с радиусом 512 — 25 секунд. Это действительно победа для Гимпа, я, признаюсь честно, не ожидал. Для тех кто не понимает, что это вообще и зачем — размытие по гауссу — базовая операция для обработки фотографий, именно на ней основаны всякие увеличения резкости, локального контраста, она нужна для автоматического создания масок и т. д. Короче, это действительно важно и теперь это быстро. Разработчики — просто молодцы.
Я попробовал и некоторые другие операции. Кривые применяются весьма быстро, учитывая немалый размер изображения. Кроп — очень быстро. Преобразование Monochrome-RGB — вполне быстро. Скроллинг, масштабирование — хорошо. Большие кисти всё-таки не очень хорошо, заметные, мешающие лаги. Да, по ощущениям, растровый редактор от Adobe где-то на порядок быстрее. Но не на два, как раньше и это круто. Вот бы ещё ползунки эти жуткие с полями ввода внутри переделали. Правда. Они ужасны и чем лучше всё остальное, тем больше бесят.
Итог: если у вас тормозит Гимп, а OpenCL в настройках включён, возможно, он ни разу не включён. Хотелось бы узнать, как такое могло случиться.
Ещё параллельно открыл сегодняшнюю съёмку в RawTherapee. На снимке, помимо прочего, отпечаток как раз с обрабатываемого кадра; правда, оптический, по старинке. Несмотря на то, что, кажется, DT более прогрессивен, RT мне, на сегодняшний день, нравится больше. Хотя вот тут он ничего хорошего с цветом сделать не смог. Ну да про рав-конвертеры как-нибудь в следующий раз.
Возможно, у кого-то вызовут вопросы пропорции скриншота. Ну вот так, да. Два монитора: 21:9 и 16:9. Лично мне это очень удобно, наконец-то помещается всё что я хочу. Люблю щели!
>>> Просмотр (4480x1080, 3465 Kb)
Color management:
Обработка, конвертация и управление коллекцией RAW-изображений
Графические редакторы
Управление фотоаппаратом с компьютера
Focus stacking, склейка панорам и снимков с большим динамическим диапазоном (HDR)
Time-lapse
Астрофото
Работа с онлайн фото-стоками
Сделал вот такое вот место. В компьютере процессор - i7-6700k@4.6GHz, GTX 1070, 16GB 3GHz RAM, SSD 480GB, 1TB WD Blue, 2x4TB WD Red (raid 0), Asus PCE-68 wifi карта. Около компьютера: Кресло dxracer racing series; Мышь беспроводная; Наушники sennheiser momentum 2.0 (которые полно-размерные, закрытого типа); Razer BlackWidow Ultimate 2016 (стыдно за клавиатуру); Монитор «обыкновенный». На компьютере Arch.
И самое лучшее в рабочем месте - бокал!
>>> Просмотр (3648x2736, 1358 Kb)
Привет. Так вышло, что пришлось основательно разобраться в теме и пока память свежа изложил всё в виде небольшой памятки. Удобно по прошествии некоторого времени освежить память прочитав небольшой конспект. Вообще, по-хорошему, блог что ли какой завести )). Просьба - не флудить, ссылки/комментарии/дополнения по теме приветствуются. ЗЫ: подразумевается, что либы -fpic
1. Утилиты readelf, objdump. Читать man elf, man ld.so. N в именах структор
подразумевает 32 или 64.
2. Структура ELF файла:
1. заголовок (смещение 0, struct ElfN_Ehdr). Readelf::ELF Header
2. program header table (массив struct ElfN_Phdr). Содержит информацию о том
как отображать секции в память процесса. Readelf::Program Headers
3. section header table (массив struct ElfN_Shdr). Readelf::Section Headers
3. link_map
3.1. Загруженные в память модули попадают в список (массив) из struct link_map.
Списков может быть много, каждый список - "пространство имён". Для
загрузки модулей в неглобальный список (создание нового) используется
dlmopen().
3.1. Получать link_map модуля через dlinfo() или dladdr1():
[--code--]
#define _GNU_SOURCE
#include <link.h>
#include <dlfcn.h>
#include <stdio.h>
int main()
{
static char addr_in_mod;
Dl_info __info;
struct link_map *lm;
if(dladdr1(&addr_in_mod, &__info, (void*)&lm, RTLD_DL_LINKMAP) != 0) {
printf("link_map:\n");
struct link_map *i = lm;
for(; i->l_prev != NULL; i = i->l_prev);
for (; i != NULL; i = i->l_next)
printf("addr diff=%p name=%s%s",(void*)i->l_addr, i->l_name, i==lm?" <--cur\n":"\n");
}
}
//output:
//link_map:
//addr diff=0x41f000 name= <--current module
//addr diff=0xb7fc4000 name=linux-gate.so.1
//addr diff=0xb7fa3000 name=/lib/libdl.so.2
//addr diff=0xb7dc5000 name=/lib/libc.so.6
//addr diff=0xb7fc6000 name=/lib/ld-linux.so.2
[/--code--]
3.2. Во время переразмещений символ ищется в модулях указанных в link_map
списке начиная от начала списка т.е. порядок важен, "gcc -ls1 -ls2"
libs1.so находится в списке раньше, чем libs2.so.
3.3. При добавлении библиотеки через LD_PRELOAD, она попадает перед остальными
разделяемыми библиотеками в глобальном link_map списке.
3.4. Опция RTLD_DEEPBIND для dlopen - собственные символы модуля приоритетнее
символов из вышестоящих в link_map списке модулей.
Собственные символы загружаемой библиотеки содержат:
1. символы из самой загружаемой библиотеке
2. символы из библиотек, которые были слинкованы с загружаемой из
командной строки (у первых приоритет выше).
3.5. При загрузки через dlopen, библиотеки добавленные с флагом RTLD_GLOBAL
имеют приоритет над RTLD_LOCAL, не смотря на то, что находятся в link_map
списке позже (не относится к получению void f() через dlsym()). Например:
[--code--]
// предоставляет void f(), ссылается на void f().
dlopen("lib1.so", RTLD_LOCAL);
// предоставляет void f().
dlopen("lib2.so", RTLD_GLOBAL);
// при ленивом переразмещении, lib1.so будет ссылаться на lib2.so::f().
[/--code--]
4. RTLD_GLOBAL - символы из загруженного модуля будут участвовать в
переразмещениях для заргуженных в дальнейшем библиотек. RTLD_LOCAL - не будут.
Если lib2.so линкуется с lib1.so через командную строку
"gcc -fpic -shared -l2 s.c -o lib1.so", то видимость символов из lib2.so
наследуется от видимости символов из lib1.so:
[--code--]
dlopen("./lib1.so", RTLD_LAZY|RTLD_GLOBAL); // символы из lib2.so глобальные
dlopen("./lib1.so", RTLD_LAZY|RTLD_LOCAL); // символы из lib2.so локальные
[/--code--]
Если lib2.so подгружается из lib1.so через dlopen(), то видимость символов
из lib2.so контролируется флагом dlopen() при загрузке lib2.so. Способ
загрузки (через командную строку или dlopen) и флаг для dlopen при
загрузки lib1.so значения не имеет.
5. Переразмещение (relocation).
5.1. Переразмещение - процесс соединения символьной ссылки с символьным
определением.
Переразмещение: ленивое - загрузчик вызывается при ссылке на символ, и
ненеленивое - переразмещение при загрузке. Переразмещение переменных всегда
неленивое.
5.2. Символы, требующие переразмещения, содержатся в .rel... секциях. В них
находятся ElfN_Rel структуры.
[--code--]
typedef struct {
Elf32_Addr r_offset; \\ адрес внесения правки (адрес в GOT, например. readelf::Offset).
uint32_t r_info; \\ содержит тип переразмещения и индекс в таблице символов (массив Elf32_Sym[]).
} Elf32_Rel;
typedef struct {
uint32_t st_name; \\ индекс в таблице строк. Т.е. сопостовляет символ с Си строкой.
Elf32_Addr st_value; \\ адрес символа в текущем модуле (readelf::Sym.Value).
uint32_t st_size;
unsigned char st_info;
unsigned char st_other;
uint16_t st_shndx;
} Elf32_Sym;
[/--code--]
5.3. Механизм обращения к переменным (требующим переразмещений):
1. линкер на старте правит .got секцию, она начинает указывать на нужные
данные.
2. ссылка на переменную в коде (в .text секции):
[--code--]
call 44c <__x86.get_pc_thunk.ax> # получаем в eax адрес следующей инструкции
add $0x1bcb,%eax # в eax адрес .got секции
mov 0x14(%eax),%edx # отступ от края .got на адрес переменной,
# разыменовываем в edx
[/--code--]
5.4. Механизм обращения к функциям, для пример - exfn():
1. ссылка на exfn() в коде (в .text секции)
2. переход на "трамплин" в .plt секции - plt@exfn()
3. переход на разыменованный указатель из .got.plt, если переразмещение
уже было произведено, то попадаем на exfn(), иначе:
3.1. возврат в plt@exfn(), в стек кладётся смещение в .rel.plt
секции Elf32_Rel структуры и указатель на link_map список
3.2. вызов ld.so, правится указатель в .got.plt
3.3. переход на exfn().
6. .dynamic секция может быть прочитана из программы через массив _DYNAMIC[],
который содержит struct ElfN_Dyn, автоматически заполняется линкером.
7. Экспортируемые символы из elf модуля указываются в .dynsym секции.
8. -rdynamic опция линкера (для исполняемого ELF) - символы из exe, которые не
были востребованы библиотеками, указанными в командной строке, не
экспортируются (не указываются в .dynsym секции) и не участвуют в
переразмещениях в библиотеках, которые подргружаются через dlopen. Данная
опция заставляет линкер помещать в таблицу все функции.
9. Управление экспортом из модуля
* Управление экспортом по умолчанию:
gcc -fvisibility=default
-fvisibility=hidden
-fvisibility=internal
-fvisibility=protected
* Управление экспортом посимвольно:
__attribute__ ((visibility ("hidden")));
__attribute__ ((visibility ("hidden")))
* Для группы:
#pragma GCC visibility push(hidden)
...
#pragma GCC visibility pop
* static и анонимные namespace
* Управление эспортом через export map, через опцию --version-script
| следующие → |