Адрес переменной не совпадает в gdb

Я использую компилятор Intel ICC для систем NetBSD. Я долго боролся с багом и еще больше удивился, когда заметил, что из дампа ядра - адреса символа из двух разных механизмов в gdb не совпадают.

Переменная connection_out имеет другой адрес при проверке с помощью "информационный символ connection_out" и p &connection_out.

Похоже ли это на проблему с компилятором, когда badf_errcnt, который был оптимизирован для регистров ЦП, назначается в памяти, и после этого компилятор путается между двумя?

EDIT1: переменная connection_out является глобальной переменной static int

gdb$ disassemble sigusr1_rt
Dump of assembler code for function sigusr1_rt:
   0x01845000 <+0>:     push   %ebp
   0x01845001 <+1>:     mov    %esp,%ebp
   0x01845003 <+3>:     sub    $0x8,%esp
   0x01845006 <+6>:     movl   $0x16c156a,0x188f05c
   0x01845010 <+16>:    mov    %ebp,%esp
   0x01845012 <+18>:    pop    %ebp
   0x01845013 <+19>:    ret    
   0x01845014 <+20>:    lea    0x0(%esi),%esi
   0x0184501a <+26>:    lea    0x0(%edi),%edi
End of assembler dump.
gdb$ info symbol 0x188f05c
connection_out in section .bss of /sites/eqx/work/swcores/tripunjay/F10ACOREDIR/f10cp_sshd.login-eqx-06.6402/sshd
gdb$ p &connection_out
$10 = (int *) 0x188f048
gdb$ p/d 0x188f05c - 0x188f048
$11 = 20
gdb$ p/x 0x188f05c - 0x188f048 
$12 = 0x14
gdb$ info symbol 0x188f048
badf_errcnt.5450.0.13 in section .bss of /sites/eqx/work/swcores/tripunjay/F10ACOREDIR/f10cp_sshd.login-eqx-06.6402/sshd
gdb$ p &badf_errcnt
No symbol "badf_errcnt" in current context.
gdb$ select-frame 5
gdb$ frame         
Stack level 5, frame at 0xbb4aca20:
 eip = 0x1846007 in wait_until_can_do_something (serverloop.c:404); saved eip 0x1846698
 called by frame at 0xbb4b0af0, caller of frame at 0xbb4ac9d0
 source language c.
 Arglist at 0xbb4aca18, args: readsetp=0xbb4b0ab4, writesetp=0xbb4b0ab8, maxfdp=0x4, nallocp=0xbb4b0abc, max_time_milliseconds=0x0
 Locals at 0xbb4aca18, Previous frame's sp is 0xbb4aca20
 Saved registers:
  ebx at 0xbb4aca00, ebp at 0xbb4aca18, esi at 0xbb4ac9fc, edi at 0xbb4aca04, eip at 0xbb4aca1c
readsetp = 0xbb4b0ab4
writesetp = 0xbb4b0ab8
maxfdp = 0x4
nallocp = 0xbb4b0abc
max_time_milliseconds = 0x0
badf_errcnt = <optimized out>
tv = <optimized out>
tvp = <optimized out>
client_alive_scheduled = 0x0
gdb$ p &badf_errcnt
Can't take address of "badf_errcnt" which isn't an lvalue.

c intel gdb netbsd
person ultimate cause    schedule 13.04.2015    source источник
comment
Что говорит map файл?   -  person Eugene Sh.    schedule 14.04.2015
comment
Как проверить файл карты? Спасибо за эти новые знания.   -  person ultimate cause    schedule 14.04.2015

Ответы (1)


arrow_upward
0
arrow_downward

Я не думаю, что компилятор запутался, но gdb вполне может запутаться или, по крайней мере, работать со слишком небольшим количеством информации.

Не похоже, что ICC предоставляет достаточную символическую информацию отладчика для gdb, поэтому вы не видите ничего очень полезного. Был ли код скомпилирован с правильными параметрами для записи отладочной информации в сгенерированный двоичный файл? (т.е. -g и, возможно, также -O0)

Вы пробовали использовать idbc (отладчик Intel)?

person Greg A. Woods    schedule 17.04.2015
comment
Это из производственного процесса, поэтому ни один из них не может быть использован. Хотя, когда я сделал переменную глобальной и удалил статическую область видимости, я не увидел проблемы. - person ultimate cause; 18.04.2015
comment
Редко существует какое-либо уважительное оправдание для того, чтобы не использовать «-g» в производственной среде! Вы даже можете хранить отладочную информацию в отдельном файле, который будет использоваться только на машине разработки, т. е. с копией основного файла с рабочей машины. На самом деле именно так работает инструментальная цепочка NetBSD (в последних выпусках) для стандартных системных двоичных файлов. Однако, даже если это не работает для ICC, единственные накладные расходы на хранение отладочной информации связаны с требуемым дисковым пространством, и это обычно тривиально. - person Greg A. Woods; 19.04.2015
comment
Да, поэтому у меня есть полная информация о таблице символов на моей частной машине для разработки. Однако, как я узнал от старших, компиляция с параметром -g иногда приводит к аннулированию некоторых возможных оптимизаций, следовательно, возникает некоторое снижение производительности. - person ultimate cause; 19.04.2015
comment
Ну, во-первых, не беспокойтесь о небольших оптимизациях, особенно без предварительного профилирования и измерения того, имеют ли они значение. Во-вторых, прочитайте руководство по компилятору, чтобы узнать, что он делает с различными параметрами командной строки. Лично я никогда не слышал ни о каком компиляторе C, который отдавал бы приоритет -g любому параметру оптимизации, и я использовал многие десятки компиляторов, хотя я не использовал последний компилятор Intel, поэтому я бы проверил руководство. Проблема обычно заключается в том, что оптимизатор часто очень усложняет работу отладчика, даже при наличии всех доступных отладочных символов. - person Greg A. Woods; 20.04.2015
comment
Кроме того, если вы можете воспроизвести ошибку, которую вы ищете, только в производственной среде, то я бы сказал, что это очень веская причина для установки отладочной версии программы с полностью отключенными оптимизациями, пока вы не сможете собрать некоторые действительно полезные отладочные данные. Информация. - person Greg A. Woods; 20.04.2015