newlib stdio, перенаправление ввода/вывода Опции

[Spym]

Добрый вечер.

Разбираюсь с newlib; сейчас попытался перенаправить стандартный вывод, и столкнулся с такой проблемой:
переопределил функции:

Код

_ssize_t _read_r(struct _reent *r, int file, void *ptr, size_t len);
_ssize_t _write_r(struct _reent *r, int file, const void *ptr, size_t len);

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

Код

int _read (int file, char *ptr, int len);
int _write(int file,char *ptr,int len);

результат тот же.

Ключи линкера:

Код

LIBS = -lstdc++ -lc -lgcc -lm
LDFLAGS = -nostartfiles -Wl,-Map=$(TARGET).map,--cref $(LIBS) -T$(TARGET).ld

В качестве референса использовал этот проект: http://www.siwawi.arubi.uni-kl.de/avr_proj...ects/#gcc_stdio
Toolchain из последней сборки yagarto.

Итак, вопрос: как переопределить стандартный ввод/вывод, и что я делаю не так?

upd: версия newlib: 1.18

Сообщение отредактировал Spym - Nov 2 2010, 19:25

[Spym]

Я прозрел; как выяснилось, вывод корректно работает даже в Yagarto.

Из первого вызова printf вызывается __sinit, где происходит инициализация stdout/stdin/stderr. После этого stdout->_write указывает на __swrite, откуда как раз и происходит вызов _write_r, а отсюда, в свою очередь, вызывется пользовательский _write; но и _write_r можно переопределить.

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

Код

printf("Something string");

в newlib не приводит к выводу этой строки в stdout; после замены на:

Код

printf("%s", "Just string\r\n");

все ВНЕЗАПНО заработало.
Почему так? Ведь в этом случае в stdout должно было уйти "Something string".

[alx2]

Из первого вызова printf вызывается __sinit, где происходит инициализация stdout/stdin/stderr.

Вот этот момент мне не очень понятен. Чем инициализируется stdout? Иными словами, куда, на какое устройство будут выводиться данные, отправляемые в stdout?

У меня типичная инициализация происходит так (упрощенный пример - сервер, принимающий tcp соединения):

Код

.....
int s = socket(.....);
listen(s, .....);
.....
int sd = accept(s);  // получили дескриптор нового tcp соединения
stdin = stdout = stderr = fdopen(sd, "w+");
.............
printf("Hello!\n");

В результате вызова printf() я получаю вызов _write(int, char*, int), первым аргументом которого будет значение sd, указанное при вызове fdopen().
А что я получу в качестве первого аргумента _write, если не сделаю fdopen? Как в этом случае _write должна решить, куда отправлять данные, на которые указывает второй аргумент?...

[Spym]

Вот этот момент мне не очень понятен. Чем инициализируется stdout?

Как я уже писал, на момент входа в main дескрипторы для stdin/stdout/stderr уже существуют, и инициализируются при первом обращении при помощи __sinit.

В результате вызова printf() я получаю вызов _write(int, char*, int), первым аргументом которого будет значение sd, указанное при вызове fdopen().
А что я получу в качестве первого аргумента _write, если не сделаю fdopen? Как в этом случае _write должна решить, куда отправлять данные, на которые указывает второй аргумент?...

В случае newlib, вы получите дескриптор _reent->_stdin (ну или _stdout, _stderr) (посмотрите в newlib: sys/reent.h) - это позволит принять решение о целевом устройстве.

[alx2]

Как я уже писал, на момент входа в main дескрипторы для stdin/stdout/stderr уже существуют, и инициализируются при первом обращении при помощи __sinit.
В случае newlib, вы получите дескриптор _reent->_stdin (ну или _stdout, _stderr) (посмотрите в newlib: sys/reent.h) - это позволит принять решение о целевом устройстве.

Не могу с Вами полностью согласиться.

