Início / coding / Perguntas / 79562692
Accepted
Max Taggart
Asked: 2025-04-09 01:18:52 +0800 CST

Compreendendo a saída do GDB - Conteúdo de memória

  • 772

Estou depurando uma falha de segmentação em um programa em C++, mas primeiro estou tentando entender melhor como usar o comando gdbpara inspecionar o layout da memória no arquivo principal, produzido quando o processo sofre uma falha de segmentação. Estou usando o seguinte programa de brinquedo, que sofre uma falha de segmentação intencional, para entender gdbmelhor a saída do .

int main() {
    int a = 4;
    int b = 12;
    *(int *)0 =11;
    return a + b;
}

Quando abro o arquivo principal (usando gdb my_executable path/to/core.pid), posso ver os endereços de memória que contêm os valores de ae b, o que faz sentido, já que sizeof(int) == 4:

(gdb) p &a
$5 = (int *) 0x7ffff940e078
(gdb) p &b
$6 = (int *) 0x7ffff940e07c

E quando pergunto pelo conteúdo da memória começando por &aisso, até que faz sentido, exceto que estou em uma máquina Intel, que deveria ser little endian, e parece que esses inteiros são big endian:

(gdb) x/4x &a
0x7ffff940e078: 0x00000004      0x0000000c      0xf940e120      0x00007fff
# (added by me) ---a==4---      --b==12---      other stuff ->

Então, se eu perguntar o conteúdo da memória começando no próximo endereço, eu esperaria o seguinte (todos os bytes se deslocam um para a esquerda):

(gdb) x/4x 0x7ffff940e079
0x7ffff940e079: 0x00000400      0x00000cf9      0x40e12000      0x007fff..

Mas o que gdbrealmente imprime é isto:

(gdb) x/4x 0x7ffff940e079
0x7ffff940e079: 0x0c000000      0x20000000      0xfff940e1      0xca00007f
#               --b==12?--      other stuff ->

Parece que avançamos 7 bytes, ou 4 bytes, e agora bé little endian. Mas a memória depois desse primeiro 0x0cbyte é diferente do que era no último comando (antes era, 0xf940e...agora é 0x2000...). Será que estou lendo a memória acidentalmente com alinhamento diferente? E alguém sabe por que os valores parecem ser big endian?

Estou compilando o código com g++a versão 13.3.0 no Ubuntu 24.04, caso isso ajude.

c++

1 respostas

  1. Best Answer

    Parece que você está interpretando mal a saída de depuração do GDB. Quando você dá a instrução x/4xe o gdb mostra 0x00000004, isso não significa que os bytes são 00 00 00 04. Em vez disso, significa que se você interpretar os próximos 4 bytes como um valor hexadecimal, será 0x00000004. Como seu sistema é little-endian, isso significa que os bytes reais são

    04 00 00 00 0c 00 00 00 20 e1 40 f9 ff 7f 00 00 [ca]
----------- ----------- ----------- -----------
0x00000004  0x0000000c  0xf940e120  0x00007fff

    Você pode confirmar isso invocando x/17bxo comentário de @ssbssa , que deve mostrar os bytes na ordem correta. Aqui, o prefixo bsignifica byte.

    Agora, se você deslocar um byte, os bytes serão reagrupados e reinterpretados, gerando o seguinte resultado:

    [04] 00 00 00 0c 00 00 00 20 e1 40 f9 ff 7f 00 00 ca
     ----------- ----------- ----------- -----------
     0x0c000000  0x20000000  0xfff940e1  0xca00007f

    O que é consistente com a sua observação. Nada de estranho como "pulamos 7 bytes para frente, ou que saltamos 4 bytes para frente e agora bé little endian" acontece.

    Não acho que isso seja exclusivo do GDB e acredito que outros dumpers hexadecimais também objdumptenham comportamento semelhante. Veja esta resposta para mais informações. Os dumpers hexadecimais provavelmente são projetados dessa forma para que um usuário casual que não esteja lendo um endereço desalinhado não precise se preocupar com endianismo.

    • 2

relate perguntas