Почему я не вижу номера строк в обратной трассировке gdb?

Я не вижу номера строк в gdb. Я скомпилировал все с флагами -g с помощью mpiicc.

gdb не показывает номера строк даже для точек останова.

Может быть, проблема в «Отсутствуют отдельные отладочные данные, используйте: debuginfo-install glibc-2.12-1.166.el6_7.7.x86_64 numactl-2.0.9-2.el6.x86_64», но я не суперпользователь, поэтому я не могу их установить .

 gdb  --args ./central -g 5 51
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/dslavchev/NuclearTesting/MPI/project-a-test-mpi/central...done.
(gdb) break direct.c:55
Breakpoint 1 at 0x40855d: file direct.c, line 55.
(gdb) l direct.c:55
50  
51  void direct(int* N, double **PA, Coord **points)
52  {
53      int     i ,j ,k ,l, ir, irr,
54              md = suma(N , NUM_AIRFOILS) - NUM_AIRFOILS,
55              m;
56      double  *D, // **D,
57              *A, *sv;
58  
59      int matrix_size_D = md*md;
(gdb) r
Starting program: /home/dslavchev/NuclearTesting/MPI/project-a-test-mpi/central -g 5 51
[Thread debugging using libthread_db enabled]

Breakpoint 1, 0x000000000040855d in direct ()
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.166.el6_7.7.x86_64 numactl-2.0.9-2.el6.x86_64
(gdb) bt
#0  0x000000000040855d in direct ()
#1  0x0000000000405ee9 in main ()
(gdb) s
Single stepping until exit from function direct,
which has no line number information.
PMPI_Comm_size (comm=1140850688, size=0x7fffffffc240) at ../../src/mpi/comm/comm_size.c:57
57  ../../src/mpi/comm/comm_size.c: No such file or directory.
    in ../../src/mpi/comm/comm_size.c
(gdb) s
65  in ../../src/mpi/comm/comm_size.c
(gdb) s
57  in ../../src/mpi/comm/comm_size.c
(gdb) 
58  in ../../src/mpi/comm/comm_size.c
(gdb) 
59  in ../../src/mpi/comm/comm_size.c
(gdb) 
65  in ../../src/mpi/comm/comm_size.c
(gdb) 

Вот команды сборки:

mpiicc -g -c -o central.o central.c -qopenmp 
mpiicc -g -c -o contours.o contours.c -qopenmp 
mpiicc -g -c -o mymath.o mymath.c -qopenmp 
mpiicc -g -c -o vort.o vort.c -qopenmp 
mpiicc -g -qopenmp   -I/opt/intel/parallel_studio_xe_2017.2.050/compilers_and_libraries_2017/linux/mkl/include -c -o  direct.o direct.c 
mpiicc -g -c -o a_liftarg.o a_liftarg.c -qopenmp 
mpiicc -g -c -o psavel.o psavel.c -qopenmp 
mpiicc -g -c -o euler.o euler.c -qopenmp 
mpiicc -g -c -o streamline.o streamline.c -qopenmp 
mpiicc -g -c -o speedmap.o speedmap.c -qopenmp 
mpiicc -g -o central central.o contours.o mymath.o vort.o direct.o a_liftarg.o psavel.o euler.o streamline.o speedmap.o /opt/intel/parallel_studio_xe_2017.2.050/compilers_and_libraries_2017/linux/mkl/lib/intel64/libmkl_scalapack_lp64.a -Wl,--start-group /opt/intel/parallel_studio_xe_2017.2.050/compilers_and_libraries_2017/linux/mkl/lib/intel64/libmkl_intel_lp64.a /opt/intel/parallel_studio_xe_2017.2.050/compilers_and_libraries_2017/linux/mkl/lib/intel64/libmkl_intel_thread.a /opt/intel/parallel_studio_xe_2017.2.050/compilers_and_libraries_2017/linux/mkl/lib/intel64/libmkl_core.a /opt/intel/parallel_studio_xe_2017.2.050/compilers_and_libraries_2017/linux/mkl/lib/intel64/libmkl_blacs_intelmpi_lp64.a -Wl,--end-group -liomp5 -lpthread -lm -ldl -qopenmp
I have compiled everything with -g flags - нет. Вы не компилировали glibc, вы использовали glibc, предоставляемый вашей системой. И это предоставляется без отладочной информации.
KamilCuk 29.05.2019 19:54

Это не имеет значения. Номера строк отсутствуют в пользовательском коде в файле direct.c.

ks1322 29.05.2019 20:46

@ Камил Кук Меня не интересует отладка glibc. Моя настоящая проблема — это ошибка сегментации, которую я не мог отследить, потому что отладчик не мог показать мне значимую информацию об отслеживании. отладка printf выиграла для меня.

Dimitar Slavchev 30.05.2019 14:53
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
2
3
3 123
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Попробуйте добавить флаг

-debug expr-source-pos

Он должен добавить информацию о строке

https://software.intel.com/en-us/cpp-compiler-developer-guide-and-reference-debug-linux-and-macos

Ответ принят как подходящий

May be the problem is

Нет: проблема не в этом (ни main, ни direct не определены в libc).

Похоже, это ошибка в GDB: прежде чем вы выполните run, он точно знает, что адрес 0x40855d соответствует direct.c, line 55.

Но после run оно как-то забывает, что знало это.

Вашей версии GDB тоже 9 лет. В качестве первого шага предлагаю собрать текущую версию (8.3 на сегодняшний день).

Честно говоря, я не уверен, что это правильный ответ, но я подозреваю, что виноват старый gdb. В конце концов я решил проблему с отладкой printf.

Dimitar Slavchev 03.11.2020 11:46

Другие вопросы по теме