Преди време имаше подобна тема, но пак ще питам - търси се що-годе завършена имплементация (или просто концепция) за работа с диагностични събития в ембедед и не само. Имам предвид това което типично му казваме логове, трейсове, грешки и подобни.
Изходните ми точки са:
- всички или повечето софтуерни компоненти могат и/или искат да сигнализират за разни събития случващи се в тях - нормална работа (трейс, лог) или ненормална (ексепшън - грешка, неизлязла проверка (assert) или подобни)
- както и е в класическите системи (syslog, log4...) има класове от "логери" за различните видове "сигнали" - грешки, предупреждения, информация, - на база на този клас могат да се правят специфични обработки - да се насочват към различни изходи и т.н.
Всъщност самите проекти които гледам за референция достатъчно добре описват feature-ите които имат - асинхронно логване, ...
Ей това са нещата които разглеждах:
- log4cpp https://github.com/orocos-toolchain/log4cpp
- spdlog https://github.com/gabime/spdlog
- g3log https://github.com/KjellKod/g3log
и разни други.
Като цяло spdlog най- ми е на сърце, но едно от условията в задачата е да е евентуално използваемо в стари проекти на C. Повечето нови разработки на които попадам ефективно ползват C++11 и нагоре което е похвално но не е съвсем портируемо в моя контекст.

Всъщност основното ми питане е в малко по-друга посока - типичните системи използват конвертиране към стринг на таргет системата (т.е. правят един sprintf на ембедед системата) и пускат текста нагоре. Алтернативата за която си мисля е тривиална - да се остави прехвърлянето към текст за по-късно и за друго място - т.е. да се прехвърли една структура/обект от нещата които ще се логват - за uint32_t примерно това са 4 байта и т.н. Директно гледам към messagepack https://msgpack.org/ или подобни (ASN.1 или някой от многото конкуренти). Целта е по-ефективно използване на заделените за треис/лог буфери както и олекотяване на транспортните нужди между отдалечените компоненти.
Хубаво би било текстовете да не се вкарват в самия фирмуер а да остават като дебъг информация в елф-а, като разбира се това малко прецаква работата и иска log viewer-а да достъп до конкретния елф, или да се поддържа таблица от текстове валидни за примерно всички софтуерни версии на дадена продуктова линия. Това е малко далечно и може да не го мислим.
Та някой има ли мнение или опит по темата? Популярният protobuf го изключвам понеже трябва да се грижа за *.pb схемите които дефинират интерфейсите, докато messagepack и сие са самоописателни. Може би ако се стигне до идеята за debug стринговете в елфовете и предаването на тази информация към log viewer-а за да може той да разбира лога, то protobuf може да е подходяща. То това с "дебъг информацията" прави log viewer-а да е по-скоро нещо като дебъгер, но това е принципна пречка? Стига лог информацията (масив от много протобуф данни) трябва да носи някакъв идентификатор за да може да се съпостави с ELF-а или друг файл които е "речника" за обръщане на бинарните данни в човешки текст.
Т.е. на ПЦ-то да върви лог сървъра който да получава бинарните данни и използвайки речника (да кажем elf-а) да генерира текстов файл.
Хубаво е да се стъпи на утвърдени инструменти за да се получи нещо работещо - имам предвид да се вади информацията от елф файла защото има достатъчно инструменти в тулчейновете и външни библиотеки, отделно вкарването на тази информация през сорса също няма да е трудно.
Мисля си доколко gprof/gcov информацията може да помогне за целта - макар че дори само включването на дебъг символите е достатъчно за да се извади доста информация - по адрес да се намери име на функция, променлива, секция. Реално това може би е крайната цел - частичен дебъг в смисъл на трейсване на работата на кода, без контрол върху него, без брейпойнти и дебъг хардуер, само "принтване" и то опционално на информация в интересни точки на софтуера.
Не ми е изцяло изчистена идеята, трябва да го мисля още.
Ако изключим изцяло "бинарната" идея ме интересува добър инструментариум за последваща работа (анализ) на логовете. Има едно Log4View което е платено и по картинки е интересно, но така и не съм го пускал.
Не съм запознат та се чудя и друго - под виндоус гледам че при големи проблеми правят coredump и после явно някак успяват да възстановят ситуацията за да разберат какво е станало. Това ще да е по-големия батко на stack dump и подобни. Като си мисля това би трябвало да е цялата значима памет която гръмналото нещо е виждало около себе си? Има ли нещо подобно под gcc и приятели, или llvm/clang?

Я задавай въпросите си един по един, ама ясно че нещо не разбирам за какво питаш...

