Estou fora do executável de destino do gdb e nem mesmo tenho uma pilha que corresponda a esse destino. Quero fazer uma única etapa de qualquer maneira, para poder verificar o que está acontecendo em meu código de assembly, porque não sou um especialista em assembly x86. Infelizmente, o gdb se recusa a fazer essa depuração simples no nível do assembly. Isso me permite definir e parar no ponto de interrupção apropriado, mas assim que eu tento avançar em uma única etapa, o gdb reporta o erro "Não é possível encontrar limites da função atual" e o EIP não muda.
Detalhes adicionais:
O código de máquina foi gerado por instruções gcc asm e eu o copiei para o local da memória do kernel onde ele está executando, a partir da saída de objdump -d. Eu não me importaria em uma maneira simples de usar um carregador para carregar meu código-objeto para um endereço realocado, mas tenha em mente que o carregamento deve ser feito em um módulo do kernel.
Suponho que outra alternativa seria produzir um módulo de kernel falso ou arquivo de informações de depuração para fornecer ao gdb, para fazê-lo acreditar que essa área está dentro do código do programa. O gdb funciona bem no próprio executável do kernel.
(Para aqueles que realmente querem saber, estou inserindo código em tempo de execução no espaço de dados do kernel do Linux dentro de uma VM VMware e depurando-o a partir do gdb remoto, depurando o kernel por meio do stub gdb integrado do VMware Workstation. Observação Não estou escrevendo o kernel exploits; sou um estudante de pós-graduação em segurança, escrevendo um protótipo.)
(Posso definir um ponto de interrupção em cada instrução dentro de minha montagem. Isso funciona, mas se tornaria muito trabalhoso depois de um tempo, já que o tamanho das instruções de montagem x86 varia e a localização da montagem mudará toda vez que eu reiniciar.)