0

I am using Intel's ICC compiler for NetBSD systems. 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 badf_errcnt which was optimized into CPU registers, is assigned a memory location, and thereafter compiler got confused between two ?

EDIT1: the variable connection_out is a static int global variable

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.
sepp2k
  • 363,768
  • 54
  • 674
  • 675
ultimate cause
  • 2,264
  • 4
  • 27
  • 44

1 Answers1

0

I don't think the compiler is confused, but gdb may very well be confused, or at least working with too little information.

It does not appear as if ICC is providing sufficient symbolic debugger information for gdb, thus you're not seeing anything very useful. Was the code compiled with the correct options to record debug information in the generated binary? (i.e. -g and maybe also -O0)

Have you tried using idbc (the Intel debugger)?

Greg A. Woods
  • 2,663
  • 29
  • 26
  • It is from a process in production machine, therefore neither can be used. Though when I made the variable global and removed static scope, I did not see the problem. – ultimate cause Apr 18 '15 at 12:20
  • There is rarely any valid excuse for not using '-g' in a production environment! You may even be able to keep the debug information in a separate file to be used only on the development machine -- i.e. with a copy of the core file from the production machine. That is in fact exactly how the NetBSD toolchain works (in recent releases) for standard system binaries. However even if this does not work for ICC, the only overhead of keeping debugging information is in the disk space required, and that's usually trivial. – Greg A. Woods Apr 18 '15 at 22:55
  • Yes, so I have full symbol table information on my private development machine. However, as I learned from seniors, compiling with -g option sometimes causes nullification of certain possible optimizations, hence some performance penalty is incurred. – ultimate cause Apr 19 '15 at 12:36
  • Well, first off don't worry about small optimizations, especially without first profiling and measuring whether they matter. Secondly, read the compiler manual to learn what it does with various command-line options. Personally I've never heard of any C compiler that prioritizes `-g` over any optimization option, and I've used many dozens of compilers, though I have not used a recent Intel compiler, so I would check the manual. The problem is usually the other way around in that the optimizer often makes it very difficult for the debugger, even with all the debugging symbols available. – Greg A. Woods Apr 20 '15 at 03:20
  • Also, if you can only reproduce the bug you're hunting in the production environment, then I'd say that's a very good reason to install a debug version of the program, with optimizations entirely disabled, until you can gather some really useful debugging information. – Greg A. Woods Apr 20 '15 at 03:22