Issue while debugging binary built by Intel compiler with GDB

[sandip_dongaregmail_]

I am trying to debug binary which is compile/built by Intel compiler(veriosn 9.1) on linux64 X86 platform. I am facing issue when trying to print result of function execution, using print command of gdb, where it works well when I compile binary with gcc.

Here is the sample program:

//hello.h
class Scheme
{
private:
void * _h;

public:
Scheme();
char *getName();
};

class SchemeImp
{
char *name;
public:
SchemeImp(char *);
char *getName();
};




//hello.cpp

Scheme::Scheme()
{
_h=(void *) new SchemeImp("testClass");
}

char *Scheme::getName()
{
return (char*) (((SchemeImp*)_h)->getName());
}


SchemeImp::SchemeImp(char *c)
{
name = c;
}

char *SchemeImp::getName()
{
return name;
}

int main()
{
Scheme *p = new Scheme(); //LINE1
printf("Name:%s\\n",p->getName()); //LINE2
printf("hello"); //LINE3
}

=======================

I compiled this using: $ icpc hello.cpp -i-static -g -debug -I.


When I attach the process using gdb, when execution comes at LINE3 I execute print p->getName(0), gdb execution stops giving output as :

(gdb) p p->getName(0)

Program received signal SIGSEGV, Segmentation fault.
0x0000000000400d34 in Scheme::getName (this=0x0) at hello.cpp:12
12 return (char*) (((SchemeImp*)_h)->getName());
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (Scheme::getName()) will be abandoned.


This works fine when I compile using gcc


Any idea what should I do to able to print these kind of functions when binary build with ICC.?

[Hubert_H_Intel]

What's the reason for using an old Intel Compiler? What's the version of gcc?
I just did a smoke test with actual Intel Compioer + GDB/IDBC, but didn't see the Seg fault.
Regards, Hubert.

[sandip_dongaregmail_]

Thanks for replying.
My other components are compiled using same icc version, right now not planning to move to other version.
I am able to reproduce this issue with higher version of icc as well (icc 11.1.069) on RHEL4 & RHEL5 both.

Issue is also observed when I make function call through gdb of simple type of function like:

char *SchemeImp::getName(void)
{
return name;
}




GCC version:
$ /usr/bin/gcc34 -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,f77 --disable-libgcj --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-4.1)

gdb version:6.1, also tried with 7.1 but still facing issue.

[sandip_dongaregmail_]

Finally the issue is resolved.
To call function using print command of gdb you should pass this pointer of the object as a first argument to function call.
e.g.
(gdb) p (&obj)
$2 = (SchemeImp *) 0x7fbffff5c0
(gdb) p obj.getTrue(0x7fbffff5c0)
$3 = 10

Still question is that, why it is not necessary (to pass this pointer as argument) when binary compiled with gcc.? Is there any document which talks about this?

[SergeyKostrov]

>>...Is there any document which talks about this?..

Take a look at ..\Info folder. There are a couple ofdoc-files like:

Gdb.info
Gdb-info-1
Gdb-info-2
Gdb-info-3
Gdb-info-4

[sandip_dongaregmail_]

I am not able to find documentation like Info folder and other mentioned. Please correct me.

[SergeyKostrov]

>>...I am not able to find documentation like Info folder...

I'll post these files some time later...

[TimP]

This appears to make reference to the gdb info file installation
> info gdb
One may hope the info files should have improved over the 5 years and 8 months since the quoted version was set up.

[SergeyKostrov]

Zip-file with Docs for GDBenclosed.

[Georg_Z_Intel]

Hello,

I was able to reproduce your problem. All 11.x compilers produced incomplete debug information for such kinds of member functions. Thus GDB assumes those are static functions whereas their implementation is still requiring C++ calling convention. This is also the reason why your workaround is required - you explicitly pass the otherwise implicit "this" parameter first to satisfy the C++ calling convention.

The problem has been fixed beginning 2010 for all 12.x compilers.

If you still want to use the same compiler I can confirm your workaround; you might even use it in a slightly optimized way:
(gdb) p->getName(p)

...or use IDB here, which does not require such a workaround.

Best regards,

Georg Zitzlsberger