Аз съм ползвал/правил custom log в който се записва само 32 битов адрес на грешката + малко бинарни данни като параметри за sprintf но без основния стринг.
Изискването беше да се минимизира обема на лог-а защото устройствата които се следяха работеха на батерии без регулярен физически достъп до тях т.е. gps logger + gsm gprs modem. Та от адреса сe взима с __builtin_return_address, после с addr2line се хваща коя точно е линията в сорса и от нея се вижда вече мястото в сорса и съответно се анализира защо е станало така. Разбира се, за да работи това първото съобщение съдържа git commit sha1 за да може да се върнеш на точния build. Хубавото на този подход е, че позволява да вкараш всички логове от всички устройства и всички версии на софтуера в база данни и после да анализираш направо със sql. Лошото е, че иска доста писане на код и скриптове за да го подкараш. Също така на моменти да знаеш само адреса на грешката няма да е достатъчно защото може да има няколко начина да се стигне до това парче код ... та последно бях добавил 10 нива от call stack и така успях да хвана много мръсен dead lock който се появяваше изключително рядко и никога на бюрото ми. Помня само, че на няколко хиляди устройства ставаше веднъж на няколко дни ... абе измъчи ме, но го хванах

Точно в тази посока мисля - значи не е безнадеждно отнесена идеята. Ще поразгледам и ще опитам да "сондирам" дали има шанс да се приеме нещо такова, или ще е в списъка отворени точки (в който само влизат неща и нищо не излиза).
Значи идеята беше да описвам няколкото атрибута - таймстамп, адрес и някакво състояние - 1,2 или повече "параметъра" които да покажат контекста на събитието. Например ако е проверка от сорта на "if x>5 return 0;" да добави и че проверката е гръмнала със стойност x=47.
Това с ретърн адреса е добре но наистина за странни грешки е хубаво да има повече "контекст".
Ако се говори за горе-долу фиксирано entry то може да е ограничено до няколко 32-битови променливи - 3-4 май изглеждат добре. Мислех си дали има смисъл от енкоднинг от типа на protobuf за тези няколко променливи - то овърхеда от динамиката му ще обезсмисли идеята?
Май залитаме в посоката да имаме екстрите на нормален инструментален трейс ама да го ползваме докато устройството е при клиента на другия край на света? Ама то нали това по принцип е идеята на логовете?

Значи то се получава така:



Това LOG е макро което вътре прави каквото трябва, виж моето как е:


Важно е функцията за следващия адрес да не се inline, че иначе ще видиш адреса една функция нагоре по call stack



Та в лога записваш само addr и с малко анализ на printf стринга данните които са в ... т.е. виж там va_list, va_start, vsnprintf, va_end

Играчка е, но става.

Да, мерси за идеите, нещо подобно ще да е.
Едит: това чудо ще се опитам да го използвам и за отдалечени системи - т.е. сървър/демон както syslog, но за начало ще излиза към mqtt брокер. Това за да мога да го пробвам в отдалечени системи. Като начало май ще го сложа на някое есп за пробите.
То затова и заглавието споменава syslog с идеята да има възможност за различни изходи, вкл. и към mqtt - то това го има готово май за syslog.

Edit: благодаря за attribute(format) - не го знаех, хитра работа ...

Абе бях почнал да го разписвам на библиотека това ама все не остава време ... и сега си го копирам като файл от проект в проект ... иначи идеи много ама време малко и все не е приоритет. В момента реализацията ми е за posix stdout ... ъъъ ... всъщност stderr ... т.е. пускам си програмата и гледам оутпута в конзолата. Със съвсем малко доработка може да се направи да пише някъде другаде и да стане по използваемо. Ако решиш да вървиш в тази посока пиши да ти го пратя да не преоткриваш колелото

Аз натам съм тръгнал, ще ми е полезно да го видя. Иначе трябва да го закача към асинхронно логване което имам сега, но там ще си поиграя също.
Мисля си че ще стигна до това да сглабям от налични парчета, дано уцели подходящите да не стане франкенщайн...

Аз съм го синхронизирал със pthread_mutex_t - но то не навсякъде има posix threads та и това трябва да се абстрактва.

Това което ти разправях за stack trace & addr2line тук не е направено - правих го за клиент и си остана за него ... по точно го доработих, преди мен някой вече го беше измислил концептуално. Но там беше навързано с буилд система, client/server, база данни, скриптове и т.н. т.е. завършена система и нямаше как да го опън сорсна.

Да, ясно е - благодаря за тези сорсове. Не мога да разчитам на pthreads, но то в тази част имам нещо готово.
А всъщност сега размишлявам за вариантите за синхронизиране и ми се върти из главата да ползвам нещо lockless, в посока да имам множество индивидуални "източници", да кажем от всеки тред дори, със собствен буфер дори, и посрещащия (един или повече) да вади от всичките полека и да пише или праща. Идеята ми е да има по-фин контрол и да мога да дам по-голям буфер на по-важните (или по-"шумни") модули. Това може да се изроди до по един буфер и пишещ тред за всеки генериращ обаче... Но и това трябва понякога - практически е еквивален на множество инстанции на демони примерно пишещи в различни файлове в /tmp (съвсем образно). Имам предвид като противоположност или алтернатива на това вадещия тред да е винаги само един.

Ами то няма как да избягаш от синхронизация ако пишеш едновременно от няколко нишки. Може да я преместиш на друго място но пак ще я има.
При мен проблема беше, че се омазваха текстовете в конзолата и без заключване не върши работа ...

