MULTI for MIPS, проблемма линковки Опции

[jorikdima]

Добрый день.
Уже достало мучится с этим Гринхилсом.
Существует достаточно большой проект для MIPS написаный на С. Изначально писался под компилятор GNU sde toolchain, соответственно были написаны скрипты компилятору и линкеру. Все нормально компилируется и линкуется. Но встала необходимость (рассматривается возможность на самом деле) перейти на другой компилятор, например МУЛЬТИ (под МИПС больше ничем особо не пахнет).
И вот вроде бы перенес все настроики компилятора, все вроде бы компилится, дело за малым - линковка . И вот тут проблему никак не удается решить. Создаю свой файл дириктив линкеру, прописываю там области памяти и секции (то как он парсит этотт файл - отдельная история ):

Код

CONSTANTS
{
    FLAS_BASE = 0xBFC00000
;
    FLASH_OFFSET = 0x4000
;
    RAM_BASE = 0xA0000000
;
    SCRATCHPAD_BASE = 0xBC000000
;
}
MEMORY
{
    flash    : ORIGIN = FLAS_BASE + FLASH_OFFSET ,    LENGTH = 10M
    ram    : ORIGIN = RAM_BASE ,    LENGTH = 10M
    scratch : ORIGIN = SCRATCHPAD_BASE , LENGTH = 10M
}
SECTIONS
{
    .code : {
        init.o ( .text )
        * ( .text )
        * ( .rodata )
        * ( .rel.dyn )
        * ( .eh_frame )
        
    } > flash
    .initial_dataf ROM ( .initial_data ) : {
        * ( .data )
        * ( .lit8 )
        * ( .lit4 )
        * ( .sdata )
    } > .
    .uninitial_dataf ROM ( .uninitial_data ) : {
        * ( .sbss )
        * ( .scommon )
        * ( .bss )
        * ( COMMON )
    } > .
    .isramf  ROM ( .isram ) : {
        * ( .isram )
    } > .
    .ROM.free_space ROM ( .free_space ) : > .

    end = .;

    .initial_data : > ram
    .uninitial_data : > .
    .free_space : > .
    .isram : > scratch
    

}

Ставлю в настройках проекта [Linker Command File]= мой файл. Типа теперь он должен использовать ТОЛЬКО МОИ секции, но линкер упорно продолжает видеть также свой дефолтовый файл standalone_ram.ld . И пишет, что одна из моих секций перекрывается с одной из секций в его файле.

Код

