Práticas recomendadas para anexar símbolos de depuração a bibliotecas do sistema durante o desenvolvimento?

Question

Estou em um estágio de um projeto em que seria realmente útil ter uma versão de depuração de um pacote de sistema instalado. Pelo menos no Ubuntu, adicionar os símbolos de depuração a uma biblioteca é muito fácil. Praticamente todos os pacotes têm uma variante -dbg que fornece todos os símbolos que você precisa para um backtrace útil.

No entanto, estou atualmente no Arch linux, onde o consenso geral é para editar o usuário makepkg.conf file, incluindo quaisquer flags de depuração para (C|CXX|CPP|LD)FLAGS . Em seguida, recompile o pacote e substitua a versão atual e otimizada pela compilação de depuração. Bem, suponho que seja justo o suficiente com uma "distribuição baseada na fonte", mas fica entediante rapidamente.

Então, quais são as práticas recomendadas para anexar símbolos de depuração a um pacote do sistema? Como outros empacotadores fazem isso?

Acho que vi que strip pode extrair símbolos de depuração e salvá-los em arquivos externos. É possível para gdb pegar esses arquivos de símbolo durante os backtraces, com os aplicativos do sistema nem mesmo se preocupando em procurá-los? Como isso funciona, do ponto de vista dos empacotadores?

É apenas uma ideia, mas é uma boa ideia criar um ambiente chroot para desenvolver? (Eu tenho um problema atm onde um pacote tem uma incompatibilidade ABI entre suas compilações de debug e release, o que é um pouco doloroso. Tudo vinculado à sua biblioteca compartilhada também reclama de símbolos perdidos, então revertido para build otimizado ..)

    

Answer 1

Se você distribuir um pacote source , a norma (autotools) é compilar os símbolos de depuração por padrão.

Eu acho que antigamente as distribuições mainstream do linux os deixavam em binários; Eu posso estar errado sobre isso. Há um equívoco de que a remoção de símbolos de depuração "otimiza" o software. Não faz. A única diferença, incluindo símbolos de depuração, é o espaço ocupado por um arquivo no disco. Isso não afeta o uso da memória, uma vez que eles não são carregados na memória durante o uso normal (portanto, isso também não afeta mais nada). Tente criar um perfil de um binário despojado e não-tirado. Eles são os mesmos.

A finalidade de separá-los dos pacotes de distro é apenas reduzir o tamanho de cada pacote, de modo que toda a instalação seja, por exemplo, 2,5 GB em vez de 3,8 GB ou o que for. Se o seu pacote for selecionado para inclusão em um repositório oficial, a distribuição irá empacotá-lo a partir da fonte. Eles não usarão um pacote que você premade, portanto, fazer esse trabalho agora (criar um pacote de depuração separado) não fará diferença a esse respeito.

Se você distribuir de forma independente pacotes binários de bibliotecas para várias distros, ninguém vai se importar se os símbolos de depuração forem compilados e a maioria das pessoas que programa com a biblioteca os desejar. Para as poucas pessoas que estão incomodadas por algum motivo estranho, elas são fáceis de se despir.

Então, se você quer minha opinião como programador e usuário linux, apenas deixe-os entrar, pelo menos por enquanto. Uma preocupação óbvia com a "otimização prematura" - especialmente, otimizações prematuras que não são realmente otimizações - não parece boa. Em outras palavras, a resposta literal à sua pergunta é: "A melhor prática para anexar símbolos de depuração às bibliotecas do sistema durante o desenvolvimento é compilá-los .

Dito isso, eu notei esta página WRT .deb packages quando eu estava tentando confirmar minha crença de que uma vez eles sempre foram incluídos de qualquer maneira. Desde que você incluiu o dpkg em suas tags, pode ser útil para você.

    

Answer 2

Adicionar OPTIONS+=(debug !strip) adiciona isso (de /etc/makepkg.conf ) às suas opções de construção: DEBUG_CFLAGS="-g -fvar-tracking-assignments" .

Nenhuma dessas opções desativa qualquer otimização ( link ). Você obtém uma compilação otimizada com símbolos de depuração, não o que muitas pessoas querem dizer quando falam sobre uma "compilação de depuração". Para obter isso, você também habilitaria -O0 ou -Og ("otimizar para depuração".)

Quando você depura com gdb, geralmente print some_local lhe dará (optimized out) , porque o formato de depuração não pode rastrear variáveis que estão ao vivo em registradores (não são derramadas na memória). É claro que até mesmo um formato de depuração perfeito não pode realmente corrigir casos em que uma variável foi realmente otimizada, e nenhum registro ou memória contém um valor correspondente à fonte C. Você ainda pode (razoavelmente) obter rastreamentos de forma confiável e funções args para funções que não eram inline.

o link diz que agora você pode usar (debug strip) para obter um pacote somepkg-debug separado que coloca informações de símbolo em /usr/lib/debug . (Como o que o Debian / Ubuntu distribui como somepkg-dbg .) IDK se esse fosse o caso em 2013 quando você perguntou isso.

Você não pode, é claro, usar esse pacote de depuração com um pacote binário existente, porque qualquer pequena diferença em qualquer coisa poderia levar a informações incorretas de depuração.

Infelizmente, não há um sistema de pacotes / repo para distribuir pacotes de depuração para pacotes binários pré-compilados. Assim, você ainda precisa compilar localmente qualquer pacote para o qual você deseja depurar símbolos.

No lado positivo, essa é uma boa chance de ativar -march=native para tornar os binários otimizados especificamente para o seu sistema. por exemplo. habilite tudo o que a sua CPU suporta, como o BMI2 para instruções de deslocamento de contagem variável mais eficientes, instruções% vector popcnt e AVX / AVX2 / FMA / AVX512. -march=native também define -mtune=native , que é bom .

A sobrecarga do perfurador de deixar informações de depuração no mesmo arquivo que as bibliotecas deve ser insignificante. O /usr/lib/libc.so.6 inteiro não é carregado na RAM, apenas as páginas necessárias são mapeadas. As informações de depuração são agrupadas dentro do binário para que essas páginas provavelmente permaneçam frias no disco.