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

hello.h:

extern"C" int f(int i);

#define F(x) f(\
f(\
f(\
f(\
x))))

hello.cpp:

#include "hello.h"
 
int main(int argc, char** argv)
{
  int x=F(42);
  return x+5;
}

Далее

clang hello.cpp -o hello.ll -S -emit-llvm  -target i386-pc-windows -g

В лл вижу

%7 = call i32 @f(i32 42), !dbg !19
  %8 = call i32 @f(i32 %7), !dbg !19
  %9 = call i32 @f(i32 %8), !dbg !19
  %10 = call i32 @f(i32 %9), !dbg !19

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

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

Я при развороте тела макроса честно прописываю строку и колонну каждого токена. Но если макрос находится в другом файле, то отладчик итерируется по линиям и колоннам не того файла, в котором макрос, а того файла, который вызвал макрос. Потому что codeview (мне нужен именно он, так как мсвс) не позволяет задавать каждой инструкции свой файл.

Если ли компилятор/отладчик, который позволяет ставить брекпоинты внутри макроса? И как выглядит его отладочная инфа?
Как в том же D выглядит отладка кода, находящегося в сгенерированной строке?

Здравствуйте, T4r4sB, Вы писали:

TB>то есть всё тело макроса относится к одной дебаг локации
TB>Это значит, что я не могу поставить брекпоинт внутрь макроса в любое место.
Конечно не можете это же будет одна строка.

TB>Я при развороте тела макроса честно прописываю строку и колонну каждого токена. Но если макрос находится в другом файле, то отладчик итерируется по линиям и колоннам не того файла, в котором макрос, а того файла, который вызвал макрос. Потому что codeview (мне нужен именно он, так как мсвс) не позволяет задавать каждой инструкции свой файл.

TB>Если ли компилятор/отладчик, который позволяет ставить брекпоинты внутри макроса? И как выглядит его отладочная инфа?
TB>Как в том же D выглядит отладка кода, находящегося в сгенерированной строке?
Нету.
Но можно отлаживать не исходник, а то что выкатит препроцессор.
А еще лучше отформатировать апосля.

gcc -E hello.c

# 1 "hello.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "hello.c"
# 1 "hello.h" 1
extern"C" int f(int i);
# 2 "hello.c" 2

int main(int argc, char** argv)
{
  int x=f(f(f(f(42))));
  return x+5;
}

ps: поиск тут не работает но была тут как-то такая тема: отладчики не нужны

Здравствуйте, kov_serg, Вы писали:

_>Нету.не нужны

Жееееесть, за столько лет они не почесались добавить возможность указывать отдельный файл каждой строке.

Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, kov_serg, Вы писали:

_>>Нету.не нужны

TB>Жееееесть, за столько лет они не почесались добавить возможность указывать отдельный файл каждой строке.


Не понял, кто не почесался? И что значит: "отдельный файл каждой строке"?

Вообще, если говорить о сишных макросах, то они работают до фазы собственно компиляции, это практически текстовая подстановка с небольшими сишными нюансами. Многострочных макросов в сишечке нет — есть символ '\' в конце строки, который работает везде в сишном коде и говорит о том, что следующая строка является продолжением текущей.

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

Здравствуйте, Marty, Вы писали:

M>Не понял, кто не почесался? И что значит: "отдельный файл каждой строке"?

