LINUX.ORG.RU

Узнать в какой момент? При компиляции - используйте autoconf. В рантайме - dlsym (но тут надо быть уверенным в том, что dlsym есть)

dmitry_vk ★★★
()

Может быть это лучше делать при configure, а в программе проверять ifdef'ами?

winlogon
()

>ф-ции read & write в системе.

что значит «в системе»? искать придется все равно во всех *.so :), ну только если заранее не определено местоположение этих ф-ций.

Deleted
()
Ответ на: комментарий от Deleted

что значит «в системе»? искать придется все равно во всех *.so

угу, я неправильно выразился.

Boy_from_Jungle ★★★★
() автор топика

никак.

то есть если у вас динамически слинковано приложение, и ссылка на используемый вход (read|write)не разрешена - оно просто «незапустится»

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

вы заранее должны знать параметры системы - они вобщем-то устоявшиеся - и можно ориентироваться на POSIX.

p.s. можно использовать фигурный костыль из configure/autotools - делать stub, который поочереди запускает программы, исполняющие ровно по одной исследуемой функции и вот если все они завершились успешно, то этот stub загружает основное приложение.

MKuznetsov ★★★★★
()

> существуют ли например ф-ции read & write в системе

да

> Куда посмотреть

/proc

> что почитать

/proc/kallsyms

arsi ★★★★★
()
Ответ на: комментарий от Boy_from_Jungle

Как это нельзя? Если процесс запущен вами, почти все можно просмотреть. Если не вами - часть информации все равно открыта.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Boy_from_Jungle

> к /proc обращаться нельзя.

да, си и коран — вещи несовместимые…

arsi ★★★★★
()
Ответ на: комментарий от bibi

> И чем символы ядра помогут юзерскому приложению?

помогут в рантайме узнать статически слинкованному приложению наличие некоторых системных вызовов (для многих функций, вроде тех же read/write, в libc только обёртки к системным вызовам).

arsi ★★★★★
()
Ответ на: комментарий от arsi

помогут в рантайме узнать статически слинкованному приложению наличие некоторых системных вызовов (для многих функций, вроде тех же read/write, в libc только обёртки к системным вызовам).

Ну увидит приложение там скажем символ sys_read. И что это ему даст? Или, ещё лучше, не увидит оно там символа sys_xxx. Это гарантирует, что ядро не предоставляет определенную ф-ть? Отнюдь. Символ тупо переименовали.

bibi
()
Ответ на: комментарий от bibi

> Ну увидит приложение там скажем символ sys_read. И что это ему даст?

это ему даст информацию о присутствии этого символа в ядре. ваш К.О.

> Или, ещё лучше, не увидит оно там символа sys_xxx. Это гарантирует, что ядро не предоставляет определенную ф-ть? Отнюдь. Символ тупо переименовали.

это вам не пхп ;)

arsi ★★★★★
()
Ответ на: комментарий от arsi

помогут в рантайме узнать статически слинкованному приложению наличие некоторых системных вызовов

примера у тебя нет?!

(для многих функций, вроде тех же read/write, в libc только обёртки к системным вызовам).

я вроде нахожу их в libc.so

Boy_from_Jungle ★★★★
() автор топика
Ответ на: комментарий от arsi

?это ему даст информацию о присутствии этого символа в ядре. ваш К.О.
а если я например буду искать функцию printf

Boy_from_Jungle ★★★★
() автор топика
Ответ на: комментарий от arsi

это ему даст информацию о присутствии этого символа в ядре. ваш К.О.

И? Вот увидел ты, допустим, что в таблице символов ядра есть sys_read который так хочется топикастеру. Твои дальнейшие действия?

bibi
()

и кстати некоторые функции могут статически вкомпиливаться в бинаринк, так что сперва видимо нужно поискать их в собственном бинарнике (dlopen(NULL))

alex_custov ★★★★★
()
Ответ на: комментарий от Boy_from_Jungle

> примера у тебя нет?!

например, для x86:

arch/x86/kernel/syscall_table_32.S (в сорцах ядра) — соответствия символов ядра номерам системных вызовов (для каждой архитектуры своя таблица).

arch/x86/include/asm/unistd_32.h — определение констант номерам системных вызовов.

> я вроде нахожу их в libc.so

glibc:

time_t
time (t)
     time_t *t;
{
  INTERNAL_SYSCALL_DECL (err);
  time_t res = INTERNAL_SYSCALL (time, err, 1, NULL);
  /* There cannot be any error.  */
  if (t != NULL)
    *t = res;
  return res;
}
INTERNAL_SYSCALL(name, err, nr, args...) делает системный вызов __NR_##name. вот так можно отыскать, какая функция от каких системных вызовов зависит. и да, ещё одно: системный вызов может быть, но делать только «return ENOSYS;». так что точно узнать, реализован он или нет, можно только после его вызова. по /proc/kallsyms можно разве что выяснить, поддерживается ли он системой.

arsi ★★★★★
()
Ответ на: комментарий от Boy_from_Jungle

> а если я например буду искать функцию printf

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

arsi ★★★★★
()
Ответ на: комментарий от alex_custov

объясни, нафига такой геморой?

моча бьёт в голову начальнику.

Boy_from_Jungle ★★★★
() автор топика
Ответ на: комментарий от Boy_from_Jungle

эм… в смысле узнать, есть эти системные вызовы под данную платформу или нет? примерно так:

#include <sys/syscall.h>

#ifdef __NR_read
/* read(…) */
#endif

#ifdef __NR_write
/* write(…) */
#endif

arsi ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.