Извините, сказал не подумавши.  

А какая с ними проблема? 


Да ладно, если больно надо будет - добавят в формат что нужно. Или есть какая-то резкая необходимость использовать именно специфированный кем-то там(кем?) формат?

PE специфицирован
ELF тоже


как ты такое отследишь?

  


Добавлено через 3 минуты и 38 секунд
так что с примером?   
его фишка в том, что если компоновщик будет отслеживать зависимости, то в выходной файл не будет включена функция routine, что приведет к непредсказуемым последствиям


Это сообщение отредактировал(а) MAKCim - 21.1.2008, 10:28

А компилятор разве генерирует PE или ELF? 
Я же говорил о том, что компилятор будет вкладывать информацию в объектники .



Очень просто: если линкуется с флагом -rdynamic, то включать все глобальные ф-ции с внешним связываением вне зависимости от того, используются они или нет . Ежу понятно, что из dll/so ничего выкидывать не нужно, ибо использоваться оно будет внешними программами.



А ничего... Я тебе говорю о С++(С), а не об ассемблере. В случае с ассемблером - просто включать весь модуль полностью, ибо реверсить асм вредно для здоровья .

объектные файлы являются форматными PE или ELF файлами
ELF формат, к примеру, специфицирует объектные, перемещаемые, исполняемые файлы, а также файлы динамических библиотек
с PE то же самое

DLL и SO тут вообще не причем
я просто привел один из способов вызова функции foo(), которая определена в отдельном модуле
причем компоновщик в этом случае просто не в состоянии определить, что foo на самом деле используется


ты наверное немного не в теме   
компоновщик работает только с объектными файлами
а по ним невозможно определить, как они были получены: компиляцией кода на ЯВУ или трансляцией ассемблерного кода
вот есть две эквивалентные программы

и

на выходе мы получим 2 объектных файла и невозможно будет определить, что один из них получен из исходника на ассемблере

Понятно, и тем не менее: объектники не используются дальше, чем до передачи их линкеру, т.е. можно немного усовершенствовать формат от чего никто не пострадает, разве нет?



Отлично, но чтобы упомянутый тобою способ работал нужно собрать исполняемый файл в таком режиме, когда все сущности с внешним связыванием засовываются в специальную таблицу экспорта, т.е. в дальнейшем исполняемый файл можно использовать как dll/so т.е. принципиальной разницы нет, так?



Возможно я и не в теме , но компилятор точно знает с чем он работает(асм или С/C++) и если он в состоянии(т.е., если он работает с C/C++), то ничто не мешает ему добавить эту информацию в объектник. Если же этой информации нет(т.е. компилятор был не в состоянии её добавить), то линкер вправе работать "по старинке".

хорошо, какие конкретно дополнительные данные ты предлагаешь помещать в объектный файл?

не понял
здесь обычный исполняемый файл, который собирается из 2-х модулей
в первом определена main(), во-втором - foo()
также есть ссылка на dlopen()/dlsym() из libdl.so
если компоновщик будет пытаться избавиться от ненужного "мусора", то в этот "мусор" попадет и foo(), которая на самом деле используется, но на которую нет прямой ссылки из объектного файла, где определена main()

ответь на первый вопрос

Для каждой ф-ции: список сущностей от которых зависит данная ф-ция(как внутримодульных, так и внешних). Причём, если "нужная" ф-ция заинлайнена, то от неё мы не зависим.


Не совсем обычный - он компонуется с ключем -rdynamic, а иначе он работать не будет, даже если foo не будет выкинута компоновщиком... разве нет?

Вообще то и gcc (точнее ld) и BCB давно умеют линковать только нужные функции в исполняемый файл. Достигается это очень просто - каждая функция помещается компилятором в свой собственный сегмент кода (отдельный от всех других). Линкер на этапе сборки выкидывает сегменты, к меткам, описанным в которых, нет ссылок.
Кстати, этот процесс во многом аналогичен линковке со статическими библиотеками, что есть вообще везде с самого начала.

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

Добавлено через 1 минуту и 38 секунд

да, все верно
но файл все равно останется исполняемым, только с расширенной таблицей .dynsym

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

ничего не исключается 
идет лишь добавление символов в .dynsym, а она в свою очередь используется при поиске символов

Добавлено через 1 минуту и 31 секунду
вообщем, если подытожить, задача исключения сложна, но решаема
я в принципе обратного и не утверждал

Так, Макс, блин, кому-то из нас двоих однозначно пора спать .

Ты спросил:
Я тебе ответил: отслежу по ключику -rdynamic. Если он есть, то добавляем все ф-ции вне зависимости от их реальной используемости(точно так же, как если бы мы собирали .so).


Теперь ты мне говоришь:С моей стороны вопрос: а где я сказал, что что-то исключается? 

---------------------------------------------------------
Я, на всякий случай напомню предмет нашей беседы: тривиальна или нетривиальна задача исключения ненужного кода. Т.е. разговариваем мы с тобой о неком вымышленном тулчайне, в котором такая возможность будет и пытаемся понять возможен ли такой тулчайн в реальности, таким образом, даже если я говорю "что-то там куда-то там исключается", я имею в виду мой вымышленный компоновщик. Угу?

Добавлено через 49 секунд
Или не угу? 

Добавлено через 5 минут и 4 секунды

Вот даже как . Хорошо ты подытожил, красиво .
Давай я тоже подытожу: я не увидел ни NP-полноты задачи, ни необозримого множества ньансов, которые нужно предусмотреть, так что задача классическая: есть три ф-ции(A, B, C), причём A зависит от B, а B зависит от C, значит A зависит от B и С .

рано   

да


под исключением я подразумевал, что в текущей реализации компоновщика LD ничего не исключается, а секции выходного файла формируются из целых секций входных файлов

вот
с этого и надо было начинать
тогда все стало на свои места   

это теория
она абстрагирует от деталей, в которых обычно и кроются сложности
если все так просто, почему этого до сих пор нет в LD или других компоновщиках (хотя про другие не могу дать 100%-ой гарантии)

А я, с Вашего позволения, пойду подремлю .


Конкретно про LD - думаю причина в том, что, либо используемый формат объектников дорабатывать будет дорогого стоить, а переходить на новый формат родит проблемы с совместимостью. Но тем не менее я не вижу ни одной серьёзной проблемы, чтобы воплотить в жизнь эту фичу.