Depurando o kernel do Linux com o QEMU

Question

Eu estava tentando estudar a depuração do kernel usando o QEMU. Eu tentei inicialmente e falhei devido ao fato de que não havia nenhum sistema de arquivos virtual. As respostas a esta postagem sugerem que deve haver um sistema de arquivos virtual. Mas ele não fala sobre como criar FS virtual para depuração do kernel e como passá-lo para o qemu. Você pode me ajudar?

    

Answer 1

Dependendo da distribuição que você deseja usar, existem várias maneiras de criar uma imagem do sistema de arquivos, por exemplo, este artigo conduz você pelo caminho trabalhoso para um Sistema "Linux from Scratch" .

Em geral , você ou cria uma imagem QEMU usando qemu-img , obtém a mídia de instalação de alguma distribuição e usa o QEMU com o meio de instalação para preparar a imagem ( esta página explica o processo para o Debian GNU / Linux ) ou use uma imagem preparada por outra pessoa.

Esta seção do QEMU Wikilivros contém todas as informações que você precisa.

Editar: Como a resposta de Gilles à pergunta relacionada sugere, você não precisa de um sistema de arquivos raiz completo para testes, você poderia apenas use uma imagem initrd (digamos, o initrd do Arch Linux como aqui)

    

Answer 2

Procedimento passo a passo do QEMU + GDB testado no host do Ubuntu 16.10

Para começar do zero rapidamente, fiz um exemplo mínimo de QEMU + Buildroot totalmente automatizado em: link Os passos principais são abordados abaixo.

Primeiro, obtenha um sistema de arquivos raiz rootfs.cpio.gz . Se você precisar de um, considere:

• uma imagem executável init -only mínima: Linux Distro personalizado que executa apenas um programa, nada mais | Unix & Troca de pilha do Linux
• um sistema interativo do Busybox: Qual é o menor possível implementação do Linux? | Unix & Troca de pilha do Linux

Em seguida, no kernel do Linux:

git checkout v4.9
make mrproper
make x86_64_defconfig
cat <<EOF >.config-fragment
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_GDB_SCRIPTS=y
EOF
./scripts/kconfig/merge_config.sh .config .config-fragment
make -j"$(nproc)"
qemu-system-x86_64 -kernel arch/x86/boot/bzImage \
                   -initrd rootfs.cpio.gz -S -s

Em outro terminal, suponha que você queira iniciar a depuração de start_kernel :

gdb \
    -ex "add-auto-load-safe-path $(pwd)" \
    -ex "file vmlinux" \
    -ex 'set arch i386:x86-64:intel' \
    -ex 'target remote localhost:1234' \
    -ex 'break start_kernel' \
    -ex 'continue' \
    -ex 'disconnect' \
    -ex 'set arch i386:x86-64' \
    -ex 'target remote localhost:1234'

e terminamos !!

Para módulos do kernel, consulte: Como depurar o Linux módulos do kernel com o QEMU? | Estouro de pilha

Para o Ubuntu 14.04, GDB 7.7.1, hbreak foi necessário, break pontos de interrupção de software foram ignorados. Não é mais o caso em 16.10. Veja também: link

O messy disconnect e o que vem depois são para contornar o erro:

Remote 'g' packet reply is too long: 000000000000000017d11000008ef4810120008000000000fdfb8b07000000000d352828000000004040010000000000903fe081ffffffff883fe081ffffffff00000000000e0000ffffffffffe0ffffffffffff07ffffffffffffffff9fffff17d11000008ef4810000000000800000fffffffff8ffffffffff0000ffffffff2ddbf481ffffffff4600000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000

Tópicos relacionados:

• link pode ser um bug do GDB
• gdb - A resposta remota do pacote 'g' é muito longa | Estouro de pilha
• link osdev.org é, como de costume, uma excelente fonte para esses problemas
• link

Veja também:

• link kernel oficial do Linux "documentation"
• Como depurar o kernel do Linux com GDB e QEMU? | Estouro de pilha

Limitações conhecidas:

• o kernel do Linux não suporta (e nem mesmo compila sem correções) com -O0 : Como desotimizar o kernel Linux e compilá-lo com -O0? | Estouro de pilha
• O GDB 7.11 vai explodir sua memória em alguns tipos de conclusão de guias, mesmo após a correção max-completions : Interrupção de conclusão de tabulação para binários grandes | Stack Overflow Provavelmente algum caso de canto que não foi coberto naquele patch. Portanto, um ulimit -Sv 500000 é uma ação sensata antes da depuração. Estourou especificamente quando eu abri file<tab> para o argumento filename de sys_execve como em: Pode a chamada do sistema sys_execve () no kernel do Linux receber caminhos absolutos ou relativos? | Estouro de pilha