[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] "Attach Process" dialog for gdb running remotely ?
|
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
> Sent: Friday, January 25, 2013 9:37 AM
> To: CDT General developers list.
> Subject: 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."
Yes, that is what I've seen when the command is not supported.
> 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.
I just realized what you are doing. I hadn't understood before.
You are running a 'local' session with GDB running on the target.
That's interesting. But we're not well prepared for that :(
When trying to list the processes, we use
-list-thread-groups --available
and if it does not work, we check if we are dealing with a local
session. For a local session we assume GDB is on the local
machine, and CDT gets the list of processes itself.
In your case, that explains why you see the list of processes
of your host instead of your target.
The good news is that if -list-thread-groups is supported,
you won't have this problem.
> 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.
I found this email that talks about a port of gdbserver to
Solaris 10, but I'm not sure it was ever submitted.
http://www.sourceware.org/ml/gdb/2010-03/msg00219.html
But now that I understand what you are doing, I don't think
you should use gdbserver. So, in the C/C++ Attach to Application
launch, select 'gdb' in the dropdown box of the Debugger subtab
next to the "Debugger:" label, intead of '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.
So -list-thread-groups --available works with a gdbserver on
solaris? You should find out if you can get it to work with
GDB itself...
> 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 prompt will not be shown for a 'local' session, so if you
avoid using gdbserver, this should work.
However, I believe all you need is to bring the binary running
on solaris and put it on your host. I think that is what GDB
needs, it it is running locally. With that, the prompt on
the LOCAL file system would allow the user to choose that binary.
> Do you have any other suggestion how I can provide an “attach
> to remote process” functionality with gdb on Solaris ?
If -list-thread-groups --available can work on Solaris, then
your ssh and local debug session solution is probably best.
If not, then a remote session with gdbserver on target and
GDB on you LOCAL host, is simplest, but you'll need the
binary locally (the one on the target copied over to the host
should be ok, but you'll have to try it).
If you don't mind not showing a list of processes to your
users but letting them type in a pid, you could use your
ssh trick without -list-thread-groups --available working,
but you'll need to find a way to have
CCorePlugin.getDefault().getProcessList() return an empty
list for that case only. I have not easy suggestion for that.
> Would you recommend patching the gdb, or can you think of
> anything else ?
I don't have an easy solution I'm afraid.
BR,
Marc
>
>
>
> 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
> <mailto: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 <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/
> <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>
> [mailto: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_.27
> gdb_traces.27.2C_where_can_I_find_them.3F
> <http://wiki.eclipse.org/CDT/User/FAQ#I.27ve_been_asked_for_.2
> 7gdb_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%3cmailto:cdt-dev-bounces@e
> clipse.org> > [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
> <mailto:cdt-dev@xxxxxxxxxxx%3cmailto: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 <mailto:cdt-dev@xxxxxxxxxxx>
>
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> <https://dev.eclipse.org/mailman/listinfo/cdt-dev>
>
>
