Управление линковкой

[zuuuuk]

Доброго времени суток.

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

Код:

например: out.obj

[RXL]

Слишком мало информации.

[zuuuuk]

RXL, дело в том, что весь код состоит из программных модулей.
А1.с А1.h ;    B1.c,  B2.h  .......  и  так далее.
Занимаются этими модулями разные люди.
после компиляции получаются объектные файлы
A1.obj  B1.obj  ..... и тд

Линкер собирает их в одну программу.
Вот можно, как-то в ликорвочном скрипте жестко  указать адрес расположения объектных файлов А1 и В1?
они будит идти друг за другом.
Я учту размер этих модулей, так что бы они не пересекались.

[Finch]

zuuuuk, Важная информация это среда разработки! Например в связке GCC+Makefile такое делается на раз и два. Просто прописываются относительные пути.

[zuuuuk]

Finch,  процессор ARM. компилятор gcc.
Вы могли бы пример привести. или ссылку дать, что почитать.
как указать адрес расположения объектного файла?
вот

[RXL]

Строгих правил нет. У меня, к примеру, список объектных файлов задан OBJECT.
Типовой пример с поиском исходников:

Код: (GNU make)

    SOURCES=$(shell find . -name *.cpp)
    OBJECTS=$(SOURCES:%.cpp=%.o)

    all: $(OBJECTS)

    %.o: %.cpp
         <command to compile dependencies $< into target $@ >  $< -o  $@

Если makefile создается конфигуратором, то прямое его редактирование не имеет смысла и нужно смотреть опции конфигуратора.

[zuuuuk]

RXL, Это Makefile.
у меня другой вопрос.
как задать адрес расположения объектного файла?

[Finch]

Вот такой Makefile я использую. Его еше нужно допиливать. Но

Код: (GNU make)

NAME=biado
#TESTNAME=test
_OBJ = main.o node.o Document.o
#_TESTOBJ = test.o mathaction.o functionaction.o Lexem.o Calculate.o Operator.o Value.o
DEPS =

CPP=g++
_OBJDIR=./obj/
_DISTDIR=./dist/

OBJ = $(patsubst %,$(OBJDIR)%,$(_OBJ))
#TESTOBJ = $(patsubst %,$(OBJDIR)%,$(_TESTOBJ))

ifeq ($(MAKECMDGOALS) , release)
CPPFLAG=-O2 -std=c++11
GOALDIR=release/
GOAL=$(DISTDIR)$(NAME)
LIBRARY=
else
CPPFLAG=-g -Wall -std=c++11
GOALDIR=debug/
GOAL = $(DISTDIR)$(NAME)
#$(DISTDIR)$(TESTNAME)
LIBRARY=  
endif

OBJDIR = $(_OBJDIR)$(GOALDIR)
DISTDIR = $(_DISTDIR)$(GOALDIR)

.PHONY: all
all: $(GOAL)

$(DISTDIR)$(NAME) : $(OBJ) | $(DISTDIR)
        $(CPP) $^ -o $@ $(CPPFLAG) $(LIBRARY)

#$(DISTDIR)$(TESTNAME) : $(TESTOBJ) | $(DISTDIR)
#       $(CPP) $^ -o $@ $(CPPFLAG) $(LIBRARY)

$(OBJDIR)%.o: %.cpp $(DEPS) | $(OBJDIR)
        $(CPP) -c $< -o $@ $(CPPFLAG) $(LIBRARY)
       
$(OBJDIR) :
        if [ ! -d $(_OBJDIR) ] ; then \
        mkdir $(_OBJDIR);\
        fi
        mkdir $(OBJDIR)

$(DISTDIR) :
        if [ ! -d $(_DISTDIR) ] ; then \
        mkdir $(_DISTDIR);\
        fi
        mkdir $(DISTDIR)

.PHONY: clean release

release:  $(DISTDIR)$(NAME)

