Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] "Attach Process" dialog for gdb running remotely ?

Hi Marc,

 

Looks like you are right - I've built a fresh gdb-7.5.1 from scratch (standard configure) and here's what I see:

 

-bash-3.00$ ./gdb/gdb -i mi

=thread-group-added,id="i1"

~"GNU gdb (GDB) 7.5.1\n"

~"Copyright (C) 2012 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 \"sparc-sun-solaris2.10\".\nFor bug reporting instructions, please see:\n"

~"<http://www.gnu.org/software/gdb/bugs/>.\n"

(gdb)

-list-thread-groups --available

^error,msg="Can not fetch data now."

(gdb)

 

Trying to build gdbserver from the gdb-7.5.1 source also fails:

 

-bash-3.00$ cd gdb/gdbserver

-bash-3.00$ ./configure

[…]

checking for Elf32_auxv_t... no

checking for Elf64_auxv_t... no

Error: target not supported by gdbserver.

 

Funny thing is, I do have a different version of gdbserver (not sure how that one was built) which I can

Launch as gdbserver –multi and actually use that to attach to a remote process. So the functionality

Of listing Solaris processes is apparently out there somewhere.

 

The problem with that approach is, that after attaching, the CDT asks me to browse to the process

executable on the LOCAL file system (but I don’t have the image local and don’t want to have – I

prefer remote debug over cross-debug).

The original solution with just entering “ssh remote gdb” as the debugger to use with the “Local” launch

Is what I’d really like ; that one did not ask me about the process image to use.

 

 

Do you have any other suggestion how I can provide an “attach to remote process” functionality with gdb on Solaris ?

 

Would you recommend patching the gdb, or can you think of anything else ?

 

Thanks,

Martin

--

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6

 

 

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
Sent: Friday, January 25, 2013 3:34 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] "Attach Process" dialog for gdb running remotely ?

 

Hi,

 

-list-thread-groups should be available for all GDB's starting with 7.0.  However, it is an MI command and therefore will not be understood by the GDB command-line interface as you ran it.  You can use that command in two ways to try it out:

   interpreter-exec mi "-list-thread-groups --available"

or start gdb in mi mode:

  gdb -i mi

the run the command directly.

 

The problem will not be in recognizing the command but if it is supported on your platform.  For example, on Windows "-list-thread-groups --available" will not work, although GDB is aware of the command.  It is likely that the gdbserver running on Solaris will not support that command, although you'd have to try it to be sure.  If it does not, then DSF-GDB cannot get the list of processes from the remote target, so no list will be shown to the user (getting a list of local processes is not normal).

 

Also, be aware that different advanced features of GDB may not work on every platform.  Specifically, I don't know if Non-stop or Reverse will work on Solaris (they don't on Windows).  Finally, the Multicore Visualizer uses /proc/cpuinfo to get the list of cores, as available on Linux.  This probably won't work on Solaris either which means the Visualizer will stay blank (like on Windows).   Note that these features of GDB/CDT could be ported to other platforms, it is just that no one has decided to make that investment.

 

If you still want to look into why you are getting a list of _local_ processes when doing a remote debug on Solaris, look (or send me) the gdb traces of the session.  I'd be curious to know how that could happen.

 

BR,

 

Marc

 

 

________________________________________

From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Oberhuber, Martin [Martin.Oberhuber@xxxxxxxxxxxxx]

Sent: January 24, 2013 7:42 PM

To: CDT General developers list.

Subject: Re: [cdt-dev] "Attach Process" dialog for gdb running remotely ?

 

Hi Marc,

 

Thanks for your answer. Apparently my gdb doesn’t understand –list-thread-groups … I didn’t compile that gdb myself, is there any recommendation how gdb should ideally be compiled for the CDT ? Of course I’ll want non-stop-mode, reverse debug, multi-attach, multicore visualizer and all the other goodies

 

My CDT is a recent build from cdt-maint on top of Eclipse 3.8.1 (I think I was using build #388).

 

-bash-3.00$ gdb

GNU gdb (GDB) 7.4

Copyright (C) 2012 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "sparc-sun-solaris2.10".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

(gdb) -list-thread-groups --available

Undefined command: "-list-thread-groups".  Try "help".

(gdb) -list-thread-groups

Undefined command: "-list-thread-groups".  Try "help".

(gdb)

 

Thanks,

Martin

--

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River direct +43.662.457915.85  fax +43.662.457915.6

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam

Sent: Thursday, January 24, 2013 7:19 PM

To: 'CDT General developers list.'

Subject: Re: [cdt-dev] "Attach Process" dialog for gdb running remotely ?

 

It is not obvious to me why you would get a local list of processes...

You can look at the gdb traces and see what is happening differently:

http://wiki.eclipse.org/CDT/User/FAQ#I.27ve_been_asked_for_.27gdb_traces.27.2C_where_can_I_find_them.3F

 

To fill the process prompter with values, CDT asks GDB for the list of processes using

  -list-thread-groups --available

If that command does not work (as it may not for Solaris), the remote session should fall back to asking for a pid directly.  For the local case, the list will be provided by CDT itself.

I wonder if there is some confusion between the remote and local case?

 

What version of CDT are you using?

 

 

 

________________________________

From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin

Sent: Thursday, January 24, 2013 11:43 AM

To: cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>

Subject: [cdt-dev] "Attach Process" dialog for gdb running remotely ?

Hi,

 

I have an odd problem, trying to debug a remote application with gdb running remotely.

Here’s what I do:

 

 

1.       Create a new “C/C++ Attach Application” Launch

 

2.       Leave the project and app fields empty on the main tab

 

3.       Enter “ssh szg-vm01-qa-lx2 gdb“ as the debugger to use on the debugger tab

 

Launch it, and wohoo I get a Process picker dialog showing remote processes, everything works fine !

The remote host in that case is RHEL 5.8 with gdb 7.0, NFS-shared file system.

 

BUT

 

When I try the same against a remote Solaris 10 host running gdb-7.4 , I’m getting a LOCAL Process picker dialog, showing the local processes (and the “New…” button enabled).

I don’t have the full file system shared in that case.

 

What could be the reason why I don’t get a remote process picker in the 2nd case ?

Can I enable logging of any kind to troubleshoot ?

 

Thanks,

Martin

--

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River direct +43.662.457915.85  fax +43.662.457915.6 _______________________________________________

cdt-dev mailing list

cdt-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top