Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Здравствуйте, Тот кто сидит в пруду, Вы писали:

AS>Господа, я жутко извиняюсь, но вы что с дуба рухнули? Какой не PIC код под x86?!
call может быть как относительным, так и абсолютным. но калла мало. у x86 нельзя адресовать данные относительно регистра команд. MOV EAX, [EIP+XXXX] -- нет такой команды.

AS>Он там весь PIC бай дизайн. Обращение к данным, то же бай дизайн по фиксированному адресу.
MOV EAX, [ESP+XXX] -- по фиксированному? да ну?! не может быть!!!

AS> Собственно кто мешает собрать всё в одну секцию и сделать авторелок?
мешает -- кому?! компилятору? да никто не мешает. достаточно использовать базовый адрес и танцевать от него. но это чуть-чуть медленее. релоки призваны ускорить это дело.

AS> У gcc кстати какя-то такая фигня была.
она у него не без ограничений, накладываемых на компилируемый код.

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

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>Здравствуйте, Alexéy Sudachén, Вы писали:

ТКС> Вот прямо сейчас скопировал из дизассемблера — call 022EC860.
ТКС> Вполне себе привязано к конкретному адресу. А на самом деле это
опкод посмотрите. адрес -- относительный. то, что дизассемблер показывает 022EC860, а не $+XXXX это проблемы дизассемблера.

ТКС> Базонезависим — это когда мы можем поместить код по любому адресу,
ТКС> передать на него управление, и он отработает одинаково. Без всяких
ТКС> дополнительных телодвижений, типа коррекции адресов внешними средствами

вот пример позиционно-независимого кода:
call l
l: pop ebx
mov eax, [ebx+XXX]

вот пример позиционно зависимого кода:
mov eax, offset data

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

AS>>Дык, можно элементарно писать на С PIC код, без какой либо специальной поддержки со стороны компилятора.
ТКС>Можно. Можно и без типизации писать. Или на ассемблере. Только вероятность ошибок на порядки повышается.
"можно" это очень спорное утверждение. вот тут коварный ms vc обращается к глобальным переменным даже если у функции только локальные переменные. откуда же взялись глобальные? а это, оказывается, магический пирожок. вот счастье. но это хоть отключается. однако, _гарантий_ что компилятор не выкинет финтов у нас нет (если только возможность генерации такого кода не заявлена и не поддерживается явно).

Здравствуйте, PanychY, Вы писали:

PY>Приветствую

PY>Вот такая вот задача.
PY>Есть некий код на C, фактически — один файл .C в котором определенны несколько функций, структур и т.п.
PY>Задача собственно в том, что-бы оттранслировать этот код в машинный и получить на выходе raw-машинный код(а не объектный .obj или .o), в котором все эти функции и лежат — что-то типа прошивки получается. Естественно нужно что-бы как результат была выдана таблица точек входа. Ищу компилятор который это может более менее штатными средствами. Целевая архитектура x86/x64_86.

Appended:
Спасибо всем кто ответил. Дабы сместить акценты и не пресечь развитие ненужного срача, дополню:
1. Меня вполне устраивает решение: sourcecode.c --транслятор cl/gcc/etc--> objectcode.{obj|o} --dumpbin/dumpobj и т.п--> BLOB
Собственно я бы ими воспользовался сразу без вопросов, если бы они могли генерировать карту размещения функций в BLOB-е. (Я пока такой опции не нашел).
2. Исходный C код действительно будет написан изначально позиционно независимо: т.е глобальных и статических данных не будет, вызовы соседних функций будут выполняться исключительно косвенно через память/регистр, c-runtime использоваться не будет, либо по минимуму(inline/intrinsic). Т.е. будут приняты все меры дабы не позволить транслятору нагенрировать позиционно зависимый код. (Фактически, С-код прошивки эквивалентен переписанной на C реализации какого-нибудь C++ класса с исключительно виртуальными методами, которые общаются только между собой).
3. Да, целевая платформа пока Win32(POSIX подобные — позже). Т.е. "прошивка" — не MBR, а вполне себе типичный user-space код, который грузится такой-же типичной user-space софтиной, и передает ей управление в случае необходимости.
4. Как обеспечивается позиционная независимость .DLL я в курсе. Но этот способ не применим, ибо это не PIC.
Т.е. ищется компилятор и/или ключи к нему и тулзы, позволяющие генерировать PIC как встроенная фича(а не на авось повезет).
И да, не хочется заставлять разработчиков писать одна функция — один .C файл(вызовов по абсолютному адрессу точно не будет).

Здравствуйте, PanychY, Вы писали:

PY>Appended:
PY>Т.е. ищется компилятор и/или ключи к нему и тулзы, позволяющие генерировать PIC как встроенная фича(а не на авось повезет).

Я как бы уже вскольз упомянул, что знаю как писать обычный С-код c рантаймом и глобальными переменными, который в результате PIC. Причём на том же MSVC, что успешно давно уже делаю. Но на это никто внимания не обратил, зачем ))) Все принялись опровергать правильное, но не полное утверждение. Как истинные RSDN'овцы.

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

Здравствуйте, мыщъх, Вы писали:

AS>>Господа, я жутко извиняюсь, но вы что с дуба рухнули? Какой не PIC код под x86?!
М>call может быть как относительным, так и абсолютным. но калла мало. у x86 нельзя адресовать данные относительно регистра команд. MOV EAX, [EIP+XXXX] -- нет такой команды.

молодец, возми конфетку. я собственно о чём писал?

AS>>Он там весь PIC бай дизайн. Обращение к данным, то же бай дизайн по фиксированному адресу.
М>MOV EAX, [ESP+XXX] -- по фиксированному? да ну?! не может быть!!!

