Оптимизация поиска слабых символов

Если вы когда-либо пытались использовать утилиту nm в какой-либо программе на C++, вы, вероятно, заметили, что многие символы идентифицируются как «V» или «W». Оба являются разными типами слабых символов.

Теперь иметь тонны слабых символов в исполняемом файле плохо, так как во время выполнения динамический компоновщик попытается разрешить их все. Я подумал, что можно было бы сэкономить много времени, применяя простое соглашение при связывании исполняемых файлов:

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

Этот хак мне кажется безопасным, так как:

  • Если какая-либо библиотека определяет слабый символ с тем же именем, он будет переопределен продвинутым, и это нормально, поскольку для слабых символов мы можем выбрать любое определение.
  • Если ни одна библиотека на самом деле не определяет такой символ... ничего особенного не происходит
  • Если библиотеки определяют слабые символы, которые не определены в исполняемом файле, все работает как обычно.

Прежде чем я попытаюсь обсудить это с разработчиками binutils, есть ли огромная ошибка, которую я упускаю?


gcc c++ linux llvm binutils
person alexp    schedule 03.03.2013    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я не вижу ничего, что могло бы помешать тому, что вы описываете, работать.

Однако я задаюсь вопросом, стоит ли это делать вообще. И я почти уверен, что ваши «разработчики binutils» тоже задались бы этим вопросом.

Поэтому я предлагаю вам обратить внимание на несколько вещей: как часто в типичном случае один и тот же символ определяется в исполняемом файле и в динамической библиотеке?

Поскольку, скорее всего, останется большое количество слабых символов, не определенных в исполняемом файле, сколько времени вы на самом деле сэкономите?

Некоторые примеры существующих программ, которые были улучшены, или, по крайней мере, ответ на вопрос «Для приложения X столько времени в среднем тратится на поиск слабого символа, и это потенциальная выгода?»

Это то, что я искал бы как разработчик binutils [я не один из них, но если бы я был им].

person Mats Petersson    schedule 04.03.2013
comment
На самом деле, я хочу сказать, что в типичном крупномасштабном приложении C++ (я начал свое исследование с изучения производительности компилятора clang) большое количество слабых символов исходит из самого исполняемого файла. Преимущество продвижения символов из исполняемого файла состоит в том, что их не будут искать, но они по-прежнему смогут переопределять в конечном итоге слабые символы в связанных библиотеках, как того требует правило C++ ODR. - person alexp; 04.03.2013
comment
Да, и я хочу сказать, что вам нужно показать, что это стоит делать - количество ссылок на слабые символы и экономия времени должны быть достаточно большими, чтобы это имело заметное значение. Я не смотрел на это, но я подозреваю, что часть поиска не такая уж большая часть процесса загрузки, что дает огромную экономию - но я не вникал в детали, я просто предлагаю, что если вы хотите сделать это, вы были бы готовы объяснить, в чем заключается экономия в реальном [предпочтительно популярном] приложении - возможно, FireFox или Chrome? - person Mats Petersson; 04.03.2013