Ще го разгледам и ще пиша какви са ми впечатленията

Сега на първо четене:

__FILE__/__LINE__ се получават с addr2line, само че трябва да се пазят някъде дебъг символите или там каквито неща си генерира GCC за да работи и които по принцип като компилираш в release се strip-ват. То затова в тоя логер от който заимствам в началото на всяка сесия се пускаше едно съобщение в лог-а с SHA1 на git commit-а от който е компилирано и после на сървъра всичко се навързваше - но то си е голяма галимация - една камара сървъри - build, log, db, ... но пък като го подкараш почти няма проблем който да не го хванеш.

По отношение на нишки и контекс - thread ID е важно, даже бях направил детектор на dead lock който добавяше състояние на всички нишки в лога със 10-на нива call stack. Та това с call stack си беше изцяло моя доработка - трябваше само да се забрани -fomit-frame-pointer оптимизацията на GCC (те и един линк веднага гуглето откри https://yosefk.com/blog/getting-the-cal ... inter.html ) - което не беше чак толкова голям проблем защото все пак inline-ването не се забранява и като цяло генерирания код си е добре оптимизиран - разликата беше има няма 1% по голям код, с мед да го намажеш. И май ако не бъркам за всяко съобщение в лога накрая също добавях 10 нива на call stack и тогава вече "прогледнахме" какво се случва на полето като нещо запецне - самия фирмуер беше така написан, че ако няколко дни не се свързал със сървъра да си източи логовете спираше да прави всичко друго докето не свърши тази работа и по тоя начин хванахме няколко много гадни бъг-а дето brick-ваха устройства из цял белгистан.

Отрепахме няколко месеца работа но стана пушка. Само дето бизнес модела на фирмата нещо не беше много читав и накрая май след мен му теглиха майните на целия проект (дали и щото не намериха кой да го крепи всичкото щото пък преди да се хвана пак беше до кривата круша) и пуснаха нова версия с някаква готова китайска платка и linux вместо с микроконтролер и RTOS. Въобще тука такова пилеене на средства (пари, човешко време, материали и т.н.) правят понякога, че ми е чудно как успява все пак да съществува икономиката им.

Това с __FILE__ __LINE__ го има в текстовия, Printf-like вариант. За другия не мисля да се боря - или barectf, или lttng-ust - освен ако началството не реши да преоткриваме топлата вода.
В линк който си дал има коментар за google breakpad:
https://chromium.googlesource.com/breakpad/breakpad/+/master/docs/getting_started_with_breakpad.md
На картинката са нарисували това което ние обсъждаме тук Ще го огледам дали нещо може да се открадне (я идея, я код)...

Е, те направо са се оляли - тия minidump-ове които ползват съдържат целите стекове на всяка нишка - това си е за fat clients - за ембедед ми се струва кощунство
Но пък е безценно за анализ на deadlocks, че те са май най-мръсните за оправяне ...

Този пич от линка ти има интересни постове - тук описва "delayed printf":
https://www.embeddedrelated.com/showarticle/518.php
Вместо да прави символни таблици ползва GDB да му върне информацията от елф-а/екзето - пише само поинтъра и разчита че текстовете са константи някъде - т.е. няма да сработи ако си генерираш текст в рам буфер. Но реално и така си е достатъчно.
Не съм убеден че gdb през питон е бърз начин да извадиш текста - поне на ембедед, монолитна система може и по-лесно. Но пък е "елегантно" и работи за всякакви gdb-разбираеми дивотии.

Те на колегите преди мен им е била точно такава идеята - даже вместо адреса на формат стринга записваха адреса взет с __builtin_return_address() с идеята после от него да се види какъв точно е формат стринга от сорса - пък в бинарито даже текстовете са махнати с макроса ... само дето не го бяха направили като хората нито на устройството нито на сървъра - голяма врътня си е. На практика е по лесно да си логваш четливи дебъг съобщения ... и на флаша и на GPRS-а цените падат, закона на Мур се грижи да ни е лесно

Не е точно така - апетитът идва с яденето - моите хора не се свенят да логват и от времекритични места - и с закона на Мур това времекритичното ако се е викало на всеки 500мкс преди години сега го искат на 100 примерно - и бонуса от технологиите хич не ми помага (или поне не стига). Да не говорим че с тия новите мудни ядра ситуацията отида на влошаване - пробвахме нова платформа (линукс на cortex-a9) и се оказа че джитъра на real time-а е почти двойно по-зле от това което имахме в предишната генерация с ARM11... Е, като запали по-бързо свършва работата, ама накрая сме пак откъдето тръгнахме.

Това с логването от критични места си е тънка работа - обикновенно един буфер да се трупа в него и после да се стриймва по някой бавен интерфейс помага. Но идват други усложнения - да отработваш препълнен буфер и т.н. То затова вариантът със записването само на __buildin_return_address() без абсолютно нищо друго хич не е за пренебрегване - трупа ти 4 байта + още 4 евентуално за timestamp. Верно губиш доста от информация ама пак горе долу има поглед какво точно прави желязото. Ама щом търкаляте линукс едва ли имате сериозни ограничения за паметта ...

Да де, и тъкмо с тия няколко аргумента които изреди виждам че lttng е което ни трябва.

Оф - тоая lttng ми седи още в отворен таб в браузъра - даже, вече е 4-5 таба назад, че в момента боря гаден проблем с nodejs garbage collecting - заспива ми целия сървър за 30 секунди и така на всеки няколко минути - и всички кучета дето съм пуснал да дебнат за злосторници почват да лаят ...

4-5 таб-а назад - значи преди 10-тина минути си го отворил
Добро нещо е, за проба тръгва лесно на RPi и даже работи. Има събрани няколко трейса ако искаш просто да разгледаш какво излиза (в Trace Compass-а например) - че аз първо рових за готови трейсове и като не намерих се принудих да си записвам.