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 ?

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
> Sent: Friday, January 25, 2013 2:21 PM
> To: CDT General developers list.
> Subject: 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 :)

But you won't get a list of processes to choose from in that
case.  It is better than showing a list of the processes
running on the host though :)

> The one thing that gets in the way is the "prompt for 
> process" dialog which tries finding
> a file on the local host. 

With your original trick of running GDB with a local session
but on the target, that prompt wouldn't show up at all, which
seems more user-friendly...
Wouldn't be better for you to try to solve the 'attach list'
isse instead of the 'prompt for process' issue?

> 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.

I like that.
I actually had a similar discussion not too long ago about this
in the hopes of avoiding the prompting.

Could you write an enhancement bug for this?

Thanks!

> 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
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> 

Back to the top