Вы не используете редактор исходного кода (даже VSCode) для отладки core dump (поскольку файл core не имеет текстовый формат). Вы используете gdb (или, возможно, какой-либо другой отладчик , такой как lldb ). У GDB есть очень хорошее руководство пользователя , которое я настоятельно рекомендую прочитать. Вы также не используете VSCode для компиляции своего кода C ++, но компилятор , такой как GCC или Clang (возможно, VSCode может быть настроен для запуска g++ для вас).
Вам также не нужно специально генерировать дамп ядра. Часто бывает проще установить точку останова в gdb. Вы можете создать ядро работающего процесса, используя gcore (1) . Вы можете присоединить gdb к запущенному процессу, используя параметр -p gdb (1) . Я вижу очень мало случаев, когда создание дампов ядра специально полезно. Но, конечно, abort (3) (также используется assert (3) ) генерирует дамп core.
Ваше приложение лучше скомпилировать (используя опцию -g для GCC или Clang) с DWARF отладочной информацией. Предположим, что исполняемый файл вашего приложения представляет собой исполняемый файл yourapp. Затем вы отлаживаете дамп ядра (файл core см. В core (5) ; обратите внимание, что gdb (1) упоминается в core (5)). man страница, заданная командой man core) с использованием gdb yourapp core
Некоторые редакторы исходного кода могут работать с gdb (мой редактор emacs и способен работать с gdb с M-x gdb). Вы должны погрузиться в документацию вашего редактора исходного кода, чтобы понять, как это сделать.
Но я рекомендую использовать gdb в командной строке терминала. Это очень удобный инструмент. См. этот ответ на связанный вопрос.
gdb использует очень низкий уровень ptrace (2) системный вызов для установки точек останова и т. Д. И т. П. Вам почти никогда не понадобится ptrace (кроме случаев, когда вы пишете свой собственный отладчик, который может занять годы работы), но вы используете gdb, который использует ptrace.
PS. Как запустить gdb из VSCode - это другой вопрос. Поскольку я не использую VSCode, я не могу ответить на него. И это может даже не стоить делать. Даже с 30-летним опытом работы emacs я часто запускаю gdb в терминале. Поскольку это проще, чем запускать его из emacs (или VSCode).
NB. В наши дни, в 2019 году, «редактор исходного кода» является почти синонимом « IDE ». Оба положения на практике относятся к одним и тем же продуктам, но они различаются по способу их представления. Вы можете назвать emacs IDE, я (и сообщество GNU) предпочитаю называть его редактором исходного кода, но мы оба будем использовать его для одних и тех же вещей: приятного написания, просмотра и работы над исходный код , сборка и отладка.