Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

Is it a GDB bug or Intel Compiler bug or my code?

TRIPATHI__RIPUNJAY
1,344 Views

I am using Intel's ICC compiler for NetBSD system. I have been fighting with a bug, and got surprised even more when I observed that from the core dump - address of a symbol from two different mechanisms in gdb are not same.

The variable connection_out seems to have different address when checked with "info symbol connection_out" and p &connection_out.

Does it looks like a compiler problem where a local static variable badf_errcnt which was optimized into CPU registers, is assigned a memory location, and thereafter compiler got confused between two ?

I have compiler O2 level optimizations ON. The variable in question is a global static int variable. I don't think pointer aliasing is in its role here as the variable's memory location is being used.

I see that the unstripped symbol file also concurs to the address in the disassembled code.

 

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.


prompt$ nm sshd.unstripped | grep connection_out   
0188f05c b connection_out

0 Kudos
3 Replies
Amanda_S_Intel
Employee
1,344 Views

When you compile and run the code with -O0, does the problem go away?

0 Kudos
TRIPATHI__RIPUNJAY
1,344 Views

I could not try that, though I see that when I make that variable available in global scope

(which means I remove "static" specifier from "static int connection_out" )

the problem goes away indeed.

Therefore, by doing that I spoil my global namespace but the values it prints via gdb are correct.

0 Kudos
TRIPATHI__RIPUNJAY
1,344 Views

I just ran following commands on the unstripped symbol file and it seems that .debug_info section does not have address details.

Therefore it rather seems to be a compiler/linker issue.

user$ readelf -Ws sshd.unstripped | grep connection_out  

   632: 01892b34     4 OBJECT  GLOBAL DEFAULT   26 connection_out  

  1684: 01892b34     4 OBJECT  GLOBAL DEFAULT   26 connection_out  

user$ readelf -wi sshd.unstripped | grep connection_out   

     DW_AT_name        : connection_out 

0 Kudos
Reply