Этапы сборки программы

Кинье ссылку на литературу чтобы углубиться в знаниях по работе Gcc. Чтобы понять что такое таблица символов, и прочее

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

то что вы называете сборкой видимо называется building - что есть генерация актуального по времени таргета, то есть нечта, например того же образа программы, и в этот процесс могут быть вовлечены все сразу - и компилятор и линкер, и еще что-нибудь, в том числе и геренератор документации и даже мейлер, что шлет куда-нить письмо.

Никто не обманывает, просто уже давно компиляция и ассемблирование не вызываются отдельно, из сишника сразу получается объектный код. (Как и препроцессор, строго говоря, вызывается компилятором.) Но при наличии любопытства ты можешь запустить gcc с ключом -S и посмотреть на этот ассемблерный текст.

Тут вопрос традиции, не обмана.

Компоновка пишется через «о». И это единственная из перечисленных тобой стадий, которая в случае gcc обычно явно вызывается раздельно (из мейкфайла при этом вызывается тот же gcc со специальным ключом, и ему скармливается список готовых объектных модулей, gcc вызывает компоновщик (линкер), на выходе получается готовый двоичный файл.

препроцессинг не во всех языках есть. вот если есть в языке препроцессирование и директивы препроцессора, то он есть…а если их нет…то его стало быть и нет.

ассемблирование есть там, где компилятор генерит ассемблерное представление, а не какое-то иное.

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

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

Я упомянул в тексте Си…. извините, что ненастолько явно, чтобы было понятно. Сори вобщем

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

Когда я делаю

gcc file.c -S 

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

Ну если мы в бинарный(двоичный или машинный) переводим, то значит без ассемблирования никак. Потому что по определению перевод текста из на высокоуровневом языке в машинный-это ассемблирование. Значит ассемблирование имеет место всегда на Си?

Значит стадии сборки программы это препроцессинг, ассемблирование, и компановка? Так?

Потому что по определению перевод текста из на высокоуровневом языке в машинный-это ассемблирование. Значит ассемблирование имеет место всегда на Си?

ты типа с ума сошел. ассемблирование это перевод из текста на языке ассемблера в бинарный код. если нет текста на ассемблере то нет и асемблирования. что такое ассемблер - смотри определения.

Значит стадии сборки программы это препроцессинг, ассемблирование, и компановка? Так?

не так. препроцессинг(хотя это детали), компиляция, компоновка. «ассемблирование» зависит от метода реализации кодогенерации в компиляторе. можно генерить сразу в бинарный код, можно в какое-то общеупотребительное промежуточное представление для которого есть простые способы преобразования в бинарный код. например текст на асме, ir llvm, или еще что.

Спасибо

можешь запустить gcc с ключом -S и посмотреть на этот ассемблерный текст

при LTO ты там не увидишь того, что ожидаешь

компановка

КомпОновка.

По сути: нет, так получилось ещё хуже, чем в стартовом посте. Ибо вопрос о наличии ассемблирования ещё дискуссионен, но компиляция в случае gcc наличествует обязательно.

Ну и что-то похоже, тебя тянет на схоластику. В большинстве случаев вопрос о наличии ассемблерного представления не сильно важен. Пиши код. Практика, практика!

Это бесполезный вопрос, потому что это детали реализации компилятора и тебя они волновать не должны. Один компилятор может использовать реальный ассемблерный код на промежуточной стадии, другой сразу выплёвывать машинный код, третий - ни то и ни другое, а какое-то своё промежуточное представление. Вдвойне тебя это не должно волновать поскольку ассемблерный код - это просто человекочитаемое представление машинного кода.

один из путей понять есть ознакомление с эволюцией метода.

1. были схемы физической коммутации

2. появление хранимой в стираемой/переписываемой памяти состояний сообразно которым шло исполнение процесса вычисления.

3. занос тумблерами в память указанных в п.2 .

4. появление программы которая транслировала знаки с ленты в память состояний - это Грэйс Хопер и первые флоуматики

()тут и далее сложно восстановить хронологический тайминг и скорее восстановим порядок предшестования (по типу топологической сортировки - где если была причина следственная связь то причина будет раньше следствия но обратное не верно не всё что указано по списку раньше связанно причиностью с указанным позже и возможно что указанное позже было хронологически раньше)

5. появление в трансляторах(а скорее поглощение трансляторами появивщихся предтрансляторов возможности препроцессинга ибо сам препроцессинг это предварительная трансляция во вход исходного транслярора некоторой «скорописи»

6. появление перемещяемых(в дополнение к уже используемым абсолютным объектным) объектных кодов - что позволяем сделать отдельный этап сборки - в виде линковки.

зы. само слово ассемблирование - есть сборка.

7. выделение из трансляции двух крайностей и игра с их сочетаниями - компиляция как трансляция завершённого входа и интерпретация как эмуляция расширенной интерпретатором(транслирующим «одностроки») исходной машины A в расширенную машину A’

8. при появлении возможности/необходимости свёртка двух последовательных трансляций в одну - в частности компиляция исходного языка с разу либо в перемещаемые обьекники(характерно для Сишек) либо сразу в исполняемый код ( ТурбоПаскали) - и там и там было модно выбрасывать этап ассемблерных листингов ибо это зверинец микромашин.

9. всяческие жид-компиляции которые делали компиляцию в рассрочку. (P-code, смолтоки селфы, суперкомпиляции и прочая прочая , хот-споты и т.п.)

..to be continue in XXII centure

Спасибо

Я просто хотел понять, чтобы не плавать в понятиях...

Если суммировать все что тут имеется из написанного , то еомпиляция компиляция-это преобразования текста программы на языке программированмя в машинный код. А Ассемблирование, -это преобразования текста на Ассемблере в машинный код.

gcc file.s 

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

Но если

gcc file.c

То будет компиляция и компоновка, но этапа ассемблирования не будет.

Наверное опять тупанул. Сори конечно, что понял ваши объяснения криво

Ну примерно так, да.

Спасибо

Чтобы точно сказать что делает конкретная реализация конкретного языка программирования надо просто посмотреть его исходный текст. Никто не обманывает, просто это высказывания разной степени точности.

Никто не обманывает, просто это высказывания разной степени точности.

Во! Анонимус сформулировал точнее, чем я.

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

Работают так же, как буквы. Но имена, которые начинаются с двух нижних подчёркиваний, и имена, начинающиеся с подчёркивания и большой буквы, стандарт резервирует для реализации языка. (Это значит, что компилятору разрешается использовать любые такие имена для чего угодно и не беспокоиться, что ваша программа их определяет для себя.)

почему конкретного языка, конкретного компилятроа

Ок

Погуглил, но как всегда ясного ответа не увидел

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

int _; 

тут объявлена переменная с именем _.

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

anonymous

Вроде теперь немного все увязалось

Спасибо всем