[
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,
Thanks for your help and suggestions. I really appreciate that !
> 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
Yes I guess that's the gdbserver that works for me. I found some "public patches"
On the gdb mailing list from 2010 which are relatively large ... applied to a 7.1 gdb tree.
Strange that the patches never made it into the official source tree. Would you know
Whom to ask where's the official location of these patches in some CM system ?
Anyways the patches are only for gdbserver, so I assume bringing that work inside the gdb itself
might not be trivial. I've also heard (not yet tried myself) that there are issues with pthread programs.
> However, I believe all you need is to bring the binary running on solaris and put it on your host.
I'm afraid it's not that easy. My target system has binaries in the hundreds, plus sharedlibs
In the hundreds. And, I would need a cross-gdb. I would get that prompt dialog a zillion times,
Even if I prepare a mirror of the target file system on my host :(
The nice thing about running gdb on the remote is, that it is fully self-contained. It finds all
the files in their original places. And CDT is really good doing the source path mapping :)
The idea that I'm currently entertaining is launch gdb on the remote (ssh remote gdb) but
still have it connect to the gdbserver which also runs on the remote, in order to get the
attach functionality. It sounds crazy but works :)
The one thing that gets in the way is the "prompt for process" dialog which tries finding
a file on the local host. Do you think it would be possible to receive the original file path
from the remote, apply a single object path mapping ( / --> /mirror/of/targetfs) and try
find the file there, then only show the "find binary" dialog if that fails ?
Ideally have all object path probing / handling through the gdb/mi channel and not
access the file system locally at all.
If that would work I'd launch my gdb on the remote with an identity mapping (/ --> /)
and all should be fine...
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 5:04 PM
To: 'CDT General developers list.'
Subject: 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>
>
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