Не, имах предвид да ползвам lockless queue за връзката между генериращите и консумиращите тредове, което на нормални архитектури става без нужда от забрана на прекъсванията. Но това е отделна тема.

Поразбутах малко логера си да може да праща UDP пакети вместо да пише само в stderr ... т.е. сложих му един указател към функция да може да се закача допълнителна функционалност. Ако трябва - свиркай. Май ще взема да го изкарам в гитхъб да може лесно да се преизползва, че така с копиране на файлове става хаос. Ти докъде докара твоя проект?

Аз се разрових в по-дълбоки води - има един формат за логове (трейсове) CTF. Не знам преди дали го обсъждахме, но това е нещото което реално ми върши работа. По-познат е от проекти като LTTng. Идеята му е качествена и са реализирали това което търсех - асинхронно логване, при това с дефиниране на различни tracepoints - които описват C структури с полета според нуждите на конкретната точка, която ще логва. Няма смисъл да го описвам подробно - документацията им е на ниво и там по-лесно се разбира. Там са описали и доста имплементационни детайли, които им позволяват да са достатъчно ефективни - например на multicore имат подход с отделни буфери и много други. Имат и глезотии като пращане към/през relay daemon, и много други. Може да го погледнеш във връзка с UDP-то за което споменаваш.
Та за този формат има доста инструментариум, къде покрай LTTng, къде други - включително такива за разглеждане и анализ на логовете (trace compass е един пример), има и конвертиране към други формати.
Всъщност за момента го ползваме за кърнел логване директно - през LTTng (това на линукските ни системи). За user trace има LTTng-ust библиотека, обаче изникват някой други идеи и май за портабилност ще трябва да се въздържим от нея. Но за сметка на това има barectf - библиотека за bare metal за същите цели. Та тоя barectf е нещото, което ползвам в момента.
Разбира се има желание тоя barectf или LTTng да не се превръщат в нещо задължително за нашия код, затова има един слой (API) през който ще минава. Там развитието е в посока да мога да ползвам идеите за отделни "канали" за логването, които да позволят да има разделяне на информацията. В типичните имплементации лог() функциите (макроси) имат аргумент за ниво на трейса/лог-а, формат за принтф и променлив брой аргументи. Аз добавям конктекст - "канал" или "източник" или нещо подобно като смисъл.
Целта е лесна обработка после - кой "модул" е пратил лог-а например - за тези цели по-рано сме ползвали threadId, което е много полезно. Даже lttng (или barectf?) имат тая екстра да добавят това и казват че работи "автоматично" на posix системи. Често обаче в един тред има няколко "логически модула" - това примерно пасва на идеята с __LINE__, __FILE__ и т.н. Само че има и още едно ниво - ако има няколко инстанции на нещо (обекта от един клас) това с __FILE__/__LINE__ не е достатъчно.
Тъй като натискам да се ползва максимално dependency injection съм им подготвил такава постановка - дадения модул декларира (в интерфейса си) колко "канала" за логване/трейсване му трябват. Ако е нещо дребно може да поиска само един канал, ако е примерно нещо комуникационно може да поиска 2 канала - един за TCP примерно и един за UDP (хипотетично, но точно за различни "протоколи" го ползвам сега). Т.е. параметри на "конструктора" (на C е при нас и ползваме аналогични техники) - системата ("dependency injector"-а) осигурява тези хендъли и ги подава при съзадаването на инстанцията. Оттам модула разчита на тях и го предава като контекст на даденото викане на лог() в неговия код.
Съответно системата е свободна да реши че и е през... за тия два "логически" канала и да даде един и същи контекст и на двете места - но модула е осигурил възможност за разделение.
В тоя хендъл (който е непознат като имплементация за модулите) си държа специфичните неща за логването - към къде ще ходи - stream, file или нещо друго. В момента е само FILE* и така мога да работя с файлове или stdout/stderr стриймове.

Като цяло подхода е обърнат спрямо класическият - вместо системата да ми казва "имаш 2 избора - stderr или stdout, избираш и край!" при мен е "аз като приложение имам 7 изходни стрийма с1, с2, ... с7 и ти като система ми го насочи където искаш, ако щеш и в /dev/null...". Тъй де, класическо инвертиране на контрола.

А самото печатане в най-простия си вид е сведено до:

Това fpOutput в случая се вижда че е хендъл отворен с fopen - в един от тестовете например има 3 канала - единия го насочвам към stdout, другите два към два отделни текстови файла.
Това е временен вариант докато приложим barectf-а (или lttng-ust) - за съжаление не е ясно дали другата линия на развой, която ги ползва, ще се приеме окончателно. Но моята тънка сметка е чрез добавянето на тоя контекст да им запаля лампичките че има чалъм да се спестят прехвърляния на много мета-данни, които са известни още по време на компилирането. Тогава всяко печатане може да ползва отделен hCtx който да си е уникален даже до това да включва sFormat и други "константи". Не знам колко е приложимо от практическа гледна точка, но реално утопичната цел може да е всяко едно съобщение (място на викане) да отива в собствена дестинация