Добрый день. Нету желающего поучаствовать в разработке библиотеки трассировки вызова

функций?

Идея в создании библиотеки, с которой необходимо слинковаться и интерфейса под отображение информации трассировки. Знаю, как такое провернуть под gcc/clang, но msvc видимо не позволяет или хз.

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

Библиотека предполагается практически полностью/полностью свободной (MIT/Apache 2.0, например).

Интерфейс будет на Qt, поэтому его знание на мин. уровне тоже важно. Если интересно, то буду рад 1-2 участникам, вводную инфу я соответственно распишу, чтобы копать не надо было долго. Спасибо

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

На основе этой инструментации и будет. Что то забыл дописать

Можно сделать гораздо лучше, если инструментацию вставлять не в ассемблер, а прямо в исходный код. libclang позволяет. Там есть компонент "rewriter" для того. Потом текст (с инструментацией) компилировать можно хоть msvc.

Еще можно посмотреть в сторону TXL (вроде, txl.ca), но он грамматику современного c++ не осилит имхо

если они специально С++ не поддерживают, то не осилят, да грамматика С++, к сожалению, шире, чем содержимое annex A (grammar summary)

Его я не пробовал, но пробовал копать в сторону плагинов для clang. Та еще яма(имхо). Да и в чем отлижие между libclang и -finstrument-functions на уровне накладных расходов? Как я понял одно и тоже. А аргументы я думал из символов отладки подтягивать, хотя тут да, может быть посложнее

я сделал на libclang. для голого C правда. не поддерживаются вычисления в коде исполняемом до функции (когда размер массива в аргументе функции -- выражение вычисляемое в рантайме). В C++ аналогично, в конструкторах инициализация членов класса делается как бы до начала тела функции конструктора. Кажется не очень сложно доделать. Там твой визитор вызывают для каждого грамматического элемента. Соответственно в начало и конец функции, перед/после фигурных скобок втыкается инструментация. Еще в return. Еще в throw надо, в catch, про конструкторы сказал, еще try-блоки которые вокруг всей функции (до фигурных скобок). С аегументами и возвращаемыми значениями просто, их нужно просто перечислить и передать в макрос, там уже средствами настоящего компилятора запишется как и куда нужно. В целом трансформация кода ограничивается вставкой вызова макросов в нужных местах. Там какой-то мудрой логики -- нет.

Отличие в том, что в случае с -finstrument-functions аргументы не пойми где лежат (в регистрах, стеке, везде по-разному). А так компилятору будет дан код который с ними будет что-то делать и онсам что надо и куда надо положит. Потом с -finstrunent... компилятор вынужден при вызове функций инструментации сохранять все регистры которые по ABI могут портиться. Когда инструментация встроена в код, он уже знает что (не) портится. Вообще для инструментации на уровне ассемблера я бы рекомендовал обратить взор на функцию mcount (опция -pg). Но с ней проблема с tail call optimization и решения там кажутся не нормальными.

Я в плане документации имел ввиду. Много недокументированных функций и структур попадались,поэтому забросил. Но мб ещё раз посмотрю. А за инфу спасибо. Подумаю над этим