Не правильный путь к исходному файлу! # gdb -q eu-stack Reading symbols from eu-stack... Reading symbols from /usr/lib/debug/usr/bin/eu-stack.debug... (gdb) b main Breakpoint 1 at 0x402450: file ../../src/stack.c, line 632. (gdb) list 1 <built-in>: Нет такого файла или каталога. Нет удобной утилиты посмотреть список исходников (*), поэтому так: # gdb --batch -ex 'i sources' /usr/lib/debug/usr/bin/eu-stack.debug Source files for which symbols have been read in: Source files for which symbols will be read in on demand: /usr/src/debug/glibc-2.30-alt2/csu/../sysdeps/x86_64/crtn.S, /usr/src/debug/glibc-2.30-alt2/csu/elf-init.c, /usr/include/bits/stdio2.h, /usr/src/debug/elfutils-0.182-alt2/build-x86_64-alt-linux/lib/../../lib/printversion.c, /usr/include/bits/fcntl2.h, /usr/include/stdlib.h, /usr/include/bits/error.h, /usr/src/debug/elfutils-0.182-alt2/build-x86_64-alt-linux/src/../../src/stack.c, /usr/src/debug/glibc-2.30-alt2/csu/../sysdeps/x86_64/crti.S, /usr/src/debug/glibc-2.30-alt2/csu/init.c, /usr/src/debug/glibc-2.30-alt2/csu/../sysdeps/x86_64/start.S Нам нужен stack.c, в том виде как его показал gdb его нет: # ls -l /usr/src/debug/elfutils-0.182-alt2/build-x86_64-alt-linux/src/../../src/stack.c ls: невозможно получить доступ к '/usr/src/debug/elfutils-0.182-alt2/build-x86_64-alt-linux/src/../../src/stack.c': Нет такого файла или каталога Сам исходник, при этом, есть где надо: # find /usr/src/debug -name stack.c | grep elfutils /usr/src/debug/elfutils-0.182-alt2/src/stack.c С точки зрения debugedit путь правильный: /usr/lib/debug/usr/bin# /usr/lib/rpm/debugedit -l /dev/stdout ./eu-stack.debug | xargs -0 | tr ' ' '\n' | grep stack /usr/src/debug/elfutils-0.182-alt2/src/stack.c * Как показывают путь другие утилиты: # objdump -Wi /usr/lib/debug/usr/bin/eu-stack.debug | fgrep stack.c <a1> DW_AT_name : (косвенная строка, смещение: 0x19ec): ../../src/stack.c # /usr/bin/llvm-dwarfdump -debug-info /usr/lib/debug/usr/bin/eu-stack.debug | fgrep stack.c | head -2 DW_AT_name ("../../src/stack.c") DW_AT_decl_file ("/usr/src/debug/elfutils-0.182-alt2/build-x86_64-alt-linux/src/../../src/stack.c") Более полный вывод llvm-dwarfdump для этого объекта: 0x0000009b: DW_TAG_compile_unit DW_AT_producer ("GNU C99 9.3.1 20200518 (ALT Sisyphus 9.3.1-alt1) -fstack-protector-strong -mtune=generic -march=x86-64 -g -O2 -std=gnu99 -fre switches -fexceptions") DW_AT_language (DW_LANG_C99) DW_AT_name ("../../src/stack.c") DW_AT_comp_dir ("/usr/src/debug/elfutils-0.182-alt2/build-x86_64-alt-linux/src") DW_AT_ranges (0x00000940 [0x0000000000402830, 0x0000000000403a15) [0x0000000000402440, 0x000000000040244a) [0x0000000000402450, 0x0000000000402745)) DW_AT_low_pc (0x0000000000000000) DW_AT_stmt_list (0x000000ea)
Несколько пакетов, которые я посмотрел - собранные autotools не прямо в $RPM_BUILD_DIR, а в подкаталоге - так. А с cmake - собранные в BUILD - проблем нет.
(In reply to Vitaly Chikunov from comment #1) > Несколько пакетов, которые я посмотрел - собранные autotools не прямо в > $RPM_BUILD_DIR, а в подкаталоге - так. А с cmake - собранные в BUILD - > проблем нет. Потому что autotools собирает так (относительный путь к stack.c): x86_64-alt-linux-gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='"/usr/share/locale"' -DDEBUGPRED=0 -DSRCDIR=\"/usr/src/RPM/BUILD/elfutils-0.182-alt2/src\" -DOBJDIR=\"/usr/src/RPM/BUILD/elfutils-0.182-alt2/build-x86_64-alt-linux/src\" -I. -I../../src -I.. -I. -I../../src -I../../lib -I.. -I../../src/../libelf -I../../src/../libebl -I../../src/../libdw -I../../src/../libdwelf -I../../src/../libdwfl -I../../src/../libasm -std=gnu99 -Wall -Wshadow -Wformat=2 -Wold-style-definition -Wstrict-prototypes -Wtrampolines -Wlogical-op -Wduplicated-cond -Wnull-dereference -Wimplicit-fallthrough=5 -Werror -Wunused -Wextra -Wstack-usage=262144 -D_FORTIFY_SOURCE=2 -pipe -frecord-gcc-switches -Wall -g -O2 -fexceptions -MT stack.o -MD -MP -MF .deps/stack.Tpo -c -o stack.o ../../src/stack.c А cmake так (абсолютный путь к main.cpp): /usr/bin/clang++ -DBUILD_DATE=\"20201102\" -DBUILD_VERSION=\"\" -DISPC_ANDROID_TARGET_OFF -DISPC_FREEBSD_TARGET_OFF -DISPC_IOS_TARGET_OFF -DISPC_MACOS_TARGET_OFF -DISPC_NO_DUMPS -DISPC_PS4_TARGET_OFF -DISPC_WINDOWS_TARGET_OFF -DISPC_X86_ENABLED -DLLVM_10_0 -D_FORTIFY_SOURCE=2 -I/include -I/usr/src/RPM/BUILD/ispc-1.14.1/src -I/usr/src/RPM/BUILD/ispc-1.14.1/BUILD/. -pipe -frecord-gcc-switches -Wall -g -O2 -O2 -g -Wall -Wno-sign-compare -Wno-unused-function -Werror -I/usr/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fstack-protector-strong -fdata-sections -ffunction-sections -fno-delete-null-pointer-checks -Wformat -Wformat-security -fpie -fwrapv -Wno-c99-extensions -Wno-deprecated-register -fno-rtti -std=c++14 -o CMakeFiles/ispc.dir/src/main.cpp.o -c /usr/src/RPM/BUILD/ispc-1.14.1/src/main.cpp
Чтоб понять исправлена ли эта ошибка в апстриме debugiedit, нашел пакет собранный с ../configure в Федоре -- gnuplot. У них тоже остается "../../src" в Directory Table (в .debug_line), так что пути к исходникам его содержат. Но, в отличии от нас, нужные пустые диры запакованы. Таким образом путь с "../../src" не дает ошибки. % objdump -Wl ./usr/lib/debug/usr/bin/gnuplot-qt-5.2.8-6.fc33.x86_64.debug ... The Directory Table (offset 0x1b): 1 ../../src 2 ../../term 3 /usr/include/bits 4 /usr/include ... (gdb) i sources ... /usr/src/debug/gnuplot-5.2.8-6.fc33.x86_64/minimal/src/../../src/qtterminal/QtGnuplotEvent.h ... % less gnuplot-debugsource-5.2.8-6.fc33.x86_64.rpm ... drwxr-xr-x 2 root root 0 авг 6 05:22 /usr/src/debug/gnuplot-5.2.8-6.fc33.x86_64 drwxr-xr-x 2 root root 0 авг 6 05:22 /usr/src/debug/gnuplot-5.2.8-6.fc33.x86_64/minimal drwxr-xr-x 2 root root 0 авг 6 05:20 /usr/src/debug/gnuplot-5.2.8-6.fc33.x86_64/minimal/src drwxr-xr-x 2 root root 0 авг 6 05:22 /usr/src/debug/gnuplot-5.2.8-6.fc33.x86_64/qt ... -rw-r--r-- 1 root root 5158 дек 22 2017 /usr/src/debug/gnuplot-5.2.8-6.fc33.x86_64/src/qtterminal/QtGnuplotEvent.h ...
Задание #261678: rpm-build.git=4.0.4-alt155 elfutils.git=0.182-alt2 - сделано как в Fedora - запакованы пустые диры в /usr/src/debug. До изменений: # gdb -q eu-stack Reading symbols from eu-stack... Reading symbols from /usr/lib/debug/usr/bin/eu-stack.debug... (gdb) b main Breakpoint 1 at 0x402450: file ../../src/stack.c, line 632. (gdb) list 1 <built-in>: Нет такого файла или каталога. (gdb) list main 627 ../../src/stack.c: Нет такого файла или каталога. (gdb) r Starting program: /usr/bin/eu-stack [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, main (argc=1, argv=0x7fffffffe3f8) at ../../src/stack.c:632 632 in ../../src/stack.c (gdb) list 627 in ../../src/stack.c (gdb) После сборки elfutils/eu-stack rpm-build'ом из задания: # gdb -q eu-stack Reading symbols from eu-stack... Reading symbols from /usr/lib/debug/usr/bin/eu-stack.debug... (gdb) b main Breakpoint 1 at 0x402450: file ../../src/stack.c, line 632. (gdb) list 1 <built-in>: Нет такого файла или каталога. (gdb) list main 627 return 0; 628 } 629 630 int 631 main (int argc, char **argv) 632 { 633 /* We use no threads here which can interfere with handling a stream. */ 634 __fsetlocking (stdin, FSETLOCKING_BYCALLER); 635 __fsetlocking (stdout, FSETLOCKING_BYCALLER); 636 __fsetlocking (stderr, FSETLOCKING_BYCALLER); (gdb) r Starting program: /usr/bin/eu-stack [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, main (argc=1, argv=0x7fffffffe3c8) at ../../src/stack.c:632 632 { (gdb) list 627 return 0; 628 } 629 630 int 631 main (int argc, char **argv) 632 { 633 /* We use no threads here which can interfere with handling a stream. */ 634 __fsetlocking (stdin, FSETLOCKING_BYCALLER); 635 __fsetlocking (stdout, FSETLOCKING_BYCALLER); 636 __fsetlocking (stderr, FSETLOCKING_BYCALLER); (gdb) Исходники стали отображаться. (ps. Почему у нас list по-умолчанию пытается показать некое 1 <built-in> не понятно. Думаю, это какая-то другая проблема.)
`list` по-умолчанию ведет себя странно и в Fedora, но иначе: [root@a7a0fa830f90 /]# gdb -q eu-stack Reading symbols from eu-stack... Reading symbols from /usr/lib/debug/usr/bin/eu-stack-0.182-1.fc33.x86_64.debug... (gdb) i line No line number information available. (gdb) list 618 619 /* Makes sure we are properly attached. */ 620 if (dwfl_pid (dwfl) < 0) 621 error (EXIT_BAD, 0, "dwfl_pid: %s\n", dwfl_errmsg (-1)); 622 break; 623 624 default: 625 return ARGP_ERR_UNKNOWN; 626 } 627 return 0; (gdb) i line Line 618 of "stack.c" is at address 0x302e <parse_opt+286> but contains no code. (gdb) list 628 } 629 630 int 631 main (int argc, char **argv) 632 { 633 /* We use no threads here which can interfere with handling a stream. */ 634 __fsetlocking (stdin, FSETLOCKING_BYCALLER); 635 __fsetlocking (stdout, FSETLOCKING_BYCALLER); 636 __fsetlocking (stderr, FSETLOCKING_BYCALLER); 637 То есть показывает какую-то строку выше main, но из правильного исходника. А у нас, если так сделать, то "показывает" `Line 1 of "../sysdeps/x86_64/start.S"`.
rpm-build-4.0.4-alt155 -> sisyphus: Thu Nov 12 2020 Vitaly Chikunov <vt@altlinux> 4.0.4-alt155 - debugedit: Fix 'Unhandled relocation 0 in .debug_info section' on e2k. - debuginfo: Fix source paths with `..` by creating appropriate empty dirs under `/usr/src/debug` tree (closes: #39175).
JFYI. В gdb-10 list по-умолчанию стал показывать (вместо '1 <built-in>: Нет такого файла или каталога.') часть исходника рядом с main. \o/ # gdb -q --args eu-stack Reading symbols from eu-stack... Reading symbols from /usr/lib/debug/usr/bin/eu-stack.debug... (gdb) list 618 619 /* Makes sure we are properly attached. */ 620 if (dwfl_pid (dwfl) < 0) 621 error (EXIT_BAD, 0, "dwfl_pid: %s\n", dwfl_errmsg (-1)); 622 break; 623 624 default: 625 return ARGP_ERR_UNKNOWN; 626 } 627 return 0;
