Bug 368312

Comment 1 Marco Falda 2012-01-22 08:24:27 EST

Also with the same version of Eclipse and

GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
mpiexec (mpich2 1.0.5p2)

Comment 2 Greg Watson 2012-02-14 11:13:57 EST

I checked the version matching code and it should parse your version ok. The only other code I can see is the actual version check. Can you try running the command "gdb -q -i mi". When you see the "(gdb)" prompt, type "-gdb-version" and hit return. Let me know what output you get.

Comment 3 Marco Falda 2012-02-15 14:47:19 EST

(In reply to comment #2)
> I checked the version matching code and it should parse your version ok. The
> only other code I can see is the actual version check. Can you try running the
> command "gdb -q -i mi". When you see the "(gdb)" prompt, type "-gdb-version"
> and hit return. Let me know what output you get.

In my case the output is:

-gdb-version
~"GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08\n"
~"Copyright (C) 2011 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law.  Type \"show copying\"\nand \"show warranty\" for details.\n"
~"This GDB was configured as \"x86_64-linux-gnu\".\nFor bug reporting instructions, please see:\n"
~"<http://bugs.launchpad.net/gdb-linaro/>.\n"
^done



In Eclipse I see the following output in red (in its console):

 gdb: invalid option -- 'q'
 sdm [--debugger=value] [--debugger_path=path]
     [--proxy=proxy]
     [--host=host_name] [--port=port]
 	 [--master]
     [--server=rank]
     [--debug[=level]]

Comment 4 Dan Sun 2012-02-20 23:07:48 EST

I tried some debugging on the SDM itself. 

The error is generated after calling function MICommandResultOK() in function GetGDBVersion(). The returned value of MICommandResultOK is not 1(TRUE) and that takes the code path to generate error message "Unable to determine gdb version". Taking one step closer, I found that the completed field of the MICommand structure, cmd, is not 1(TRUE) when it is passed into function MICommandResultOK() and it leads function MOCommandResultOK() to return 0.

I stopped my investigation at this point. Hopefully what I found is useful to others.

Comment 5 Greg Watson 2012-02-21 08:06:08 EST

(In reply to comment #4)
> I tried some debugging on the SDM itself. 
> 
> The error is generated after calling function MICommandResultOK() in function
> GetGDBVersion(). The returned value of MICommandResultOK is not 1(TRUE) and
> that takes the code path to generate error message "Unable to determine gdb
> version". Taking one step closer, I found that the completed field of the
> MICommand structure, cmd, is not 1(TRUE) when it is passed into function
> MICommandResultOK() and it leads function MOCommandResultOK() to return 0.
> 
> I stopped my investigation at this point. Hopefully what I found is useful to
> others.

Thanks! I believe the problem is that the gdb version being used does not understand the '-q' option, which is preventing gdb from starting. The MISessionStartLocal function does not detect that gdb is unable to start. The debugger then continues to try to determine the version, and ultimately fails. Hence the misleading message. I've verified this happens if you change '-q' to and invalid option for gdb. 

A workaround for now is to remove the '-q' option at lines 160 and 162 of MISession.c (in org.eclipse.ptp.debug.sdm/libmi).

I wasn't aware of any versions of gdb that do not support '-q'. The correct way to deal with this would be to write an autoconf test to check that gdb supports '-q' and set a config.h option if it doesn't.

Comment 6 Dan Sun 2012-02-21 21:25:42 EST

Hi Greg,

As it turn out, there is nothing wrong with the code. Such an error was caused by in incorrect configuration in my Eclipse's preference set up.

When I set up SDM, Windows->Preferences->Parallel Tools->Debug->SDM, I populate "Path to backend debugger" with the path to the SDM binary rather than the path to gdb. Therefore, an incorrect path is sent to SDM, so SDM was failing to start gdb.

Apologies for wasting your time.

Comment 7 Greg Watson 2012-02-22 14:04:42 EST

No problem, I'm glad we got it sorted out. See bug 360139 for a description of the paths. These need to be made clearer in the next release.