хм, почему тогда не написать mov eax, [любой общий регистр + XXX]
принципиальное отличие от кода оССюСяешь?

AS>> Собственно кто мешает собрать всё в одну секцию и сделать авторелок?
М>мешает -- кому?! компилятору? да никто не мешает. достаточно использовать базовый адрес и танцевать от него. но это чуть-чуть медленее. релоки призваны ускорить это дело.

спасибо Кэп, а я то и не знал )))

AS>> У gcc кстати какя-то такая фигня была.
М>она у него не без ограничений, накладываемых на компилируемый код.

И?

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

И? проще скомпилировать код в DLL и разместить её в памяти руками, опа! Я только что сделал великое открытие, мне орден полагается?

Здравствуйте, watch-maker, Вы писали:

AS>>Назови мне процессор в котором дуступ к памяти можно делать по смещению от инструкции? Так на всякий случай.

WM>Wikipedia:
WM>Интерес представляют конечно же не учебный MMIX, а ARM и x86-64. Да, в x86-64 можно наконец-то писать нормальный PIC, где глобальные переменные адресуются через смещение относительно значения регистра RIP.

Спасибо за наводку, не знал! Надо будет посмотреть.

Здравствуйте, мыщъх, Вы писали:

ТКС>>Можно. Можно и без типизации писать. Или на ассемблере. Только вероятность ошибок на порядки повышается.
М>"можно" это очень спорное утверждение. вот тут коварный ms vc обращается к глобальным переменным даже если у функции только локальные переменные. откуда же взялись глобальные? а это, оказывается, магический пирожок. вот счастье. но это хоть отключается. однако, _гарантий_ что компилятор не выкинет финтов у нас нет (если только возможность генерации такого кода не заявлена и не поддерживается явно).

Полную гарантию может дать только страховой полис (c) сами знаете кто ))) Однако есть конкретные версии компиляторов, которые точно изветно как работают, но ведь реальным пацанам этого мало, да? Им надо чтобы все возможные кейсы были описаны в документации и ещё лучше оговорены EULA...

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>Здравствуйте, PanychY, Вы писали:

PY>>Appended:
PY>>Т.е. ищется компилятор и/или ключи к нему и тулзы, позволяющие генерировать PIC как встроенная фича(а не на авось повезет).

AS>Я как бы уже вскольз упомянул, что знаю как писать обычный С-код c рантаймом и глобальными переменными, который в результате PIC. Причём на том же MSVC, что успешно давно уже делаю. Но на это никто внимания не обратил, зачем ))) Все принялись опровергать правильное, но не полное утверждение. Как истинные RSDN'овцы.

AS>Как обычно, все сами всё знают и умеют, а тут какой-то ламер их учить пытается.... да я разве ж против, желаю самостоятельно найти ключики / написать нужные тулзы.
Я читал все ответы. У меня не стоит проблема написания кода, компиляции и извлечения BLOB-а. У меня стоит проблема поиска функций в BLOB-е.

Здравствуйте, PanychY, Вы писали:

AS>>Как обычно, все сами всё знают и умеют, а тут какой-то ламер их учить пытается.... да я разве ж против, желаю самостоятельно найти ключики / написать нужные тулзы.
PY>Я читал все ответы. У меня не стоит проблема написания кода, компиляции и извлечения BLOB-а. У меня стоит проблема поиска функций в BLOB-е.

тривиальные питоновский скрипт парсящий мап файл разве с этой проблемой не справляется?

Здравствуйте, Alexéy Sudachén, Вы писали:

AS>тривиальные питоновский скрипт парсящий мап файл разве с этой проблемой не справляется?
1. У меня такого нету. А у Вас?(Ну ладно, пошутил, напишу я утильку, но впредь закидоны по поводу питоновских скриптов пишет в форуме для холиворов).
2. У меня нету .map файла. .map файл рождается линкером. Линкер не запускается, ибо не нужен.
3. Полученный линкером .map не содержит искомой информации.
ЧЯДНТ?

AS>>тривиальные питоновский скрипт парсящий мап файл разве с этой проблемой не справляется?
PY>1. У меня такого нету. А у Вас?(Ну ладно, пошутил, напишу я утильку, но впредь закидоны по поводу питоновских скриптов пишет в форуме для холиворов).

Не совсем такой, но есть естественно.

PY>2. У меня нету .map файла. .map файл рождается линкером. Линкер не запускается, ибо не нужен.
PY>3. Полученный линкером .map не содержит искомой информации.
PY>ЧЯДНТ?

допустим есть нечто такое

int f(int a)
  {
    return a+10;
  }

int g(int a)
  {
    return a+10;
  }

тогда делаем

gcc -c test.c
nm test.o

00000000 b .bss
00000000 d .data
00000000 r .eh_frame
00000000 t .text
00000000 T _f
0000000b T _g

Вроде как всё очевидно. Если нет, то смотрим

objdump -d test.o

Disassembly of section .text:

00000000 <_f>:
   0:    55                       push   %ebp
   1:    89 e5                    mov    %esp,%ebp
   3:    8b 45 08                 mov    0x8(%ebp),%eax
   6:    83 c0 0a                 add    $0xa,%eax
   9:    5d                       pop    %ebp
   a:    c3                       ret    

0000000b <_g>:
   b:    55                       push   %ebp
   c:    89 e5                    mov    %esp,%ebp
   e:    8b 45 08                 mov    0x8(%ebp),%eax
  11:    83 c0 0a                 add    $0xa,%eax
  14:    5d                       pop    %ebp
  15:    c3                       ret    
  16:    90                       nop
  17:    90                       nop