Это значит, что при генерации дебажной инфы ты каждой возможной точке останова прописываешь её положение: линию, колонну. При этом файл указать нельзя. Всё тело функции — в одном файле (((

M>Вообще, если говорить о сишных макросах, то они работают до фазы собственно компиляции, это практически текстовая подстановка с небольшими сишными нюансами. Многострочных макросов в сишечке нет — есть символ '\' в конце строки, который работает везде в сишном коде и говорит о том, что следующая строка является продолжением текущей.

Этот факт вообще не помогает отладке.

M>Немного не понял, что ты там вообще делаешь, можно попробовать при реализации препроцессора не убирать переводы строки в дефайнах, но тут надо учитывать, что внутри дефайна может быть строковый литерал, который в сорце раскинулся на несколько строк

Да хоть убирай, хоть не убирай. Получается, что невозможно в режиме clang -gcodeview заставить отладчик полноценно проходить по блоку, подставляемому из другого файла.
Только если генерировать файл с подстановками, куда-то сохранять и отлаживаться по нему. Но это такая дичь(

Здравствуйте, T4r4sB, Вы писали:

TB>Да хоть убирай, хоть не убирай. Получается, что невозможно в режиме clang -gcodeview заставить отладчик полноценно проходить по блоку, подставляемому из другого файла.
Ходите отладчиком по коду — IDA наще всё.
А так есть еще логи, тесты и декомпозиция.

TB>Только если генерировать файл с подстановками, куда-то сохранять и отлаживаться по нему. Но это такая дичь(
Добавлю дичи:

cat hello.c | sed -E 's/^(\s*#\s*include\s*<)/\/\/--uid12345--\1/' | gcc -E -CC -x c++ - | sed 's/\/\/--uid12345--//'

Здравствуйте, kov_serg, Вы писали:

_>Ходите отладчиком по коду — IDA наще всё.
_>А так есть еще логи, тесты и декомпозиция.

Ты не о том.
Моя задача — научить компилятор генерировать дебажную инфу для макросов. Формат codeview имеет дурацкие ограничения, которые не дают это делать, оказывается.

Здравствуйте, T4r4sB, Вы писали:

TB>то есть всё тело макроса относится к одной дебаг локации
TB>Это значит, что я не могу поставить брекпоинт внутрь макроса в любое место.
TB>На самом деле я сто лет не писал на крестах, я принимаю участие в разработке собственного убийцы С++, где такое макропрограммирование вовсю используется в метапрограммировании наряду с шаблонами, статической генерацией текста программы итд.
TB>И я не знаю, как мне генерить дебаг инфу.
Без отдельного шага препроцессинга это не сделать.
Добавь в конец каждой строчки макроса какой нить плейсхолдер, к примеру: PP_LINE_TERMINATOR
Потом на специальном шаге своего препроцессора менаешь плейсхолдер на перевод строки — профит.

TB>Я при развороте тела макроса честно прописываю строку и колонну каждого токена. Но если макрос находится в другом файле, то отладчик итерируется по линиям и колоннам не того файла, в котором макрос, а того файла, который вызвал макрос. Потому что codeview (мне нужен именно он, так как мсвс) не позволяет задавать каждой инструкции свой файл.
А если макрос вообще в теле функции в хедере вызван был, который может подключаться к десяткам cpp, то что? Там и без переводов строк были проблемы с определением в каком файле реально "выполняется" макрос.

Здравствуйте, Vain, Вы писали:

V>Без отдельного шага препроцессинга это не сделать.
V>Добавь в конец каждой строчки макроса какой нить плейсхолдер, к примеру: PP_LINE_TERMINATOR
V>Потом на специальном шаге своего препроцессора менаешь плейсхолдер на перевод строки — профит.

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

V>А если макрос вообще в теле функции в хедере вызван был, который может подключаться к десяткам cpp, то что? Там и без переводов строк были проблемы с определением в каком файле реально "выполняется" макрос.

А проблема в чём? Ну дебажная инфа десятков цпп будет содержать локации, ссылающиеся на этот хедер. Почему это должно быть проблемой?

Здравствуйте, T4r4sB, Вы писали:

V>>А если макрос вообще в теле функции в хедере вызван был, который может подключаться к десяткам cpp, то что? Там и без переводов строк были проблемы с определением в каком файле реально "выполняется" макрос.
TB>А проблема в чём? Ну дебажная инфа десятков цпп будет содержать локации, ссылающиеся на этот хедер. Почему это должно быть проблемой?
Как? Хедер одни, а цпп не один. Уже нестыковочка.

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, T4r4sB, Вы писали:

V>>>А если макрос вообще в теле функции в хедере вызван был, который может подключаться к десяткам cpp, то что? Там и без переводов строк были проблемы с определением в каком файле реально "выполняется" макрос.
TB>>А проблема в чём? Ну дебажная инфа десятков цпп будет содержать локации, ссылающиеся на этот хедер. Почему это должно быть проблемой?
V>Как? Хедер одни, а цпп не один. Уже нестыковочка.

В чём нестыковочка-то? Что мешает создать на каждый цпп по 100500 дебажных ll, в которых есть ссылки на один и тот же хедер? Меня ктулху съест за это?

Здравствуйте, T4r4sB, Вы писали:

V>>>>А если макрос вообще в теле функции в хедере вызван был, который может подключаться к десяткам cpp, то что? Там и без переводов строк были проблемы с определением в каком файле реально "выполняется" макрос.
TB>>>А проблема в чём? Ну дебажная инфа десятков цпп будет содержать локации, ссылающиеся на этот хедер. Почему это должно быть проблемой?
V>>Как? Хедер одни, а цпп не один. Уже нестыковочка.
TB>В чём нестыковочка-то? Что мешает создать на каждый цпп по 100500 дебажных ll, в которых есть ссылки на один и тот же хедер? Меня ктулху съест за это?
Э, речь про препроцесс макрос была, где там ты создавать будешь, если макрос уже написан без всяких дебаг ссылок? Или это не препроцесс макрос тогда.

Здравствуйте, Vain, Вы писали:

V>Э, речь про препроцесс макрос была, где там ты создавать будешь, если макрос уже написан без всяких дебаг ссылок? Или это не препроцесс макрос тогда.

Макрос написан в текстовом виде *.h файле допустим.
Ты из *.cpp вызываешь макрос.
Ты компилируешь этот *.cpp, создавая *.ll с дебажной инфой.
В этой дебажной инфе проставляешь каждой строке ссылки на фрагменты текста макроса.
Как-то так должно работать.
Ты дебажную инфу сам генерил?

Здравствуйте, T4r4sB, Вы писали:

V>>Э, речь про препроцесс макрос была, где там ты создавать будешь, если макрос уже написан без всяких дебаг ссылок? Или это не препроцесс макрос тогда.
TB>Макрос написан в текстовом виде *.h файле допустим.
TB>Ты из *.cpp вызываешь макрос.
TB>Ты компилируешь этот *.cpp, создавая *.ll с дебажной инфой.
TB>В этой дебажной инфе проставляешь каждой строке ссылки на фрагменты текста макроса.
TB>Как-то так должно работать.
TB>Ты дебажную инфу сам генерил?
Мы всё ещё про С++ говорим или это какой-то новый вариант использования макросов? Каким образом проставляешь, если уже компиляция пошла и она не в курсе какая строка макроса к какому файлу принадлежит?
Макрос в С++ это просто кусок текста без каких либо ссылок.

Здравствуйте, Vain, Вы писали:

V>Мы всё ещё про С++ говорим или это какой-то новый вариант использования макросов? Каким образом проставляешь, если уже компиляция пошла и она не в курсе какая строка макроса к какому файлу принадлежит?
V>Макрос в С++ это просто кусок текста без каких либо ссылок.

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

макросы как я помню содержат только одну строку
т.е. нельзя выставить локацию в одной строке длинной в километр

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

Здравствуйте, T4r4sB, Вы писали:

V>>Мы всё ещё про С++ говорим или это какой-то новый вариант использования макросов? Каким образом проставляешь, если уже компиляция пошла и она не в курсе какая строка макроса к какому файлу принадлежит?
V>>Макрос в С++ это просто кусок текста без каких либо ссылок.
TB>А, ок, я понял. Исходник макроса пропадает при препроцессинге, копируясь внутрь нужного цпп, поэтому на него нельзя проставлять ссылки.
TB>Но нет, я не понял. Кто мешает при препроцессинге выставлять вставленным строчкам макроса дебажные локации, ссылающиеся на файл, содержащий исходник макроса?
Так это просто кусок текста состоящий из кусков текста без всяких линий и файлов. Один макрос может состоять из других, которые сами по себе не образуют ни линию, ни блок текста, пока полного раскрытия не произойдёт.

Здравствуйте, Vain, Вы писали:

V>Так это просто кусок текста состоящий из кусков текста без всяких линий и файлов. Один макрос может состоять из других, которые сами по себе не образуют ни линию, ни блок текста, пока полного раскрытия не произойдёт.

Что мешает препроцессору запоминать происхождения каждого куска текста и выставлять линию и колонну в результирующем файле?
Это если говорить про С++.
А другие языки имеют право собирать тело единой функции из разных файлов.

Здравствуйте, T4r4sB, Вы писали:

_>>Нету.не нужны
TB>Жееееесть, за столько лет они не почесались добавить возможность указывать отдельный файл каждой строке.
А как справляется компилятор с директивой #line, в которой как бы и указывается и номер строки и имя файла? Неужто в дебаг инфе не оказывается нужной информации?

Здравствуйте, T4r4sB, Вы писали:

V>>Так это просто кусок текста состоящий из кусков текста без всяких линий и файлов. Один макрос может состоять из других, которые сами по себе не образуют ни линию, ни блок текста, пока полного раскрытия не произойдёт.
TB>Что мешает препроцессору запоминать происхождения каждого куска текста и выставлять линию и колонну в результирующем файле?
Потому-что это не компилятор, и он таки расставляет, но при раскрытии инклудов (#include ...) а не макросов. И только для строк, колонны как понимаю не поддерживаются в отладчиках, да и не понятно как их поддерживать нормально без горы геморроя в использовании.

TB>Это если говорить про С++.
TB>А другие языки имеют право собирать тело единой функции из разных файлов.
Это просто текст, препроцессор ничего не знает про функции, это вообще фича препроцессора.