GDB не может получить доступ к памяти в переменной типа-значения - PullRequest
0 голосов
/ 03 апреля 2019

При попытке отладить ядро, выброшенное из-за ошибки сегмента, линия, в которой он падает, на самом деле не имеет смысла в моих глазах;сравниваются два целых числа и результат сохраняется в bool.Это не упрощенный код:

bool doLog = level >= debugLevel;

Это код ассемблера, в котором происходит сбой:

cmp    %ebx,0x14(%rbp)
  // ebx = 3
  // rbp = 0x6e696c7265

Однако при попытке напечатать значение адреса, хранящегося в rbp, я получаюошибка GDB: «не удается получить доступ к памяти по адресу 0x6e696c7279»

Меня беспокоит то, что при печати адреса debugLevel я получу адрес, отличный от того, который хранится в регистре rbp, используемом для cmp:

p &debugLevel => 0x6e696c7279
i r rbp       => 0x6e696c7265

1 Ответ

0 голосов
/ 03 апреля 2019

0x6e696c7265 выглядит как коды ASCII для букв .Вы, вероятно, перезаписали указатель строковыми байтами.

(например, возможно переполнение буфера наступило на сохраненное значение RBP, а затем функция вернулась к своему вызывающему после восстановления RBP, нарушив доступ к локальным объектам, когда вызывающий пытается использоватьRBP как указатель кадра. На самом деле, RBP+14 не будет указателем кадра, если, возможно, это не в Windows и компилятор не выделил этот локальный объект в теневом пространстве над адресом возврата.)

распечатав адрес debugLevel, я получу адрес, отличный от того, который хранится в регистре rbp, используемом для cmp

GDB знает из отладочной информации, что &debugLevel = RBP + 0x14.

Вот почему в инструкции cmp используется режим адресации со смещением 0x14, в частности 0x14(%rbp).Таким образом, вычисление &debugLevel с искаженного базового адреса даст вам еще один неверный адрес.

0x6e696c7279 - 0x6e696c7265 = 0x14 = 20.Эта часть не интересна или не связана с вашей ошибкой повреждения памяти.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...