SECTIONS
{
    .zdata                        ABS : > zero_memory
    .zbss                        ABS : > .
    .rozdata                            ABS : > .

    .text                            : > dram_memory
    .syscall                            : > .
    .secinfo                            : > .
    .fixaddr                            : > .
    .fixtype                            : > .
    .robase                           ALIGN(8) : > .
    .rodata                            : > .

    .sdabase                               ALIGN(8) : > .
    .sdata                            : > .
    .sbss                            : > .
    .rosdata                            : > .
    .data                            : > .
    .profile                            : > .
    .bss                            : > .
    .heap                ALIGN(8) PAD(heap_reserve)  : > .
    .stack                ALIGN(8) PAD(stack_reserve) : > .

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

Второе. Я вообще хотел бы на выходе получить бинарник. Для этого я так понимаю надо поставить опцию Binary Code Generation но сразу при построении проекта среда говорит, что для МИПСа я этого сделатьь не могу, почему??? Может эта опция не о том? Для х86 - тоже самое. Если без этой опции скомпилить сэмпл, то ниче похожего на бинарник нету, только объектные файлы.

[andk]

Да, GHS довольно своеобразная среда..
Я к ней привыкнуть не смог, пользуюсть отдельными утилитами. Только отладчик запускаю из-под среды.
Просмотри файлы проекта (default.gpj, *.gpj) скорее всего там и найдешь проблему.

В оконцовке у меня это выглядит примерно так:
1. Батник для запуска компилятора -
......
D:\Dev\GHS\mips407\gbuild.exe -all default.gpj
.......

default.gpj - файл "проекта" -

#!gbuild
primaryTarget=mips_standalone.tgt
[Project]
-bsp generic <<< здесь глобальные настройки компилятора
-G
-object_dir=objs
-wantprototype
-cpu=rc32364
-littleendian
default.con
src\hello.gpj [Program]
src\resource.gpj [Project]

Если настройки компилятора разные для разных файлов, то оформляется ввиде "подпроектов" с индивидуальными настройками внутри.
Соответственно, hello.gpj и resource.gpj - файлы:
#!gbuild
[Program]
hello.c <<< исходники добавляю свои, как мне нужно
dmatest.c
tdm.c
eth.c
DspIf.c
standalone_ram.ld <<< файлик для линкера - я имя его не менял, потроха поправил и все.

resource.gpj - не разбирался, зачем этот файл, поэтому оставил все как было.
#!gbuild
[Project]
resource_readme.txt
standalone_ram.ld

Ну и все практически
В standalone_ram.ld правишь что тебе нужно, прикручиваешь свою любимую среду и вперед!
Кстати, хелп у GHS не плохой, много полезных фич можно вычитать.

Бинарник... не помню, по моему не заморачиваясь на разборки с линкерными ключами - конвертировал из ELF - да он не очень мне нужен был.
А Вообще - Build options - Linker - Generate additional output.

Creates the specified output type in addition to the project executable. Permitted settings
for this option are:
<> Memory Image File (-memory) &ndash; Generates output file with .mem extension containing the output of the image as translated by the gmemfile utility program. For more information about gmemfile, see "The gmemfile Utility Program" in the MULTI: Building Applications book for your target.

Вроде то, что тебе нужно. По виду - честный образ памяти.

<> S-Record File (-srec) &ndash; Generates output file with .run extension
containing the output of the image as translated by the gsrec utility program. For more information about gsrec, see "The gsrec Utility Program" in the MULTI: Building Applications book for your target.

<> None (--no_additional_output) : [default]

[jorikdima]

Спасибо. Разобрался теперь.

[jorikdima]

По ходу дела возник еще один вопрос с линкером.
Предположим есть написанная на С функция, которая хранится в одном с файле. Я могу скомпилировать этот файл с помощью например gcc (хотя и не обязательно) и получить объектник (установив директиву -с компилятора). Далее предположим я этот объектник хочу подключить к другой программе, которая вообще делается в другой среде и под другим компилятором.
Так вот проблемма заключается в следующем. В этой С функции я использую библиотеку math <math.h>, для вычисления мат. функций. Когда я подключаю мой файл к программе, то все линкуется, ошибок не выдает, функция вызывается, но как только в этой моей функции происходит вызов матиматической функции из math.h проц переходит по какому то адресу где одни nop.
Насколько я понимаю математическая функция, которую я вызываю никак не включается в код объектника (что естественно), а для нее есть свой объектник, где то в стандартных библиотеках. Но как мне его этот математический объектник "взять с собой" в новый проект???? Надеюсь я ясно выразился.
Спасибо

[andk]

Ну а впрямую сказать линкеру "линкуй либу ХХХ" ?
Поискать имя функции в библиотеках можно, имена там есть.

А вот возможность линковки обьектников сделаных из-под разных компиляторов.... не знаю, ни разу так не делал..... Что-то мне думается шансов мало...

[jorikdima]

Ну а впрямую сказать линкеру "линкуй либу ХХХ" ?
Поискать имя функции в библиотеках можно, имена там есть.

Так а какую либу??? Я расчитываю на то, что свой файл (сишный с вызовом мат функции) я отдам условно говоря покупателю, а он пусть линкует его с чем хочет.

А вот возможность линковки обьектников сделаных из-под разных компиляторов.... не знаю, ни разу так не делал..... Что-то мне думается шансов мало...

Должно быть нормально, так как формат объектника стандартный - ELF. По крайней мере для GNU и MULTI. Линкер не ругается, и нормально вызывает мою функцию, только при вызове мат функции внутри моей идет чер знает куда. Если в моей функции отменить выхов сторонней мат функции, то все ОК.

[andk]

>Так а какую либу???

Во всех либах присутствуют имена функций. Так что, есть шанс найти нужную либу по содержанию в ней нужного тебе имени функции.

> Я расчитываю на то, что свой файл (сишный с вызовом мат функции)
> я отдам условно говоря покупателю, а он пусть линкует его с чем хочет.

Не, ну если исходники отдаешь - какие проблемы?

>>А вот возможность линковки обьектников сделаных из-под разных компиляторов....
>>не знаю, ни разу так не делал..... Что-то мне думается шансов мало...

>Должно быть нормально, так как формат объектника стандартный - ELF.
>По крайней мере для GNU и MULTI. Линкер не ругается, и нормально вызывает мою функцию,
>только при вызове мат функции внутри моей идет чер знает куда.
>Если в моей функции отменить выхов сторонней мат функции, то все ОК.

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

Вообще, ситуация странная в том смысле, что мат функция отсутствует в памяти.
Может выбраны не те опции для процессора? (типа наличия мат сопроцессора, разрядности, еще чего-нибудь?)
Или условная компиляция где-то затесалась и требует каких-то параметров?
Попробуй в math.h перед вызываемой тобой функцией поставить #error "xxxx" - пройдет или нет?