Início / unix / Perguntas / 792721
Accepted
sdbbs
Asked: 2025-03-20 04:25:03 +0800 CST

Como descobrir qual pacote Debian pode incluir um determinado arquivo de origem?

  • 772

Gostaria de depurar meu aplicativo em gdb, porém com fontes completas de algumas bibliotecas de sistema que eu possa precisar. Por exemplo, em um certo ponto do meu processo de depuração em gdb, chego a uma situação como:

...
(gdb) si
0x00047e28 in std::thread::detach() ()
(gdb) c
Continuing.
...
Thread 1 "myProject" received signal SIGABRT, Aborted.
raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

Não tenho certeza do motivo pelo qual std::thread::detach()não recebo uma sugestão de arquivo de origem (pesquisei manualmente online e descobri que está em libstdc++-v3/src/c++11/thread.cc ), mas raise()recebo o arquivo de origem e a linha ../sysdeps/unix/sysv/linux/raise.c:51.

De qualquer forma, para qualquer um desses, thread.ccou raise.c, como posso descobrir qual pacote de origem em um determinado Debian os inclui? Então eu poderia eventualmente obtê-los apt source [package]e fornecer o caminho para esses arquivos gdbconforme descrito em https://stackoverflow.com/questions/48278881/gdb-complaining-about-missing-raise-c/48287761#48287761 para que eu pudesse percorrer as linhas de origem (e especialmente ver qual função subjacente recebe como argumentos do meu código) ...

Eu tentei apt-file, mas parece que não funciona com pacotes de origem:

$ apt-file search raise.c
gnulib: /usr/share/gnulib/lib/raise.c
gnulib: /usr/share/gnulib/tests/test-raise.c

Legal, mas nenhum deles parece ../sysdeps/unix/sysv/linux/raise.c?!

$ apt-file search thread.cc
c++-annotations: /usr/share/doc/c++-annotations/examples/yo/threading/examples/functorthread.cc
libglibmm-2.4-doc: /usr/share/doc/libglibmm-2.4-doc/examples/thread/thread.cc
omniorb-doc: /usr/share/doc/omniorb-doc/examples/poa/threading/mainthread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/lib/asan/asan_thread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/lib/lsan/lsan_thread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/lib/msan/msan_thread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/lib/tsan/rtl/tsan_rtl_thread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/lib/tsan/tests/rtl/tsan_thread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/test/tsan/race_with_finished_thread.cc
rust-src: /usr/src/rustc-1.24.1/src/libcompiler_builtins/compiler-rt/test/tsan/signal_thread.cc

Ok, apt-filenovamente encontrei algo, mas todos parecem ser falsos positivos, nada corresponde ao esperado libstdc++-v3/src/c++11/thread.cc.

Então, há alguma maneira de procurar arquivos de origem como esse no Debian? Especificamente, estou no Raspbian Stretch no Raspberry Pi 3B+.

debian

1 respostas

  1. Best Answer

    std::thread::detach() Não recebo uma sugestão de arquivo de origem

    Hum, isso, como o nome diz, é a biblioteca padrão C++; muito disso é modelado e será instanciado e, portanto, compilado apenas como parte do binário real que o usa. Não obter arquivos de origem para coisas que podem ou não ser internos do compilador, ou implementações de biblioteca padrão, não é tão surpreendente até agora.

    Então, você precisa pensar ao contrário: em qual binário as coisas dão errado? O backtrace idealmente lhe diria. O Debian pode lhe dizer de qual pacote binário esse binário vem, e então você pode usar isso para obter a versão de origem do Debian desse binário. Há um atalho (veja "solução sistemática").

    sysdeps/unix/sysv/linux/raise.c

    No seu caso específico: é o glibc. Sempre que você quiser depurar alguma coisa, essa é a primeira fonte de depuração que você instala, de qualquer forma. (gnulib é uma "pista falsa". É a prática, honestamente bastante questionável, de incluir algum código-fonte compartilhado em vários projetos principais do GNU. Esses arquivos podem ser do gnulib, mas foram incorporados ao glibc e potencialmente modificados.)

    $ apt-file search raise.c

    Sim, não. Usar o nome do arquivo não é uma opção para código-fonte. Eles se sobrepõem muito. apt-filepesquisa arquivos instalados , não os arquivos-fonte dos quais eles foram compilados. (que uma ferramenta de empacotamento na verdade nem consegue saber.) É por isso que ele aponta para o pacote aleatório que contém um raise.c. (Eu, de cabeça, conheço pelo menos dois raise.carquivos não relacionados. Tenho certeza de que quando você pesquisa no github por arquivos chamados raise.c, você encontrará algumas centenas a milhares. EDIT: sim, você encontra )

    Solução sistemática:

    habilite debuginfoda recuperação de símbolos de depuração no seu sistema. Em essência, é export DEBUGINFOD_URLS="https://debuginfod.debian.net"antes de você iniciar o GDB.

    • 3

relate perguntas