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

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

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

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

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


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

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

upd: версия newlib: 1.18

Попробую издалека:
Поднимите руки, кто использует yagarto и printf.

Покажите $(TARGET).ld чтоль
Я пробовал переопределять

, работало.

Запросто.
Нажмите для просмотра прикрепленного файла

Хм. Не вижу криминала.
Вспоминаю, что читал что-то такое про yagarto... Ага, нашёл:

Так что, если это правда, то в yagarto - никак. Берите CodeSourcery, или сборки от klen-а, если есть склонность к экспериментам

То есть, вы не с yagarto эксперементировали.
Ок, благодарю за содействие, сейчас посмотрю, какие есть альтернативы.

upd:
Посмотрел Вашу ссылку:

Это же неверное утверждение.

Кстати, тогда вопрос по Yagarto: как там определён стандартный ввод/вывод?

Прикрутил вместо yagarto/arm-none-eabi сборку kgp-arm-eabi_x86_32_HALLOWEEN_EDITIION от Klen, результат тот же: stdout не перенаправляется.
Я озадачен.

Меня немного смущает слово "перенаправляется". Что Вы имеете в виду? printf() выполняет вывод в поток stdout (при наличии перечисленных в документации системных вызовов, а именно, close, fstat, isatty, lseek, read, sbrk, write). Таким образом, перенаправление stdout - это просто присваивание ему другого значения. Может у Вас просто в stdout что-то не то?
Покажите, как Вы открываете поток, что присваиваете stdout...

Так год-то прошлый. Сейчас yagarto перешло на arm-eabi, да.



Очень странно. Посмотрите ещё вот в этой теме, я там приаттачивал тестовый проект с printf. Он для cortex-m3, но может поможет.

-----
Ещё мысль пришла. Если у вас C++ проект, то функции надо объявлять как
extern "C":

stdout ничего не присваиваю, т.к. достаточно переопределить низкоуровневые функции, которые Вы уже перечислили, разве нет? При входе в main видно, что stdout уже существует (см. ниже).

Посмотрел, принципиальных отличий не нашел.

Эти функции определены в syscalls.c, всё в порядке.
Да, я забыл упомянуть, что при вызове printf управление всё же передавалось в:

Но вместо _write_r затем уходило в __swrite.

Попробовал сейчас перед вызовом printf() руками определить указатель на _write_r():

Пока я этого не сделал, stdout->_write указывал на NULL.
Вызвал printf(), смотрю значение stdout->_write - теперь указывает на __swrite.

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

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

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

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

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

Это радует, значит Yagarto потихоньку движется в сторону, так сказать, общепринятых тенденций. И eabi, и --disable-newlib-supplied-syscalls. Больше тулзов, хороших и разных!

Мне кажется, что это кривизна newlib. Хотя неясно, чем отличается _write из вашего файла syscalls.c от _write дефолтного.

обычная буферизация. попробуйте так

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

всех форумчан с празгиком, история нашего народа однако...

Действительно.
Интересно, как я могу управлять размером буфера?
И почему использование управляющих последовательностей не приводит к буферизации вывода?


В прикручивании как раз проблем не возникло - достаточно указать в PATH путь к toolchain же.
Да, кстати, при -O0 ваш KGP собрал 160кБ кода против 202кБ -O0 yagarto (-lc -lm -lgcc -lstdc++) при прочих равных, на первый взгляд всё работало. Хотя это сейчас мало о чем говорит, да и полученный код я не тестировал пока толком.

Посмотрите setvbuf();

newlib - достаточно "взрослая" библиотека. Для увеличения производительности она буферизует вывод, в том числе и на stdout (насколько я помню stderr не буферизуется для удобства отладки). Содержимое буфера скидывается либо по fflush как было сказано выше, либо по символу перевода строки "\r\n".
По поводу yagartoo - она уже давно умела нормально собирать данный функционал.

Благодарю, уже почитал маны по теме. Не ожидал, что embedded библиотека столь "достаточно "взрослая"".

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

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

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

Как я уже писал, на момент входа в 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)...

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


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



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

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

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

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

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


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

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

Точно - я вопрос забыл написать, но он подразумевался.
Ну и наконец, значения дескрипторов при выполнении:

Хм.