Оптимизация поиска слабых символов
Если вы когда-либо пытались использовать нм Утилита для любой программы на C ++, вы, вероятно, заметили, что многие символы обозначены как «V» или «W». Оба разные виды слабый символы.
Теперь иметь тонны слабых символов в исполняемом файле — это плохо, так как во время выполнения динамический компоновщик будет пытаться разрешить их все. Я думал, что можно было бы сэкономить много времени, применяя простое соглашение при связывании исполняемых файлов:
- Всякий раз, когда в исполняемом файле будет создан слабый символ, если такой символ имеет значение по умолчанию, преобразуйте его в обычный символ.
Этот взлом кажется мне безопасным, так как:
- Если какая-либо библиотека определяет слабый символ с тем же именем, он будет переопределен продвигаемым, и это хорошо, так как для слабых символов мы можем выбрать любое определение
- Если никакая библиотека на самом деле не определяет такой символ … ничего особенного не происходит
- Если библиотеки определяют слабые символы, которые не определены в исполняемом файле, все работает как обычно.
Прежде чем я попытаюсь обсудить это с разработчиками binutils, я упускаю огромную ошибку?
Решение
Я не вижу ничего, что могло бы помешать тому, что вы описываете, работать.
Однако мне интересно, стоит ли это вообще делать. И я вполне уверен, что это то, что ваши «разработчики binutils» также удивятся.
Поэтому я предлагаю вам взглянуть на несколько вещей: как часто в типичном случае один и тот же символ определяется в исполняемом файле и в динамической библиотеке?
Поскольку, скорее всего, останется большое количество слабых символов, которые не определены в исполняемом файле, сколько времени вы реально сэкономите?
Некоторые примеры существующих программ, которые были улучшены, или, по крайней мере, ответ на вопрос: «Для приложения X в среднем столько времени тратится на поиск слабого символа, и это потенциальный выигрыш?»
Это то, что я искал бы как разработчик binutils [я не один из них, но если бы я был].
Другие решения
Других решений пока нет …