clean:
        for x in $(_OBJDIR)* ; do rm -f $$x/*; done
        for x in $(_DISTDIR)* ; do rm -f $$x/*; done
       

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

[Aether]

Вот такой Makefile я использую. Его еше нужно допиливать. Но

Я его понял немного не так: объектные файлы содержат функции, и он хочет иметь возможность их размещать внутри исполняемого файла так, как хочет, а не как их соединяет линковщик.
Например, как сделать main строго первой или строго последней в main.exe?

Вот только зачем это нужно?

[Finch]

А я понял, что он хочет объектные файлы создавать в отдельной директории. С возможностью собирать из этой директории. Мой вариант Makefile как раз это делает. И более того раскидывает также по разным версиям сборки (debug, release). Также и целевой файл.

[zuuuuk]

Aether, вы правы. Именно это я и имел ввиду.

Вот только зачем это нужно?

Они будут идти в том порядку который задам я.
И потом скопировать в другое место при исполнении.

makefile данную задачу не решает.

[Aether]

И потом скопировать в другое место при исполнении.

Это как? Линковщик не просто соединяет объектные файлы в один, суть статического объединения в один исполняемый файл в том, что ссылки на функции прописываются жёстко, и отделить какую-то функцию, перенести её - невозможно, тут же нарушатся связи. Или это особенность ARM архитектуры?
В случае необходимости разделения программы и библиотеки существуют другие подходы - создание динамических библиотек, с таблицами виртуальных методов - DLL, COM... Тут нужно смотреть в сторону целевой ОС, если конечно, Вы не пишете собственную ОС?

[RXL]

GNU ld объединяет объектные файлы в порядке заданном командной строкой, включая библиотеки.
ld -static -o target main.o -lc boot.o ...
Разрешение символов происходит в том же порядке: если символ уже разрешен, но есть в следующей либе, то из либы он не импортируется.

[darkelf]

Я тоже как-то не понял, о чём вопрос. Если всё-таки об ld-скриптах GNU LD, то они позволяют задавать адреса, по которым будут располагаться те или иные секции, например так:

Код:

OUTPUT_ARCH(i386)
ENTRY(_entry)
{ . = 0x83010000;
  .text : {
    *(.text*) 
    *(.rodata*)
    *(.rdata)
    . = ALIGN (4K);
  } = 0xcccccccc
  .data : {
    *(.data)
  }
  .bss . : { 
    *(.bss)
  }
  .eh_frame (NOLOAD) : {
    *(.eh_frame)
  } :NONE
  /DISCARD/ : {
    *(.rdata$zzz)
  }
  . = ALIGN (0x1000);
}

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

[zuuuuk]

По-видимому функции, которые надо будет размещать по строго фиксированным адресам, надо будет располагать в разных секциях

Я нашёл как размещать функции по адресам. Спасибо.
А вот можно именно программный модуль (объектный файл) разместить в заданном адресе?

[darkelf]

По-видимому функции, которые надо будет размещать по строго фиксированным адресам, надо будет располагать в разных секциях

Я нашёл как размещать функции по адресам. Спасибо.

Вы-бы тогда привели своё решение, вдруг кому-то ещё понадобится - поищет он по форуму, найдёт Ваш вариант, и скажет Вам спасибо.

А вот можно именно программный модуль (объектный файл) разместить в заданном адресе?

В объектном файле могут быть как минимум секции кода и данных. По современным понятиям код должен быть защищен от записи, а данные - могут быть защищены (константные данные, не изменяемые строки и т.д.) или не защищены (глобальные переменные) от изменения, а кроме того ещё и защищены от выполнения. При линковке все секции кода из объектных файлов собираются в одну исполняемую секцию .text, все секции неизменяемых данных - в секцию .rodata, а все изменяемые - в секцию .data.

С учётом сказанного выше, не понятно, как для Вашего случая проводится защита, но Вы можете попробовать что-то типа такого:

Код:

OUTPUT_ARCH(i386)
ENTRY(_entry)
{ . = 0x83010000;
  .text : {
    . = 0x83010000;
    module1.o(.text*) 
    module1.o(.rodata*) 
    module1.o(.rdata*) 
    module1.o(.data*) 
    . = 0x83020000;
    module2.o(.text*) 
    module2.o(.rodata*) 
    module2.o(.rdata*) 
    module2.o(.data*) 
    . = ALIGN (4K);
  } = 0xcccccccc
  .bss . : { 
    *(.bss)
  }
  .eh_frame (NOLOAD) : {
    *(.eh_frame)
  } :NONE
  /DISCARD/ : {
    *(.rdata$zzz)
  }
  . = ALIGN (0x1000);
}

Надо, конечно, проверять, но запись типа objectfile.o(.section) официально заявлена в документации и должна работать.

[zuuuuk]

darkelf, Огромное спасибо. Я это и искал.