Стандартные потоки, безусловно, существуют, как некий объект в памяти. Вопрос был в том, можно ли начать работать с этими объектами, предварительно явно их не инициализировав. О том, что они автоматически инициализируются при первом обращении, я не знал, спасибо за информацию. Мысль же моя заключалась в том, что для последующей работы с выводом на низком уровне (в соответствующих системных вызовах) необходимо, чтобы этим системным вызовам передавались осмысленные аргументы и, в частности, файловый дескриптор. При явной инициализации потока (через fopen или fdopen) это осмысленное значение предоставляет программист. А если инициализация происходит "автомагически", без участия программиста, откуда тогда возьмется это осмысленное значение?

Вот сейчас я посмотрел код newlib. Значение дескриптора хранится в поле _file структуры FILE. То есть системным вызовам, в нашем случае _write(), в качестве первого аргумента передается _reent->_stdout->_file. Теперь смотрим, какое же значение там находится. __sinit() для инициализации стандартных потоков вызывает __sfp(), которая, в свою очередь, инициализирует поле _file значением -1. Таким образом, при выполнении каких-либо операций с таким потоком системным вызовам будет передаваться -1 в качсетве файлового дескриптора, что традиционно означает невалидный дескриптор, и такой системный вызов, как правило, должен давать ошибку EBADF (bad file descriptor). По крайней мере, никакого решения о целевом устройстве такой дескриптор принять не позволит.

Конечно, если в целевой системе заведомо существует только одно устройство ввода/вывода (например один com-порт), тогда все операции производятся с ним и только с ним, и можно, наверное, в системных вызовах не анализировать значение дескриптора. Но как только мы допускаем наличия нескольких логических устройств (хотя бы двух com-портов), возникает и необходимость мультиплексировать операции ввода/вывода, а для этого потребуется селектор, которым и является дескриптор, передаваемый первым аргументом. И тогда придется-таки открывать потоки явно через fopen(3)/fdopen(3)...

[Spym]

Не могу с Вами полностью согласиться.

Подозреваю, что мы говорим о различных версиях newlib; у меня 1.18, как я уже писал тут.

если инициализация происходит "автомагически", без участия программиста, откуда тогда возьмется это осмысленное значение?

В случае 1.18, значение возмется из machine/spu/c99ppe.h:

Код

#define SPE_STDIN                   1
#define SPE_STDOUT                  2
#define SPE_STDERR                  3

__sinit() для инициализации стандартных потоков вызывает __sfp(), которая, в свою очередь, инициализирует поле _file значением -1.

Для 1.18 это не совсем верно:

Код

_VOID
_DEFUN (__sinit, (s),
    struct _reent *s)
{
  s->__cleanup = __cleanup;
  s->__sdidinit = 1;

  s->_stdin = &s->__sf[0];
  s->_stdin->_fp = SPE_STDIN;

  s->_stdout = &s->__sf[1];
  s->_stdout->_fp = SPE_STDOUT;

  s->_stderr = &s->__sf[2];
  s->_stderr->_fp = SPE_STDERR;
}

Соответственно, для stdin/stdout/stderr мы получим дескрипторы 1, 2, 3.

[alx2]

А, понял. Вы говорите о __sinit из newlib/libc/machine/spu/stdio.c, а я смотрел __sinit() из newlib/libc/stdio/findfp.c.
У меня (вот сейчас смотрю map-файл реального проекта) используется __sinit именно из findfp.o (arm-elf/lib/libc.a). А у Вас не так?

Соответственно, для stdin/stdout/stderr мы получим дескрипторы 1, 2, 3.

Вы говорите о различиях стандартных потоков ввода, вывода и ошибок. Я говорил о другом.
Допустим, в целевом устройстве два com-порта. Для работы с ними я запускаю две одинаковые задачи. В каждой из них выполняется printf(), то есть производится вывод в stdout. Но одна задача должна выводить в один com-порт, другая - в другой! Для этого каждая задача должна по-своему проинициализировать stdout. Если первая задача выполнит stdout = fdopen(1, "w+"); а вторая - stdout = fdopen(2, "w+");, то printf(...) из первой задачи даст вызов _write(1, ....), а из второй - _write(2, .....).

[Spym]

Вы не ответили, какую версию newlib используете.

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

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

[alx2]

Вы не ответили, какую версию newlib используете.

А Вы не спрашивали. Вы лишь высказали предположение, что мы говорим о разных версиях...
Нет, я говорю о newlib-1.18.0.